Компания TIOBE Software подвела (http://www.tiobe.com/index.php/content/paperinfo/tpci/index....) итоги популярности языков программирования в 2012 году. Как и в прошлом году, наибольший рост популярности ( 3.37%) отмечен для языка Objective-C, который за год поднялся с с пятого на третье место в рейтинге. На 0.89% выросла популярность языка Си, что позволило данному языку программирования сместить с первого места язык Java, который возглавлял рейтинг последние три года. На две позиции вниз упала популярность языка C#. Языки C++, PHP, Python, Perl, Lisp и JavaScript сохранили свои позиции в рейтинге. Язык Ruby за год поднялся с 12 на 11 место в рейтинге.<center>
<table style="border: 1px solid rgb(176, 177, 144); border-collapse: collapse; background: none repeat scroll 0% 0% rgb(221, 225, 194);" cellpadding="2" cellspacing="0" width="50%" border="1">
<tr><td>место<td>год назад<td>язык<td>изменение популярности</tr>
<tr><td>1<font color=green>↑</font><td>2<td>C<td>+0.89%
<tr><td>2<font color=red>↓</font><td>1<td>Java<td>-0.05%
<tr><td>3<font color=green>↑↑</font><td>5<td>Objective-C<td>+3.37%
<tr><td>4<td>4<td>C++<td>+1.09%
<tr><td>5<font color=red>↓↓</font><td>3<td>C#<td>-2.57%
<tr><td>6<td>6<td>PHP<td>-0.16%
<tr><td>7<td>7<td>(Visual) Basic<td>+0.23%
<tr><td>8<td>8<td>Python<td>+0.96%
<tr><td>9<td>9<td>Perl<td>-0.5%
<tr><td>10<td>10<td>JavaScript<td>-0.34%
<tr><td>11<font color=green>↑</font><td>12<td>Ruby<td>+0.34%
</table>
</center>
<center><a href="http://www.tiobe.com/content/paperinfo/tpci/images/tpci_tren... src="http://www.opennet.me/opennews/pics_base/0_1357635401.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
Индекс популярности TIOBE не пытается найти самый лучший язык программирования по самому большому количеству написанных строк кода, а строит свои доводы по изменению интереса к языкам, на основе анализа статистики поисковых запросов в таких системах, как Google, Google Blogs, Yahoo!, Wikipedia, MSN, YouTube, Bing, Amazon и Baidu.URL: http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
Новость: http://www.opennet.me/opennews/art.shtml?num=35779
Perl популярнее JavaScript и Ruby - мощно задвинули, внушает.Бейсик растёт. Видимо, к дождю... Как они, кстати, Бейсик вычленяют из запросов? Как отличают ruby и рубин, python от удава и т.д.?
> Как они, кстати, Бейсик вычленяют из запросов? Как отличают ruby и рубин, python от удава и т.д.?По контексту же, очевидно
>> Как они, кстати, Бейсик вычленяют из запросов? Как отличают ruby и рубин, python от удава и т.д.?
> По контексту же, очевидноbasic help это про программирование или нет?
Monty Python
> Monty PythonХорошо отражает суть языка. Сплошной стеб над хомяками использующими это а не ЯП.
Смотря какую ссылку пользователь выбрал, ваш КО.
И да, это словосочетание на английском не имеет смысла.
Количество запросов зависит не только от популярности, но и от гемморойности языка. Думаю, именно с этим связано опережение Perl JavaScript.
> Количество запросов зависит не только от популярности, но и от гемморойности языка.
> Думаю, именно с этим связано опережение Perl JavaScript.Да, надо ещё отдельную табличку - сколько раз при запросе фигурировали слова fuck и fuckin'
Ну тогда надо еще учитывать доступность и качество документации языка, идущей вместе с ним и в комплекте. Для perl/ruby/python лазить в интернет за докой как по базовым вещам, так и по дополнительным модулям нет нужды, все это устанавливается локально, документирование в них это часть языка. А вот для js локальной доки нет и не будет, вся информация только в инете.
Python простой язык. ужасная реализация. неповоротливый интерпретатор. отсутствие многопоточности из-за GIL. в любой момент только один поток активен. для большого проекта трудно отлаживаемый. при смене имени класса или параметров не выдает ошибок. нужно многое в голове держать. второй год по работе приходится писать. ненавижу.
> при смене имени класса или параметров не выдает ошибок.какая нелепая критика.
детка, это утиная типизация! и она сделана специально для удобства! если ты пишешь на Python то ты должен и думать как Python-программист. а не говорить фразы типа как "Водка это лажа, так как когда я его пробую Водку на язык -- это горько".
ну воспользуйся тогда zope.interface (или модулем abs. ды тысячи аналогов!) , если тебе прям невмоготу переучить себя на Python-программиста. думай как Python-программист, а не просто пиши Python-код!
> нужно многое в голове держать
например -- что держать?
почему нельзя записать на бумажку или сразу в код (в комментарий например или в assert)?
> отсутствие многопоточности из-за GIL. в любой момент только один поток активен
это неудобво весьма спорное.
1. GIL ускоряет Python (а не замедляет его). экспериментальные реализации Python без GIL в полтора раза медленее чем эталонный Python с GIL.
чтобы это понять -- возможно просто придётся вспомнить зачем вообще был придуман GIL :) . GIL есть и в Ruby (это случайность?).
2. в один момент активная только одна нить (Thread) -- это правда, но только наполовину правда.
предположим некая Пайтоновская нить читает байты из сокета/файла
b = fd.read(4096)
в это время (пока нить читает данные) эта нить НЕ будет является GIL-активной, но данные-то сёравно БУДУТ читаться!а этих операций ввода-вывода -- пруд пруди. постоянно нужно что-то читать или записывать, в случае если Python-утилита является например связанной с жёстким диском или с сетью. если нить исполняет SQL-запрос, то GIL тоже не затормозит его исполнение :) ..
тоесть получается что зачастую заблокированные GIL-нити не такие уж и заблокированные. хотя да, это зависит от выполняемой задачи.
говоря простым языком: GIL-ограничение негативно влияет на распараллеливание Математики.
т.е.: внутри многонитевой Python-программы вся математичка остаётся последовательной, а ввод-вывод паралелльный.> неповоротливый интерпретатор.
куда не поворотливый?
Python-интерпретатор довольно не сложно:
1. ...встраивать внутрь C/C++ программы.
2. ...расширять его модули за счёт C/C++-кода.
> второй год по работе приходится писать. ненавижу.
а до этого (или кроме этого?) на чём?
очевидно на чём-то на том что является противоположностью Пайтона по самой идеологии
[тоесть: статико-типизированном, компилируемом, со сложным синтаксисом].
>[оверквотинг удален]
> GIL :) . GIL есть и в Ruby (это случайность?).
> 2. в один момент активная только одна нить (Thread) -- это правда,
> но только наполовину правда.
> предположим некая Пайтоновская нить читает байты из сокета/файла
> b = fd.read(4096)
> в это время (пока нить читает данные) эта нить НЕ будет является
> GIL-активной, но данные-то сёравно БУДУТ читаться!
> [...]
> т.е.: внутри многонитевой Python-программы вся математичка остаётся последовательной,
> а ввод-вывод паралелльный.Это называется user-space cooperative threading. Такая хрень доступна и для C, например, через библиотечку libpth. Но почему-то, никто не использует libpth, предпочитая libpthread. Странно да? Вот несмотря на все преимущества кооперативной многозадачности, например, отсутствие необходимости в реентерабельности кода (что существенно упрощает синхронизацию нитей), несмотря на то, что при кооперативной многозадачности стоимость нити минимальна, и процесс легко может позволить наплодить себе десять тысяч нитей (на каждый открытый файловый дескриптор сокета по нити) и не положить систему... Несмотря на всё это почему-то в C кооперативная многозадачность непопулярна.
Странно при этом, что, например, Haskell, зачем-то в дополнение к юзер-спейс потокам, в библиотеках есть и ядерные потоки. Странно, что Microsoft, при создании Windows '95 отказалась от корпоративной многозадачности, используемой в предыдущих версиях Windows в пользу вытесняющей. Чего ж это им всем так не нравится корпоративная многозадачность, а?
>> второй год по работе приходится писать. ненавижу.
> а до этого (или кроме этого?) на чём?
> очевидно на чём-то на том что является противоположностью Пайтона по самой идеологии
> [тоесть: статико-типизированном, компилируемом, со сложным синтаксисом].А вы не сталкивались с такой фишкой, как опциональная типизация переменных? То есть когда язык позволяет создать как типизированную переменную, так и не типизированную. Помимо удобств отладки (рантайм исключения, при попытки записать int в переменную типа string), возникает офигенный простор для оптимизации, путём выпиливания из бутылочных горлышек тормозов порождённых динамической типизацией.
Python неплохой язык, для простеньких задач. Но он начался с идеологии, и до сих пор не может отказаться от этой идеологии "всё можно сделать единственным путём". Идеологию фтопку. Есть вполне определённые практические задачи, которые предъявляют вполне определённые требования к языку. Когда же язык, вместо того, чтобы удовлетворять этим требованиям, начинает швыряться лозунгами, и говорить что требования некошерны... Это как минимум странно.
> Когда же язык, вместо того, чтобы удовлетворять этим требованиям, начинает швыряться лозунгами, и говорить что требования некошерны... Это как минимум странно.тыг что-то давно я не видел в каких-то требованиях пункта *ПОЛНЕЙШАЯ* многозадачность :-) ..
тут вот товаришь пытался нам сообщить что в Python совершенно нет многозадачности. на что ему ответили что многозадачность есть, но она распространяется не на всю программу, а на ввод-вывод.
в требованиях же к разрабатываемым утилитам обычно так и сказано "обеспечить многозадачность" (тоесть -- хотябы какую-то! без намёка на то что что математика якобы тоже должна быть многозадачной :-)).
и не забывайте пожалуйста что если мы будем перекладывать часть функционала на операционную подсистему -- то от этого эти функции сёравно всё также будут выполняться на процессоре а не внутри астрала (нагрузка на процессоре будет возрастать!).
>> Когда же язык, вместо того, чтобы удовлетворять этим требованиям, начинает швыряться лозунгами, и говорить что требования некошерны... Это как минимум странно.
> тыг что-то давно я не видел в каких-то требованиях пункта *ПОЛНЕЙШАЯ* многозадачность
> :-) ..
> тут вот товаришь пытался нам сообщить что в Python совершенно нет многозадачности.
> на что ему ответили что многозадачность есть, но она распространяется не
> на всю программу, а на ввод-вывод.Я выше предложил на выбор два термина для обозначения такой многозадачности: user-space многозадачность, и кооперативная многозадачность. Первый термин, по-моему, лучше описывает особенности питона, но второй, в общем, тоже об этом. И я предлагаю пользоваться этой устоявшейся терминологией, не изобретая велосипедов, типа "многозадачности, распространяемой на ввод/вывод".
> в требованиях же к разрабатываемым утилитам обычно так и сказано "обеспечить многозадачность"
> (тоесть -- хотябы какую-то! без намёка на то что что математика
> якобы тоже должна быть многозадачной :-)).
> и не забывайте пожалуйста что если мы будем перекладывать часть функционала на
> операционную подсистему -- то от этого эти функции сёравно всё также
> будут выполняться на процессоре а не внутри астрала (нагрузка на
> процессоре будет возрастать!).В ТЗ обычно пишется, для чего нужна многозадачность, и соответственно становится ясным, какого типа многозадачность подразумевается. Лет десять-пятнадцать назад, kernel-space реализация thread'ов, очевидно, была оверхедом в большинстве случаев, а на десктопах -- даже не в большинстве, а всегда. Но в современных системах, в которых количество процессоров/ядер подчастую больше единицы, достаточно загадочной выглядит насильственная привязка языка к user-space многозадачности.
Да, я замечу, что лет пять назад я бредил идеей создания сервера использующего user-space многозадачность с целью повышения производительности. На базе той самой, упомянутой мною, libpth. Сегодня же, в виду того, что у меня дома стоит четырёхядерный проц, а на серверах с которыми я имею дело, подчастую, ядер ещё больше, у меня рождаются серьёзные сомнения в том, что овчинка стоит выделки. И к сомнениям добавляется подозрение, что сомнения превратятся в уверенность лет через десять, когда для процессоров станет нормальным иметь двух-трёх-значное число ядер.
`
>>[оверквотинг удален]
> Несмотря на всё это почему-то в C кооперативная многозадачность непопулярна.Кооперативной многозадачности в C чуть более, чем на каждом углу. Только реализуется она через FSM'ы и select/poll/etc, или через движки типа eventlib.
Боюсь, что то, что Вы рассказываете, объясняется личными проблемами libpth, а не общего подхода.
> Странно при этом, что, например, Haskell, зачем-то в дополнение к юзер-спейс потокам,
> в библиотеках есть и ядерные потоки. Странно, что Microsoft, при создании
> Windows '95 отказалась от корпоративной многозадачности, используемой в предыдущих версиях
> Windows в пользу вытесняющей. Чего ж это им всем так не
> нравится корпоративная многозадачность, а?Ну, во-первых, кооперативная, а не корпоративная:) Во-вторых, к чему Вы это?
Хотите полноценную вытесняющую многозадачность в Python? Модуль multiprocessing находится в стандартной поставке, начиная с 2.6. Представляете, там есть даже разделяемые переменные и возможность делать менеджеры доступа с персональной политикой синхронизации.> А вы не сталкивались с такой фишкой, как опциональная типизация переменных? То
> есть когда язык позволяет создать как типизированную переменную, так и не
> типизированную. Помимо удобств отладки (рантайм исключения, при попытки записать int в
> переменную типа string), возникает офигенный простор для оптимизации, путём выпиливания
> из бутылочных горлышек тормозов порождённых динамической типизацией.Ага, для этого давно уже есть Cython.
> Python неплохой язык, для простеньких задач. Но он начался с идеологии, и
> до сих пор не может отказаться от этой идеологии "всё можно
> сделать единственным путём". Идеологию фтопку. Есть вполне определённые практические
> задачи, которые предъявляют вполне определённые требования к языку. Когда же язык,
> вместо того, чтобы удовлетворять этим требованиям, начинает швыряться лозунгами, и говорить
> что требования некошерны... Это как минимум странно.Там есть странные вещи, но, о чём Вы говорите, давно и успешно решается. Просто надо знать чуть шире, чем одно базовое средство.
>>>[оверквотинг удален]
>> Несмотря на всё это почему-то в C кооперативная многозадачность непопулярна.
> Кооперативной многозадачности в C чуть более, чем на каждом углу. Только реализуется
> она через FSM'ы и select/poll/etc, или через движки типа eventlib.В некотором смысле, можно сказать и так. Но вы пробовали когда-нибудь писать используя thread_create? Одно дело писать программу в ивентуальном стиле, и совсем другое в чисто итеративном. В первом случае, без создания конечного автомата далеко не уедешь. Во втором же, всё как-то само по себе выходит.
Мы отклоняемся от темы. Говоря слова "многозадачность" мы всё же имеем в виду потоки выполнения, а не тысячи инстансов конечных автоматов разбирающих HTTP в apache, не так ли? Или это надо было отдельно оговорить?
> Боюсь, что то, что Вы рассказываете, объясняется личными проблемами libpth, а не
> общего подхода.Нет, не думаю. У меня есть другое объяснение тому. Если потоков немного, то пенальти по производительности от kernel-space потоков, как правило невелики (хотя, конечно, бывают и яркие обратные примеры). А если потоков много, то как правило, приходится ориентироваться на многие тысячи файловых дескрипторов, а когда так, придётся мешать в одну кучу libpthread и libpth. А это мало того, что требует внимательности (писать ли pth_create или pthread_create?), так ведь каждый user-space поток, всё же, придётся писать с оглядкой на реентерабельность. В частности, придётся пользоваться реализацией примитивов синхронизации из libpthread, а не из libpth. То есть часть существенных преимуществ относящихся к простоте кода и его эффективности уже будет утеряна. Из плюсов подхода останется лишь итеративность кода, и возможность прозрачно организовать lazy aio. Стоит ли это лишнего депенданса -- ещё большой вопрос. Тем более, что привычный ивентуальный подход хорошо известен, проверен временем и десятком(-ами?) успешных известных примеров.
> Ну, во-первых, кооперативная, а не корпоративная:)
Точно-точно. =)
> Во-вторых, к чему Вы это?
> Хотите полноценную вытесняющую многозадачность в Python?Нет, я не хочу. На python я давно забил. Собственно, никогда им особо и не интересовался. Скучный безликий язык. Если уж и разглядывать что-нибудь из языков этого класса, так ruby, по-моему, существенно приятнее. Как в плане синтаксических плюшек, так и в плане семантических.
> Модуль multiprocessing находится
> в стандартной поставке, начиная с 2.6. Представляете, там есть даже разделяемые
> переменные и возможность делать менеджеры доступа с персональной политикой синхронизации.М-м-м... Но это же на самом деле полноценные тяжеленные процессы, так? Со своим адресным пространством. Значит надо возится с SHM, только для того, чтобы передать картинку? Вариант, конечно. Но, допустим, если мы попытаемся реализовать апач на python'e -- не знаю зачем, но допустим, -- как мы сможем создать три процесса, по двадцать пять kernel-space потоков в каждом процессе, так чтобы каждый поток по сотне файловых дескрипторов обрабатывал в параллели?
>> А вы не сталкивались с такой фишкой, как опциональная типизация переменных? То
>> есть когда язык позволяет создать как типизированную переменную, так и не
>> типизированную. Помимо удобств отладки (рантайм исключения, при попытки записать int в
>> переменную типа string), возникает офигенный простор для оптимизации, путём выпиливания
>> из бутылочных горлышек тормозов порождённых динамической типизацией.
> Ага, для этого давно уже есть Cython.И как это чудо прикрутить к скриптам, которые мне иногда приходится писать в LibreOffice?
Cython -- это же уже не питон. Он уже язык с обязательной компиляцией. С другим синтаксисом. Дополнительными депендансами. Поэтому те python'овские скрипты, которые я использую в системе, так всегда и останутся питоновскими, и никогда не будут использовать статическую типизацию, даже если разработчики поймут, что в некоторых ситуациях это удобно и полезно.>> Python неплохой язык, для простеньких задач. Но он начался с идеологии, и
>> до сих пор не может отказаться от этой идеологии "всё можно
>> сделать единственным путём". Идеологию фтопку. Есть вполне определённые практические
>> задачи, которые предъявляют вполне определённые требования к языку. Когда же язык,
>> вместо того, чтобы удовлетворять этим требованиям, начинает швыряться лозунгами, и говорить
>> что требования некошерны... Это как минимум странно.
> Там есть странные вещи, но, о чём Вы говорите, давно и успешно
> решается. Просто надо знать чуть шире, чем одно базовое средство.Я бы поверил Вам на слово. Если бы речь шла не о Python'е. На заре своего существования, он был слишком увлечён противопоставлением себя Perl'у. Это фатально на нём сказалось. То есть он достаточно приятный язык, допустим PHP в разы хуже и неудобнее. Но и всё же, он далёк от идеала. По-крайней мере существенно дальше, чем ruby.
Ruby это по сути тотже Python , но сделанный для волшебников (хакеров).тяжёлая магия -- в Ruby -- будто бы считается нормой.
характерный пример:
например, в Ruby [где-нибудь в середине кода, в одном из файлов] можно написать:
foo = Bar.newа теперь [если ты не являешься автором кода] -- КАК ИМЕННО ты узнаешь где именно находится описание класса "Bar" ? оно может быть где угодно (в непонятно каком файле) ! искать через grep чтоле?
и подобных примеров -- огромное множество!
Python же ориентирован больше на то что не все люди являются экстрасенсами :) ..
там чётко:
from baz import Bar
#... ... ...
#... ... ...
#... ... ...
foo = Bar()
#... ... ...
#... ... ...
#... ... ...это значит что "Bar" задекларирован внутри "baz".
потомучто магия -- она хороша только когда автор кода является один.
> Ruby это по сути тотже Python , но сделанный для волшебников (хакеров).
> [...]
> потомучто магия -- она хороша только когда автор кода является один.Много слов, в конечном итоге сводящихся к тому, что на Ruby проще написать нечитабельную программу. Я правильно понял вашу позицию?
Мне кажется, что если в отношении Perl'а такого рода обвинения достаточно обоснованы: всем я думаю приходилось сталкиваться с совершенно нечитаемыми скриптами на Perl, и матерясь так, что жена с кухни прибегает выяснить в чём же дело, разгребать дерьмо пытаясь понять, почему оно не работает.
Но когда речь идёт о сравнении Python и Ruby, мне это больше напоминает давно забытый холивар Pascal vs C. Одним из основных аргументов ведущего этого холивара, проф. Н. Вирта, был именно аргумент о том, что на C проще написать плохой код. То есть мне кажется, что в случае Ruby, дополнительные возможности создать нечитаемый код не столь уж и существенны, что бы изменить ситуацию с чтением сорцов в худшую сторону.
ps. Да. И если вам не удаётся найти описание символа программы, то find+grep, при всей его универсальности, не единственный способ. И не всегда самый удачный. Есть ещё ctags/etags. Я, правда не пробовал (не возникало нужды) etags применительно к ruby, и не знаю насколько он может помочь, но сейчас погуглил: он умеет и ruby.
>>> Несмотря на всё это почему-то в C кооперативная многозадачность непопулярна.
>> Кооперативной многозадачности в C чуть более, чем на каждом углу. Только реализуется
>> она через FSM'ы и select/poll/etc, или через движки типа eventlib.
> В некотором смысле, можно сказать и так. Но вы пробовали когда-нибудь писать
> используя thread_create?Именно эту библиотеку - нет, а вообще - да.
Ничего принципиально проблемного не увидел. Более того, возможность строить прямой код вместо FSM оказалась сильно удобнее во многих случаях (хотя и не идеальным вариантом).> Одно дело писать программу в ивентуальном стиле, и совсем
> другое в чисто итеративном. В первом случае, без создания конечного автомата
> далеко не уедешь.Но при этом совершенно не обязательно рисовать тот автомат явно.
> Мы отклоняемся от темы. Говоря слова "многозадачность" мы всё же имеем в
> виду потоки выполнения, а не тысячи инстансов конечных автоматов разбирающих HTTP
> в apache, не так ли? Или это надо было отдельно оговорить?Видимо, надо было отдельно. Впрочем, уже понятно.
Если мы отклоняемся от темы, то лучше было бы говорить немного о другом - а именно, почему вообще подход через кооперативные задачи (они же green threads, они же fibers) лучше для теории (и хуже для практики, потому что мало используется).>> Боюсь, что то, что Вы рассказываете, объясняется личными проблемами libpth, а не
>> общего подхода.
> Нет, не думаю. У меня есть другое объяснение тому. Если потоков немного,
> то пенальти по производительности от kernel-space потоков, как правило невелики (хотя,
> конечно, бывают и яркие обратные примеры). А если потоков много, то
> как правило, приходится ориентироваться на многие тысячи файловых дескрипторов, а когда
> так, придётся мешать в одну кучу libpthread и libpth.А смешение в одну кучу pthreads и FSM, как сделано в самых высокопроизводительных системах, Вас не пугает? Там ровно те же проблемы.
> А это
> мало того, что требует внимательности (писать ли pth_create или pthread_create?), так
> ведь каждый user-space поток, всё же, придётся писать с оглядкой на
> реентерабельность. В частности, придётся пользоваться реализацией примитивов синхронизации
> из libpthread, а не из libpth.И что это меняет (по сравнению с бутербродом pthreads+FSM, потому что имеет сравнивать только с ним)? На практике достаточно, чтобы синхронизация pthreads была "внутри" синхронизации pth, и это решает, насколько я понимаю, все проблемы, которые тут решаются. Те же, которые не решаются, точно так же не решаются и в случае FSM внутри pthread, и тогда требуется явные меры синхронизации со стороны программиста (но таких случаев лучше избегать).
Насколько я понимаю, это аргументы в ту же сторону, куда и Вы клоните? Но тогда что от этого меняется?
> То есть часть существенных преимуществ
> относящихся к простоте кода и его эффективности уже будет утеряна. Из
> плюсов подхода останется лишь итеративность кода, и возможность прозрачно организовать
> lazy aio. Стоит ли это лишнего депенданса -- ещё большой вопрос.
> Тем более, что привычный ивентуальный подход хорошо известен, проверен временем и
> десятком(-ами?) успешных известных примеров.То есть Вам по факту пофиг, будут green threads или один движок событий. Тогда при чём тут Питон?
>> Во-вторых, к чему Вы это?
>> Хотите полноценную вытесняющую многозадачность в Python?
> Нет, я не хочу. На python я давно забил. Собственно, никогда им
> особо и не интересовался. Скучный безликий язык. Если уж и разглядывать
> что-нибудь из языков этого класса, так ruby, по-моему, существенно приятнее. Как
> в плане синтаксических плюшек, так и в плане семантических.Ну кому "скучный и безликий", а кому отличная рабочая лошадка, при этом приятная и удобная. В отличие от Ruby, который требует выворота мозгов, который не окупается.
>> Модуль multiprocessing находится
>> в стандартной поставке, начиная с 2.6. Представляете, там есть даже разделяемые
>> переменные и возможность делать менеджеры доступа с персональной политикой синхронизации.
> М-м-м... Но это же на самом деле полноценные тяжеленные процессы, так? Со
> своим адресным пространством. Значит надо возится с SHM, только для того,
> чтобы передать картинку? Вариант, конечно.А чем это отличается от передачи данных между тредами? Там такое же SHM и та же синхронизация. Только в случае тредов вся память зашарена насильно, а в случае процессов это надо делать явно.
(Нет, я, конечно, знаю, где отличия. Но для обычной питоновой роли они малосущественны.)> Но, допустим, если мы попытаемся реализовать
> апач на python'e -- не знаю зачем, но допустим, -- как
> мы сможем создать три процесса, по двадцать пять kernel-space потоков в
> каждом процессе, так чтобы каждый поток по сотне файловых дескрипторов обрабатывал
> в параллели?Странный запрос. Очень странный.
Если уж говорить об апаче, то у него общего между тредами или процессами (в зависимости от MPM) минимум. После перечитывания конфига они расползаются и всё взаимодействие - это запись в лог и борьба за очередь на сокет.
И в этом случае пофиг, на сколько каких сущностей оно расцеплено, лишь бы не мешало друг другу.Ваша постановка задачи в виде "три процесса по 25 kernel-space потоков" уже намеренно натянута, как те "тендеры", которые рассчитаны ровно на одного производителя и одного поставщика.
> И как это чудо прикрутить к скриптам, которые мне иногда приходится писать
> в LibreOffice?
> Cython -- это же уже не питон. Он уже язык с обязательной
> компиляцией. С другим синтаксисом. Дополнительными депендансами. Поэтому те python'овские
> скрипты, которые я использую в системе, так всегда и останутся питоновскими,
> и никогда не будут использовать статическую типизацию, даже если разработчики поймут,
> что в некоторых ситуациях это удобно и полезно.Если для них не критична скорость - так пусть остаются. В чём проблема-то?
Я плохо представляю себе, честно говоря, необходимость, например, высокой математики в libreoffice.>> Там есть странные вещи, но, о чём Вы говорите, давно и успешно
>> решается. Просто надо знать чуть шире, чем одно базовое средство.
> Я бы поверил Вам на слово. Если бы речь шла не о
> Python'е. На заре своего существования, он был слишком увлечён противопоставлением себя
> Perl'у. Это фатально на нём сказалось.Простите, я не понимаю, откуда у Вас такие выводы. С Perl они стартовали (как самостоятельные языки) ноздря в ноздрю, но развивались совершенно без оглядки друг на друга где-то до середины 90-х. Далее, противопоставление по каким свойствам? Я не вижу ни одного примера того, что было бы намеренно сделано "не как в Perl" и при этом объективно бы ухудшило потребительские свойства языка. Наоборот, практически все принципиальные решения в Python привели к лучшему результату. Например, я таким считаю возможность писать a.b.c вместо $a->{b}{c}, даже такие банальности синтаксиса уже улучшают читабельность в разы. Или отсутствие принципиально разных подходов для написания одноэкранников и большого кода. Или лучшая ориентация на генерацию исключений вместо отдачи undef или аналога, маскирующего проблему.
И, кстати, при чём тут однобокая развитость к вопросу о наличии Cython? Что, для Perl есть вариант написания со статической типизацией, компилируемый в эффективный машинный код?
> То есть он достаточно приятный
> язык, допустим PHP в разы хуже и неудобнее. Но и всё
> же, он далёк от идеала.
> По-крайней мере существенно дальше, чем ruby.Для Вас Ruby близок к идеалу? Извините, но jIMHO Ruby это достаточно однобокая поделка на тему "мы тут попытались сделать функциональную ориентированность через <strike>задницу соседа</strike> объектную ориентированность, причём записать это всё по-японски, чтобы круче выглядело".
> [...]
> Насколько я понимаю, это аргументы в ту же сторону, куда и Вы
> клоните? Но тогда что от этого меняется?
> [...]
> То есть Вам по факту пофиг, будут green threads или один движок
> событий. Тогда при чём тут Питон?Вообще весь тот разговор о libpth я рассматривал как эдакий оффтопик. Он был эдаким вольным рассуждением на тему "почему же apache вручную возится с select/poll не используя libpth взамен". Мне казалось, что оффтопичность сего достаточно очевидна и допустима. Видимо ошибался.
>>>[...]
> Ну кому "скучный и безликий", а кому отличная рабочая лошадка, при этом
> приятная и удобная. В отличие от Ruby, который требует выворота мозгов,
> который не окупается.Вы хотите сказать о том, что мэйнстим как всегда ездит по проторенной дорожке боясь свернуть в сторону? Я знаю это. И все, по-моему, знают. И даже причины тому известны. Скучны и неинетересны ибо обсуждались тысячи раз.
>>> Модуль multiprocessing находится [...]
> А чем это отличается от передачи данных между тредами? Там такое же
> SHM и та же синхронизация. Только в случае тредов вся память
> зашарена насильно, а в случае процессов это надо делать явно.
> (Нет, я, конечно, знаю, где отличия. Но для обычной питоновой роли они
> малосущественны.)Явно надо указывать, что создавая объект надо выделять его из SHM кучи, а не из локальной. При необходимости передать открытый файловый дескриптор надо прибить дочерний процесс и создать новый. Когда приспичит подгрузить библиотеку, надо подгружать её в каждом процессе, а не во всех сразу.
Это достаточно существенные отличия, накладывающие ограничения на допустимые подходы к проектированию кода. Причём, на мой взгляд, искусственные и ненужные ограничения.>> [...]
> Ваша постановка задачи в виде "три процесса по 25 kernel-space потоков" уже
> намеренно натянута, как те "тендеры", которые рассчитаны ровно на одного производителя
> и одного поставщика.Это просто один из примеров. Вполне реальный пример. Дополнительная демонстрация на ограничения накладываемые отсутствием kernel-space thread'ов в python'е.
>> И как это чудо прикрутить к скриптам, которые мне иногда приходится писать
>> в LibreOffice?
>> Cython -- это же уже не питон. [...]
> Если для них не критична скорость - так пусть остаются. В чём
> проблема-то?
> Я плохо представляю себе, честно говоря, необходимость, например, высокой математики в
> libreoffice.Вообще-то, типизация переменных (из-за которой начался разговор про Cython), в моём понимании для скрипт языка в первую очередь средство программирования/отладки, нежели способ увеличить эффективность байткода. В случае работы с calc, например, очень приятно было бы типизировать переменные, чтобы попытка взять из ячейки строку и положить в переменную типа int выкидывала бы исключение, которое я обрабатывал бы промеж прочих исключений, не засирая код тучами явных проверок типов. А если бы, при этом, python поддерживал бы типа вида {целое в диапазоне от 5 до 17} то это было бы вообще супер. А если бы он поддерживал типы, когда я в качестве типа мог бы указать предикат проверки принадлежности типу... Да я бы задвинул на всё остальное и писал бы на python'е. Шутка, конечно, но как всегда, доля правды в ней есть.
Но Python не только не поддерживает типы задаваемые предикатами, он вообще не поддерживает типизацию переменных. Он не поддерживает объявление переменных, например с целью автоматического отлова ошибок типа очепятка_в_имени_переменной. И шансов на изменение ситуации к лучшему нет никаких.
А то, что статическая типизация, подчастую позволяет компилятору генерировать более эффективный код, с моей точки зрения, для интерпретируемого языка просто дополнительная бесплатная плюшка. И да, иногда, даже в скриптах для libreoffice эта плюшка могла бы быть экстремально полезной. Когда начинается какая-нибудь возня в таблицах, с переборами вариантов как можно переставить элементы этих таблиц получше... Там вообще-то NP-hard проблема была, проблема составления расписания, но кое-что сделать можно было, чтобы поменьше телодвижений совершать вручную. И кое-что я сделал. Но ограничение на глубину рекурсии выбиралось из соображений "чтоб гуй не залипал в тормозах". Как вы понимаете, статическая типизация могла бы немало помочь. Допустим в SBCL добавление в код указания типов переменных может увеличить скорость выполнения в 2-3 раза. Правда SBCL компилирует в native код, но всё же.>>> Там есть странные вещи, но, о чём Вы говорите, давно и успешно
>>> решается. Просто надо знать чуть шире, чем одно базовое средство.
>> Я бы поверил Вам на слово. Если бы речь шла не о
>> Python'е. На заре своего существования, он был слишком увлечён противопоставлением себя
>> Perl'у. Это фатально на нём сказалось.
> Простите, я не понимаю, откуда у Вас такие выводы. С Perl они
> стартовали (как самостоятельные языки) ноздря в ноздрю, но развивались совершенно без
> оглядки друг на друга где-то до середины 90-х.Да неужели?
http://en.wikipedia.org/wiki/There%27s_more_than_one_wa...
http://www.python.org/dev/peps/pep-0020/
Вторая ссылка сама по себе показательна, и набор фраз там очень напоминает сутру "мы делаем перл, но наоборот". При этом, для наглядности, я явно одну из фраз процитирую здесь: "There should be one-- and preferably only one --obvious way to do it." =)> И, кстати, при чём тут однобокая развитость к вопросу о наличии Cython?
> Что, для Perl есть вариант написания со статической типизацией, компилируемый в
> эффективный машинный код?Дискуссия эта не равносильна дискуссии "почему python лучше perl'а". Я высказал своё мнение, чем плох Python. Про перл я выше упомянул лишь к слову о том, что... В общем, Perl и Python они находятся в некотором смысле на двух противоположных концах доведения идеи до абсурда. Или излагая свои мысли чуть иначе, я бы сказал, что Perl и Python исповедуют во многом противоположные идеи, но одну идею -- доведение идеи до абсурда -- они оба признают как основополагающую.
>> То есть он достаточно приятный
>> язык, допустим PHP в разы хуже и неудобнее. Но и всё
>> же, он далёк от идеала.
>> По-крайней мере существенно дальше, чем ruby.
> Для Вас Ruby близок к идеалу? Извините, но jIMHO Ruby это достаточно
> однобокая поделка на тему "мы тут попытались сделать функциональную ориентированность
> через <strike>задницу соседа</strike> объектную ориентированность, причём записать
> это всё по-японски, чтобы круче выглядело".Вполне себе honest opinion, я так и не понял, зачем, прежде чем высказать его, вы заранее испрашивали извинений.
>[оверквотинг удален]
>> Простите, я не понимаю, откуда у Вас такие выводы. С Perl они
>> стартовали (как самостоятельные языки) ноздря в ноздрю, но развивались совершенно без
>> оглядки друг на друга где-то до середины 90-х.
> Да неужели?
> http://en.wikipedia.org/wiki/There%27s_more_than_one_wa...
> http://www.python.org/dev/peps/pep-0020/
> Вторая ссылка сама по себе показательна, и набор фраз там очень напоминает
> сутру "мы делаем перл, но наоборот". При этом, для наглядности, я
> явно одну из фраз процитирую здесь: "There should be one-- and
> preferably only one --obvious way to do it." =)Вопрос именно в слове obvious. И я с этим согласен: должен быть один (и в идеале только один) *очевидный*, соответственно, выбираемый по умолчанию, путь сделать что-то. Это позволяет делать основную часть работы предельно просто и прямолинейно, отвлекаясь только на те случаи, когда что-то не устраивает в таком пути (например, производительность, или какие-то мелкие, но существенные особенности реализации).
С другой стороны, количество путей совершенно не ограничивается. Я как-то видел сравнение ~7 реализаций действия типа массовой замены символов в строке, с вычислением производительности и совершенно неожиданными результатами.
А какие именно фразы говорят про "перл наоборот"? Неужели "Beatiful is better than ugly"? ;)
>> Ну кому "скучный и безликий", а кому отличная рабочая лошадка, при этом
>> приятная и удобная. В отличие от Ruby, который требует выворота мозгов,
>> который не окупается.
> Вы хотите сказать о том, что мэйнстим как всегда ездит по проторенной
> дорожке боясь свернуть в сторону? Я знаю это. И все, по-моему,
> знают. И даже причины тому известны. Скучны и неинетересны ибо обсуждались
> тысячи раз.Не так. Перед майнстримом есть огромное количество народу, который экспериментирует со всем. И уже по их результатам что-то попадает в майнстрим. Так вот - их любовь к тому же Ruby подозрительно быстро прошла в последнее время.
>>>> Модуль multiprocessing находится [...]
>> А чем это отличается от передачи данных между тредами? Там такое же
>> SHM и та же синхронизация. Только в случае тредов вся память
>> зашарена насильно, а в случае процессов это надо делать явно.
>> (Нет, я, конечно, знаю, где отличия. Но для обычной питоновой роли они
>> малосущественны.)
> Явно надо указывать, что создавая объект надо выделять его из SHM кучи,
> а не из локальной.Это проблема? Мне кажется, это скорее преимущество.
Кстати, мультитрединг в Perl такой же - взаимодействие между нитями только явное.> При необходимости передать открытый файловый дескриптор надо
> прибить дочерний процесс и создать новый.Вообще-то передача дескриптора между процессами работала через Unix sockets ещё в 80-х годах. Да, это может потребовать вспомогательного модуля на Си, но это ничтожная плата в большинстве случаев.
> Вполне себе honest opinion, я так и не понял, зачем, прежде чем
> высказать его, вы заранее испрашивали извинений.Ну Вы как-то уж очень агитировали за него.
> А какие именно фразы говорят про "перл наоборот"? Неужели "Beatiful is better
> than ugly"? ;)И эта тоже. А что, скажете, нет?
>> Вы хотите сказать о том, что мэйнстим как всегда ездит по проторенной
>> дорожке боясь свернуть в сторону? Я знаю это. И все, по-моему,
>> знают. И даже причины тому известны. Скучны и неинетересны ибо обсуждались
>> тысячи раз.
> Не так. Перед майнстримом есть огромное количество народу, который экспериментирует со
> всем. И уже по их результатам что-то попадает в майнстрим. Так
> вот - их любовь к тому же Ruby подозрительно быстро прошла
> в последнее время.Что значит "не так"? Вы не натыкались на подобные обсуждения, почему мейнстрим столь ограниченно мыслит? Но давайте всё же не будем поднимать тему, она ещё более холиварная, нежели ущербности питона. Я даже боюсь подумать о том, в чём меня начнут подозревать, если я влезу в эту тему: в мейнстримности головного мозга? Или наоборот в непонимании всей мудрости и профессионализма мейнстрим-разработчика? Или в чём-то третьем?
>> Явно надо указывать, что создавая объект надо выделять его из SHM кучи,
>> а не из локальной.
> Это проблема? Мне кажется, это скорее преимущество.Ключевое слово "кажется". Тогда и файловый дескриптор -- сплошное преимущество перед std::stream: файловый дескриптор даёт удивительно тонкий контроль над ситуацией, и, главное -- всё наглядно. Читая код, всегда будешь в курсе какая стратегия буферизации используется, всегда будет понятно, какой формат вывода числовых данных активен в данный момент. И никаких сбивающих с толку неявностей.
> Кстати, мультитрединг в Perl такой же - взаимодействие между нитями только явное.
Ну это вам виднее. В перле я не писатель, в перле я читатель.
Но при чём тут перл? Это в к тому, что реализовывая мультитрединг Python пошёл не в абсолютно противоположную сторону? Может быть. Но что нашему диалогу даёт понимание этого факта?>> При необходимости передать открытый файловый дескриптор надо
>> прибить дочерний процесс и создать новый.
> Вообще-то передача дескриптора между процессами работала через Unix sockets ещё в 80-х
> годах. Да, это может потребовать вспомогательного модуля на Си, но это
> ничтожная плата в большинстве случаев.Вы не могли бы привести здесь кусочек кода на Python, который продемонстрирует передачу открытого файла между процессами?
>> Вполне себе honest opinion, я так и не понял, зачем, прежде чем
>> высказать его, вы заранее испрашивали извинений.
> Ну Вы как-то уж очень агитировали за него.Вам опять "кажется". Я никого ни на что не агитирую. Уверен твёрдо, что каждый сам кузнец своего счастья, и мои подсказки не требуются. Вот представьте, на секундочку, а если я займусь агитацией, но ошибусь с выбором предмета агитации. И представьте, что мне случится убедить окружающих в том, что дерьмо сладкое и вкусное. Они же наевшись дерьма, меня обвинят в том, что я насильно им дерьмо в рот засовывал. Зачем мне это надо?
Я не агитирую, лишь рассказываю, что мне не нравится в питоне. А руби, перл, C, и все прочие языки, что я упоминал -- это лишь примеры, приведённые для пояснения различных моих высказываний.
>> А какие именно фразы говорят про "перл наоборот"? Неужели "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, и все прочие языки, что я упоминал --
> это лишь примеры, приведённые для пояснения различных моих высказываний.Вы слишком несистемно поясняете, и это сильно мешает понять основную идею.
>>> А какие именно фразы говорят про "перл наоборот"? Неужели "Beatiful is better
>>> than ugly"? ;)
>> И эта тоже. А что, скажете, нет?
> Простите, правильно ли я понимаю, что из этого непосредственно и бесспорно следует,
> что принцип Perl обратен этому, то есть у него "Ugly is
> better than beatiful"? ;)
> Если я неправильно Вас понял, то уточните. А то тут слишком сложно
> понять как-то иначе.Уточняю: не правильно. У перла это не основополагающий принцип, а следствие. Разных причин следствие.
> Майнстрим мыслит не ограниченно, а очень разнообразно. [...]
One more time: я не хочу обсуждать эту тему. Мне очень не хочется вас огорчать отказом, но всё же я вынужден это сделать.
> В итоге я даже на C++ предпочту stdio для текстового
> общения: оно не страдает ерундой на ровном месте.О, даже как! Круто. А tail-рекурсию в C++ вы, наверное, реализуете asm-вставкой, чтобы не связываться с компилятором, который может как-нибудь не так соптимизировать рекурсивный вызов?
>> Это в к тому, что реализовывая мультитрединг
>> Python пошёл не в абсолютно противоположную сторону? Может быть. Но что
>> нашему диалогу даёт понимание этого факта?
> Оно даёт то, что я хочу уже третье письмо показать - что
> Python в своём развитии не отталкивался от Perl, он шёл своей
> дорогой.Ладно, давайте считать что он шёл своей дорогой, а то что его принципы во многом противоположные тому, к чему пришёл перл следуя своим принципам -- это чистой воды случайность, и все причинно-следственные связи мне лишь кажутся.
>> Вы не могли бы привести здесь кусочек кода на Python, который продемонстрирует
>> передачу открытого файла между процессами?
> http://code.google.com/p/python-passfd/ (BSD sockets style)
> https://groups.google.com/forum/?fromgroups=#!msg/comp.lang....
> (SysV STREAMS style)
> нагуглил менее чем за минуту, Вы это отлично могли сделать сами.Мог. Наверное. Но увидев код, который мне не показался бы аргументом к нашему диалогу, я имел бы все основания сомневаться в том, что я плохо искал.
> Зачем агитировать за дерьмо, я таки не знаю:) А вот зачем агитировать
> за апельсин, картошку или говяжий стейк, я могу себе представить без
> проблем.И, интересно, зачем? Вы, кстати, пробовали? Как успехи?
>> Я не агитирую, лишь рассказываю, что мне не нравится в питоне. А
>> руби, перл, C, и все прочие языки, что я упоминал --
>> это лишь примеры, приведённые для пояснения различных моих высказываний.
> Вы слишком несистемно поясняете, и это сильно мешает понять основную идею.Ничем помочь не могу. Либо вы имеете желание понимать, и поэтому вчитываетесь, и понимаете или задаёте вопросы, чтобы выяснить то, что неясно, либо помочь ничем не могу: если вместо того, чтобы выяснять у меня то, что вам непонятно, вы агитируете за питон, то наш разговор -- это разговор глухого с немым.
Меня бесполезно агитировать, и за апельсины, и за картошку с говяжьим стейком. И особенно за питон. Я равнодушен к процессу еды, воспринимаю его как надоевшую физиологическую потребность, поэтому мне практически без разницы, чем питаться. А почему меня бесполезно агитировать за питон, я уже объяснял вам. Позвольте я не буду повторяться.
> Уточняю: не правильно. У перла это не основополагающий принцип, а следствие. Разных
> причин следствие.Ну тогда вообще любое другое средство должно стремиться уйти от такого результата.
>> В итоге я даже на C++ предпочту stdio для текстового
>> общения: оно не страдает ерундой на ровном месте.
> О, даже как! Круто. А tail-рекурсию в C++ вы, наверное, реализуете asm-вставкой,
> чтобы не связываться с компилятором, который может как-нибудь не так соптимизировать
> рекурсивный вызов?Я не могу ничего сказать про такие вещи в C++, потому что не разбираюсь в них. Но мне кажется, что сравнение некорректно.
И, BTW, я сказал, чего не хватает iostream'у, чтобы быть нормально использованным, с моей точки зрения (в смысле, так, чтобы не иметь этот тяжёлый недостаток).> Ладно, давайте считать что он шёл своей дорогой, а то что его
> принципы во многом противоположные тому, к чему пришёл перл следуя своим
> принципам -- это чистой воды случайность, и все причинно-следственные связи мне
> лишь кажутся.Ну, наверно, так оно и есть.
>> Зачем агитировать за дерьмо, я таки не знаю:) А вот зачем агитировать
>> за апельсин, картошку или говяжий стейк, я могу себе представить без
>> проблем.
> И, интересно, зачем? Вы, кстати, пробовали? Как успехи?Достаточно успешно (не за этот конкретный набор продуктов, но за похожие). Разумеется, когда собеседник в принципе был готов принять какой-то совет.
>>> Я не агитирую, лишь рассказываю, что мне не нравится в питоне. А
>>> руби, перл, C, и все прочие языки, что я упоминал --
>>> это лишь примеры, приведённые для пояснения различных моих высказываний.
>> Вы слишком несистемно поясняете, и это сильно мешает понять основную идею.
> Ничем помочь не могу. Либо вы имеете желание понимать, и поэтому вчитываетесь,
> и понимаете или задаёте вопросы, чтобы выяснить то, что неясно, либо
> помочь ничем не могу: если вместо того, чтобы выяснять у меня
> то, что вам непонятно, вы агитируете за питон, то наш разговор
> -- это разговор глухого с немым.Это воистину разговор глухого с кем-то ещё, если Вы не хотите понимать, что я *не агитирую* за Питон. Я объясняю, чем он, с моей точки зрения, хорош (в частности, лучше Ruby или Perl), чем меня не устраивают аналоги. Тем более, что Вы сами тут несколько циклов переписки устраивали подробное расспрашивание, что я собственно думаю.
Вы же сосредоточены на одном - что Питон плох. Вы пытаетесь это объяснить сравнением с одним, другим, третьим, но всё равно он Вам плох. Может, это действительно первичный фактор, а все попытки сравнения это попытки рационализации нерационального?> Меня бесполезно агитировать, и за апельсины, и за картошку с говяжьим стейком.
> И особенно за питон. Я равнодушен к процессу еды, воспринимаю его
> как надоевшую физиологическую потребность, поэтому мне практически без разницы, чем питаться.Где-то я это уже читал. "...Александр Иванович Корейко не ел, а питался. Он не завтракал, а совершал физиологический процесс введения в организм должного количества жиров, углеводов и витаминов..." Но даже в этом случае подбор оптимального сочетания компонентов еды полезен для организма, не так ли?
> А почему меня бесполезно агитировать за питон, я уже объяснял вам.
> Позвольте я не буду повторяться.Позволяю. Но и Вы тогда не агитируйте за Ruby или что там ещё, раз уж так это воспринимаете.
>[оверквотинг удален]
>>>> это лишь примеры, приведённые для пояснения различных моих высказываний.
>>> Вы слишком несистемно поясняете, и это сильно мешает понять основную идею.
>> Ничем помочь не могу. Либо вы имеете желание понимать, и поэтому вчитываетесь,
>> и понимаете или задаёте вопросы, чтобы выяснить то, что неясно, либо
>> помочь ничем не могу: если вместо того, чтобы выяснять у меня
>> то, что вам непонятно, вы агитируете за питон, то наш разговор
>> -- это разговор глухого с немым.
> Это воистину разговор глухого с кем-то ещё, если Вы не хотите понимать,
> что я *не агитирую* за Питон. Я объясняю, чем он, с
> моей точки зрения, хорош (в частности, лучше Ruby или Perl),Мне нравится ваш настрой. Но я вижу именно агитацию. То есть да, быть может я и глухой и слепой, но каждый раз когда я высказываю то, что меня не устраивает в питоне, вы начинаете рассказывать мне, почему вас это устраивает. Это ли не агитация? То есть с какой целью вы рассказываете мне об этом? Вы думаете, что мне очень интересно, что вам нравится, а что нет? Если да, то вы меня переоцениваете.
> чем меня не устраивают аналоги. Тем более, что Вы сами тут несколько
> циклов переписки устраивали подробное расспрашивание, что я собственно думаю.
> Вы же сосредоточены на одном - что Питон плох. Вы пытаетесь это
> объяснить сравнением с одним, другим, третьим, но всё равно он Вам
> плох. Может, это действительно первичный фактор, а все попытки сравнения это
> попытки рационализации нерационального?Может быть. Но если и так то "нерациональное" -- это прямое следствие опыта использования питона. С последующим опытом использования прочих языков в тех же целях. А сравнение -- единственный способ познать удобства и неудобства языка. Будь то python, ruby, javascript или bash. Не сравнив язык с другим (а лучше с несколькими), невозможно понять что в нём удобно или неудобно.
> Где-то я это уже читал. "...Александр Иванович Корейко не ел, а питался.
> Он не завтракал, а совершал физиологический процесс введения в организм должного
> количества жиров, углеводов и витаминов..." Но даже в этом случае подбор
> оптимального сочетания компонентов еды полезен для организма, не так ли?Да-да. Почти. С единственной разницей: Корейко питался, а не ел, поскольку (если память мне не изменяет) берёг здоровье своё. У него была цель, ради которой он отказывался от радостей жизни. Для меня же, этой радости просто не существует, и отказываться не от чего. Витамины же подсчитывать... Я ещё не в том возрасте, чтобы заботиться о своём здоровье, высчитывая что-то там на калькуляторе. Поэтому мне важнее эффективность удовлетворения потребности "здесь и сейчас."
>> А почему меня бесполезно агитировать за питон, я уже объяснял вам.
>> Позвольте я не буду повторяться.
> Позволяю. Но и Вы тогда не агитируйте за Ruby или что там
> ещё, раз уж так это воспринимаете.То есть не повторяться насчёт питона вы позволяете, но вынуждаете повторить, что фразу "руби ближе к идеалу чем питон" не стоит воспринимать как агитацию? Хорошо, повторю, раскрыв: это не агитация, а наилучший компромисс между лаконичностью высказывания своего мнения и информативностью. Ведь если я просто скажу: мне не нравится питон, это будет очень неконкретное высказывание, которое не даст никаких шансов собеседнику понять почему же так. Но если я приведу в качестве примера что-то (например, ruby), то зная это "что-то" собеседник без дальнейших объяснений поймёт, что именно в питоне мне не нравится. И такая лаконичность, на мой взгляд, гораздо лучше многословной конкретики не только тем, что мне меньше писать: собеседнику не придётся продираться сквозь килобайты текста, выясняя чем же какой-то там язык не нравится непонятно кому.
А ruby я выбрал в качестве языка для сравнения, потому что он вообще очень похож на питон. И сравнение с ним, наиболее рельефно показывает недостатки питона.
>> Это воистину разговор глухого с кем-то ещё, если Вы не хотите понимать,
>> что я *не агитирую* за Питон. Я объясняю, чем он, с
>> моей точки зрения, хорош (в частности, лучше Ruby или Perl),
> Мне нравится ваш настрой. Но я вижу именно агитацию. То есть да,
> быть может я и глухой и слепой, но каждый раз когда
> я высказываю то, что меня не устраивает в питоне, вы начинаете
> рассказывать мне, почему вас это устраивает. Это ли не агитация?Нет. Это обмен мнениями.
> То есть с какой целью вы рассказываете мне об этом? Вы думаете,
> что мне очень интересно, что вам нравится, а что нет? Если
> да, то вы меня переоцениваете.Вы подняли эту тему сами, начав рассказывать про недостатки. Тогда почему Вы удивляетесь, что Вам отвечают?
> Может быть. Но если и так то "нерациональное" -- это прямое следствие
> опыта использования питона. С последующим опытом использования прочих языков в тех
> же целях. А сравнение -- единственный способ познать удобства и неудобства
> языка. Будь то python, ruby, javascript или bash. Не сравнив язык
> с другим (а лучше с несколькими), невозможно понять что в нём
> удобно или неудобно.Я это не могу понять иначе, чем Питон Вам нанёс каким-то непонятным мне образом эмоциональную травму, и теперь Вы для дискуссии ищете любой вариант, с чем бы этаким его сравнить, лишь бы показать недостатки, а для практики - чем бы его заменить, лишь бы не использовать. Извините, но из данной дискуссии крайне сложно сделать иной вывод.
Если Вас вообще интересует другая (возможно, более адекватная) оценка Вашего подхода другими участниками форума, включая меня, то попробуйте объяснить свою позицию иначе.> Да-да. Почти. С единственной разницей: Корейко питался, а не ел, поскольку (если
> память мне не изменяет) берёг здоровье своё. У него была цель,
> ради которой он отказывался от радостей жизни. Для меня же, этой
> радости просто не существует, и отказываться не от чего.Простите, чего именно не существует - цели или радости?
>[оверквотинг удален]
>>> Позвольте я не буду повторяться.
>> Позволяю. Но и Вы тогда не агитируйте за Ruby или что там
>> ещё, раз уж так это воспринимаете.
> То есть не повторяться насчёт питона вы позволяете, но вынуждаете повторить, что
> фразу "руби ближе к идеалу чем питон" не стоит воспринимать как
> агитацию? Хорошо, повторю, раскрыв: это не агитация, а наилучший компромисс между
> лаконичностью высказывания своего мнения и информативностью. Ведь если я просто скажу:
> мне не нравится питон, это будет очень неконкретное высказывание, которое не
> даст никаких шансов собеседнику понять почему же так. Но если я
> приведу в качестве примера что-то (например, ruby),Проблема именно в том, что Вам не нравится питон не потому, что нравится что-то ещё, а потому, что не нравится питон. Потому Вы и ищете кучу вариантов, с чем бы его сравнить, а не что-то одно. Это именно попытка рационализации эмоционального. Я не вижу причин, почему это должно учитываться для работы других программистов.
> А ruby я выбрал в качестве языка для сравнения, потому что он
> вообще очень похож на питон. И сравнение с ним, наиболее рельефно
> показывает недостатки питона.Понятно, но всё равно не могу согласиться. См. выше.
>>> Это воистину разговор глухого с кем-то ещё, если Вы не хотите понимать,
>>> что я *не агитирую* за Питон. Я объясняю, чем он, с
>>> моей точки зрения, хорош (в частности, лучше Ruby или Perl),
>> Мне нравится ваш настрой. Но я вижу именно агитацию. То есть да,
>> быть может я и глухой и слепой, но каждый раз когда
>> я высказываю то, что меня не устраивает в питоне, вы начинаете
>> рассказывать мне, почему вас это устраивает. Это ли не агитация?
> Нет. Это обмен мнениями.Это хорошо. А то я уж начал подозревать худшее.
>> То есть с какой целью вы рассказываете мне об этом? Вы думаете,
>> что мне очень интересно, что вам нравится, а что нет? Если
>> да, то вы меня переоцениваете.
> Вы подняли эту тему сами, начав рассказывать про недостатки. Тогда почему Вы
> удивляетесь, что Вам отвечают?Не надо приписывать мне заслуг, которых за мной нет. Меня удивляет вовсе не то, что мне отвечают. Меня удивляет настойчивость, с который вы раз за разом повторяете мне своё мнение о питоне. Оно было ясно с самого начала, я даже там фразу оставил, чтобы вам было понятно, что до меня дошло ваше мнение. Но вы до сих пор не можете успокоится, и продолжаете мне это мнение рассказывать. Естественно, это удивляет. Точнее не удивляет, а озадачивает. И становится интересно, к чему же вы пытаетесь привести сию беседу, развивая её таким образом.
> Я это не могу понять иначе, чем Питон Вам нанёс каким-то непонятным
> мне образом эмоциональную травму, и теперь Вы для дискуссии ищете любой
> вариант, с чем бы этаким его сравнить, лишь бы показать недостатки,
> а для практики - чем бы его заменить, лишь бы не
> использовать. Извините, но из данной дискуссии крайне сложно сделать иной вывод.Нет, он не наносил мне травмы. Но и тем не менее, считать его удобным языком я не могу. Неожиданно, да?
> Если Вас вообще интересует другая (возможно, более адекватная) оценка Вашего подхода другими
> участниками форума, включая меня, то попробуйте объяснить свою позицию иначе.
>> Да-да. Почти. С единственной разницей: Корейко питался, а не ел, поскольку (если
>> память мне не изменяет) берёг здоровье своё. У него была цель,
>> ради которой он отказывался от радостей жизни. Для меня же, этой
>> радости просто не существует, и отказываться не от чего.
> Простите, чего именно не существует - цели или радости?Прощаю. Поясняю: ни того, ни другого. Но на будущее: не надо так обрезать цитату. В том, что вы процитировали, объяснено отсутствие радости. В хвосте же абзаца (который вы обрезали, цитируя), объяснялось отсутствие цели.
> Проблема именно в том, что Вам не нравится питон не потому, что
> нравится что-то ещё, а потому, что не нравится питон.Да. И никто, замечу, не в состоянии эту "проблему" решить, предложив мне удачную замену питону. Так что проблема, вероятно, шире и не сводится к одному питону.
> Потому Вы и ищете кучу вариантов, с чем бы его сравнить, а не
> что-то одно. Это именно попытка рационализации эмоционального. Я не вижу причин,
> почему это должно учитываться для работы других программистов.Фраза про работу других программистов, мне не совсем понятна. При чём тут программисты? "Другие" -- это относительно кого?
>> А ruby я выбрал в качестве языка для сравнения, потому что он
>> вообще очень похож на питон. И сравнение с ним, наиболее рельефно
>> показывает недостатки питона.
> Понятно, но всё равно не могу согласиться. См. выше.То что вы с этим не можете согласиться было понятно в самом начале треда. Где-то именно там мы с вами это выяснили. Непонятно, зачем вы теперь это повторяете? Надо ли воспринимать это как гнусные намёки на то, что у меня склероз?
>>> Это ли не агитация?
>> Нет. Это обмен мнениями.
> Это хорошо. А то я уж начал подозревать худшее."Худшее" это агитация?
> Не надо приписывать мне заслуг, которых за мной нет. Меня удивляет вовсе
> не то, что мне отвечают. Меня удивляет настойчивость, с который вы
> раз за разом повторяете мне своё мнение о питоне. Оно было
> ясно с самого начала, я даже там фразу оставил, чтобы вам
> было понятно, что до меня дошло ваше мнение. Но вы до
> сих пор не можете успокоится, и продолжаете мне это мнение рассказывать.Не продолжайте тему и не будет, на что отвечать.
> Естественно, это удивляет. Точнее не удивляет, а озадачивает. И становится интересно,
> к чему же вы пытаетесь привести сию беседу, развивая её таким
> образом.У меня нет никакой твёрдой направленности данного треда.
> То что вы с этим не можете согласиться было понятно в самом
> начале треда. Где-то именно там мы с вами это выяснили. Непонятно,
> зачем вы теперь это повторяете? Надо ли воспринимать это как гнусные
> намёки на то, что у меня склероз?Это надо воспринимать как стиль, который рекомендуется для облегчения чтения.
P.S. Кажется, тред выродился. Не вижу смысла продолжать.
>>>> Это ли не агитация?
>>> Нет. Это обмен мнениями.
>> Это хорошо. А то я уж начал подозревать худшее.
> "Худшее" это агитация?Нет.
> Не продолжайте тему и не будет, на что отвечать.
Как скажете.
>> Естественно, это удивляет. Точнее не удивляет, а озадачивает. И становится интересно,
>> к чему же вы пытаетесь привести сию беседу, развивая её таким
>> образом.
> У меня нет никакой твёрдой направленности данного треда.Твёрдой... Мягкой... Направленность треда -- это немного другое. Речь о целях, которые вы преследуете участвуя в нём. Очевидно, вы придерживаетесь какой-то определённой линии поведения. Странной на мой взгляд. Интересно было бы посмотреть, к чему таким образом вы надеетесь придти.
> P.S. Кажется, тред выродился. Не вижу смысла продолжать.
Мне так кажется, буквально с начала обсуждения. Отсутствие общепринятой фичи это никоим образом не преимущество. В этом могут быть плюсы, и могут быть даже существенные плюсы, заслуживающие того, чтобы не запиливать фичу. Но уже само по себе отсутствие -- это самым очевидным образом минус. И когда я читаю доказательства тому, что отсутствие кернел-спейс потоков -- это целая гора несомненных плюсов и ничего больше, естественно, вывод напрашивается один: тред выродился в демагогию.
>Это называется user-space cooperative threading. Такая хрень доступна и для C, например, >через библиотечку libpth. Но почему-то, никто не использует libpth, предпочитая >libpthread. Странно да? Вот несмотря на все преимущества кооперативной многозадачности, >например, отсутствие необходимости в реентерабельности кода (что существенно упрощает >синхронизацию нитей), несмотря на то, что при кооперативной многозадачности стоимость >нити минимальна, и процесс легко может позволить наплодить себе десять тысяч нитей (на >каждый открытый файловый дескриптор сокета по нити) и не положить систему... Несмотря на >всё это почему-то в C кооперативная многозадачность непопулярна.
>Странно при этом, что, например, Haskell, зачем-то в дополнение к юзер-спейс потокам, в >библиотеках есть и ядерные потоки. Странно, что Microsoft, при создании Windows '95 >отказалась от корпоративной многозадачности, используемой в предыдущих версиях Windows в >пользу вытесняющей. Чего ж это им всем так не нравится корпоративная многозадачность, а?Есть целые операционные системы где нет вытесняющей многозодачности в потоках или даже в процессах операционной системы. И количество ядер, а иногда даже и сокетов в этих системах бывает больше единицы. При этом там есть C, Python и Java, только программы там работают не совсем так как думает пргораммист, не знакомый с системой.
Все-таки, когда язык скрывает от программиста всю подноготную - это оболванивает. К хорошему быстро привыкаешь и начинаешь воспринимать как должное любую фишку библиотеки расширения языка.
>>Это называется user-space cooperative threading. Такая хрень доступна и для C, например, >через библиотечку libpth. Но почему-то, никто не использует libpth, предпочитая >libpthread. Странно да? Вот несмотря на все преимущества кооперативной многозадачности, >например, отсутствие необходимости в реентерабельности кода (что существенно упрощает >синхронизацию нитей), несмотря на то, что при кооперативной многозадачности стоимость >нити минимальна, и процесс легко может позволить наплодить себе десять тысяч нитей (на >каждый открытый файловый дескриптор сокета по нити) и не положить систему... Несмотря на >всё это почему-то в C кооперативная многозадачность непопулярна.
>>Странно при этом, что, например, Haskell, зачем-то в дополнение к юзер-спейс потокам, в >библиотеках есть и ядерные потоки. Странно, что Microsoft, при создании Windows '95 >отказалась от корпоративной многозадачности, используемой в предыдущих версиях Windows в >пользу вытесняющей. Чего ж это им всем так не нравится корпоративная многозадачность, а?
> Есть целые операционные системы где нет вытесняющей многозодачности в потоках или даже
> в процессах операционной системы. И количество ядер, а иногда даже и
> сокетов в этих системах бывает больше единицы. При этом там есть
> C, Python и Java, только программы там работают не совсем так
> как думает пргораммист, не знакомый с системой.
> Все-таки, когда язык скрывает от программиста всю подноготную - это оболванивает. К
> хорошему быстро привыкаешь и начинаешь воспринимать как должное любую фишку библиотеки
> расширения языка.К чему вы этот пассаж оставили тут? К тому, что я, используя linux на платформе amd64, обязан ориентироваться в других платформах, для того, чтобы меня не обвинили в том, что я "оболванен"? Или я не правильно понял? Поясните, пожалуйста.
> это утиная типизация!таже Java при компиляции выдаст ошибку - нет такого класса, нет таких параметров (интерпретатор тоже так может:))
> сделана специально для удобства!
Python? Python ничего не скажет пока не грохнется при выполнении. очень удобно. согласен.
> GIL ускоряет Python (а не замедляет его)
вот именно, что Python
> внутри многонитевой Python-программы вся математичка остаётся последовательной, а ввод-вывод паралелльный
очевидно ввод-вывод реализован на C/C++ средствами ОС? :)
> куда не поворотливый?
не хотелось писать медленный
> 1. ...встраивать внутрь C/C++ программы.
> 2. ...расширять его модули за счёт C/C++-кода.не проще написать все на C/C++?
>> это утиная типизация!
> таже Java при компиляции выдаст ошибку - нет такого класса, нет таких параметров (интерпретатор тоже так может:))читая эти сообщени форумов -- у меня иногда создаётся такое впечатление что программисты статически-типизируемых языков -- БЫСТРЕЙ БЫСТРЕЙ БЫСТРЕЙ (на БЕШЕННОЙ СКОРОСТИ) печатают огромные абзацы кода...
...а потом просят компилятор найти ошибки :)
[обычно эти языка многословны. так что не странно, если так]
блин.. ну конешно я понимаю что компилятор находяит эти ошибки... но ведь наверняка 95% ошибок которые находит компилятор -- это ошибки которые вызванны именно много словностью синтаксиса!
полезность этих синтаксических анализаторов сводится к той аналогии как еслибы я сказал:
"""
* компьютер это очень полезая вешь, так как он может обнаруживать компьютерные вирусы!* автомобиль это очень полезная вешь, так как автомобиль может быстро довезти водителя до ГАИ!
"""ну как-то так :-) :-)
Что за чушь? Как удобно сразу же видеть в какой строке опечатался. Отчасти это связано с IDE
ненавижу IDE
Или. Нет у тебя такого класса (во время выполнения). Фигак. Или. Что ты мне подсовываешь два параметра, давая пять. Фигак вылет или исключение. Но это на действительно больших проектах. Простенькие скрипты пишу на Python с удовольствием. Пробую какие-то идеи иногда.
> Простенькие скрипты пишу на Python
> с удовольствием. Пробую какие-то идеи иногда.ну так-то всё правильно. только как-бы оно так не получилось, что если взять "сложую" программу и переписать её из <название-энтэрпрайзого-языка> в Python -- то получится "простенький скрипт" :-) [убрав по-ходу-дела кучу кода отвечающего за объектно-ориентированность алгоритма, переписав всё это в функцинальный стиль] ..
> то получится "простенький скрипт" :-)В котором будаки типа вас забили даже на обработку ошибок и прочая. Поэтому какой-нибудь скрипт системного апдейтера убунты не найдя каких-то файлов локали просто виснет колом навечно. Успев переключить репы, но не успев сделать апгрейд системы. Потому что питонист вообще не знает что за фигня - I/O error и его обработка.
В общем приходится выискивать все проблемные места вручную самому.
с ненавижу загнул. на нем хорошо писать простенькие вещи. пробовать какие-то идеи. раздражает маниакальное пристрастие писать на нем все.
> т.е.: внутри многонитевой Python-программы вся математичка остаётся
> последовательной, а ввод-вывод паралелльный.Вот только обычно все упиратеся в ввод-вывод и параллелить его толку мало. А иногда и сплошной вред, например на механическом винчестере.
Вообще-то я обычно как раз способные параллельно выполняться задачи распараллеливаю. С Python это не возможно, так как всегда выполняется только один поток и это очень очень очень расстраивает
>> т.е.: внутри многонитевой Python-программы вся математичка остаётся
>> последовательной, а ввод-вывод паралелльный.
> Вот только обычно все упиратеся в ввод-вывод и параллелить его толку мало.
> А иногда и сплошной вред, например на механическом винчестере.ну это вредно конешно для механники.
но что касается производительности -- попробуй сам же и вдумайся в свои слова -- "обычно все упиратеся в ввод-вывод"!
как минимум в многонитевых программах написанных на Python -- Математика работает в ПАРАЛЛЕЛЬНОЙ ните относительно нитей ввода-вывода! и механизм GIL это ни как это НЕ ухудшает.
таким образом в случае если "все упиратеся в ввод-вывод" -- то совершенно пофигу паралельная ли математика или не паралельная. (главное чтобы Математика не мешала вводу-выводу. а она как раз и НЕ мешает в случае с GIL Python).
Математика не параллелится ЛИШЬ ТОЛЬКО ОТНОСИТЕЛЬНО СЕБЯ САМОЙ.
# P.S.: блин, почему я всё это так разжовываю? неужеле нельзя самим поглядеть как работает GIL? вот вы вбили себе в голову что якобы активна только одна нить и всё. даже не пытаетесь проверить это на практике, например, тэстом каким-нибудь.
> Python простой язык. ужасная реализация. неповоротливый интерпретатор. отсутствие многопоточности
> из-за GIL.Вам религия запрещает применить модуль multiprocessing?
> в любой момент только один поток активен. для большого
> проекта трудно отлаживаемый.Это в чём же он трудно отлаживаемый?
> при смене имени класса или параметров не выдает
> ошибок.Тесты надо писать независимо от языка. А покрытое тестом не имеет таких проблем.
> нужно многое в голове держать.
Подробнее, пожалуйста.
> второй год по работе приходится
> писать. ненавижу.А я - ну не обожаю - но для массы типичных задач не вижу ничего лучше.
Потому что его просто нет.
Так что как средство сложного скриптования по умолчанию Python - лучший среди имеющегося.
> Вам религия запрещает применить модуль multiprocessing?Вам объяснить чем процесс отличается от потока? Стандартная отмазка питониста. Вместо нормальной реализации интерпретатора сделали костыль.
> Тесты надо писать независимо от языка
На все функции? O_o
> Так что как средство сложного скриптования по умолчанию Python - лучший среди имеющегося.
Думал над этим. Scala. JVM не страдает от GIL
http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t... производительность Python3 просто чудовищна http://www.rsdn.ru/article/scala/scala.xml#EZF скрипты на Scala
Другое дело, что порог вхождения у Scala выше.
Может даже rdmd (компиляция на лету).
>> Вам религия запрещает применить модуль multiprocessing?
> Вам объяснить чем процесс отличается от потока?Объясните. В частности, насколько эти различия существенны при работе через блок разделяемой памяти. А также, почему существуют вызовы rfork() и clone() с массой промежуточных между процессом и тредом вариантов.
> Стандартная отмазка питониста. Вместо нормальной
> реализации интерпретатора сделали костыль.<mode="mirror">Стандартный наезд того, который сам не знает, чем и как процесс отличается от треда (особенно в Unix-системах).</mode>
Прежде чем говорить о "нормальной" реализации, надо определить критерии нормальности. Я не вижу никакого смысла в требовании их определения как "для ОС это один процесс", в условиях, когда собственно ОС такие различия пофиг почти во всём.
>> Тесты надо писать независимо от языка
> На все функции? O_oЭто отдельный огромный вопрос. Но вкратце - BDD наше всё, плюс соображения автора кода о том, где могут быть острые углы.
>> Так что как средство сложного скриптования по умолчанию Python - лучший среди имеющегося.
> Думал над этим. Scala. JVM не страдает от GIL
> Другое дело, что порог вхождения у Scala выше.Он очень сильно выше, в этом и проблема. И REPL у него нет, а для средства такого типа это обязательное условие.
Накладные расходы на процесс. Иногда существенно иногда нет.
>И REPL у него нет, а для средства такого типа это обязательное условие.REPL у scala в наличии.
Языки сами по себе примерно одинаковые, состоят из N (~100) ключевых слов и символов, плюс N (~20) конструкций исключая конечно всякие asm и брейнфаки...
А запросы чаще всего связаны с поиском решений каких либо задач а не с самим языком.1. Например: в спавочник яваскрипта заглядываешь редко, но на jquery.com частенько. В справочник по php/perl/python/rubi редко, а ищещь какую-нибудь либу чаще, или например запрос в MySQL/PosgreSQL и т.д.
2. К тому же рейтинг не учитывает собственно библиотеки языков. В том же перле нету смысла ходить в гугл если есть cpan.org
Вообщем я бы рейтинг рассматривал с точки зрения начинающих программистов. Так сказать общие тенденции куда сейчас идет народ. Но это ни в коей мере не показатель сколько им _уже_ пользуются, и насколько он _уже_ популярен.
Ну вот по плюсам показательно - это ж явно народ ринулся C++11 осваивать
> Ну вот по плюсам показательно - это ж явно народ ринулся C++11 осваиватьНу а что, очеловечили малость - результат налицо. А си хороши сами по себе. В своих нишах они просто как рыба в воде.
> Количество запросов зависит не только от популярности, но и от гемморойности языка. Думаю, именно с этим связано опережение Perl JavaScript.Такое мог написать только тот кто ни одного из них не знает, хехе
Воистину. Сейчас как раз на обоих пишу...
Тогда brainfuck должен быть в тройке. :)
> Perl популярнее JavaScript и Ruby - мощно задвинули, внушает.
> Бейсик растёт. Видимо, к дождю... Как они, кстати, Бейсик вычленяют из запросов?
> Как отличают ruby и рубин, python от удава и т.д.?Вот методика - http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_d...
Так себе методика, прямо скажем...
Для коррекции используют ограничения категорий поиска в поисковой машине, и некий субьективный % релевантности. Есть альтернативные оценки - основанный на Google trends PYPL например - https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY...
У них правда 'C# is the "language of the year"' :)
> например - https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY......эталонный притон питонистов. Все за PyPy-кали. Не стуль мышления а Pyздец!
И вот это-то крайне странно, я нащщёт JavaScriptа. На фоне ноды и пакетов для нее, что-то как-то маловероятно, не?
Собственно, табличка показывает, что новички хватаются теперь не только за Андроид, но и за iOS. Причем желательно одновременно.
Стараясь не повторять одну и ту же работу на двух языках (Java и Objective C), они стараются писать код, который может быть использован под обеими платформами (на С / С++).
Интересные мобильные платформы отвлекли быдлокодеров от формоклепания (падение С#).
Вот и все тенденции. Предсказать их можно было без всякого анализа запросов...
…и тем не менее ты не высказал предсказания всех этих тенденций до этого анализа запросов. Ты уверен, что всё, что ты высказал — не рационализация?
С плюсами проще. Они язык не модный, на них просто пишут. СЧоответственно новичков там довольно мало. Но вот появился 11-й стандарт. Люди пытаются его освоить. А плюсовиков мноого...
Плюсы и просто С еще и часто входят в учебную программу. Поэтому гуглят по ним много.
Но это количество от веяний моды не меняется.
Тенденции - не в графике, а в первой-второй производной к нему ;)
> Собственно, табличка показывает, что новички хватаются теперь не только за Андроид, но
> и за iOS. Причем желательно одновременно.
> Стараясь не повторять одну и ту же работу на двух языках (Java
> и Objective C), они стараются писать код, который может быть использован
> под обеими платформами (на С / С++).Отличная иллюстрация к термину "мнение дилетанта", спасибо!
>> Собственно, табличка показывает, что новички хватаются теперь не только за Андроид, но
>> и за iOS. Причем желательно одновременно.
>> Стараясь не повторять одну и ту же работу на двух языках (Java
>> и Objective C), они стараются писать код, который может быть использован
>> под обеими платформами (на С / С++).
> Отличная иллюстрация к термину "мнение дилетанта", спасибо!ДЫк ничо как бы удивительново с Объетками С и нету, стока с етим АйФоном носились, уши все прожужжжали
> Отличная иллюстрация к термину "мнение дилетанта", спасибо!ну ка, давай, покажи нам не дилетантское мнение.
> Собственно, табличка показывает, что новички хватаются теперь не только за Андроид, но
> и за iOS. Причем желательно одновременно.
> Стараясь не повторять одну и ту же работу на двух языках (Java
> и Objective C), они стараются писать код, который может быть использован
> под обеими платформами (на С / С++).
> Интересные мобильные платформы отвлекли быдлокодеров от формоклепания (падение С#).
> Вот и все тенденции. Предсказать их можно было без всякого анализа запросов...Если сходить по ссылке и посмотреть внимательно, то видно, что изменения популярности C++ невелики, а вот Objective-C как паровоз летит вперёд, причём уже два года подряд он признан языком года по версии TIOBE (он больше всех увеличил свою популярность за год). На фоне всего этого ваши рассуждения выглядят несколько сомнительными.
И насчёт "формоклепания", кстати тоже: Visual Basic.NET популярность стремительно набирает.
Я вам даже могу соообщить вопрос года, который привел к такому всплеску запросов по Objective C.
Вопрос звучит обычно так: "А вашу программу можно запустить на iPad или iPhone?"
К VB я, к счастью, не имею никакого касательства, поэтому задумываться о его популярности даже не собираюсь.
> Я вам даже могу соообщить вопрос года, который привел к такому всплеску
> запросов по Objective C.
> Вопрос звучит обычно так: "А вашу программу можно запустить на iPad или
> iPhone?"
> К VB я, к счастью, не имею никакого касательства, поэтому задумываться о
> его популярности даже не собираюсь.LoL. Вы читали только мой коммент, или так же читали коммент на который я отвечал? Давайте мы определимся, кто с кем и о чём спорит.
Я выступал, излагая мнение, почему неверно следующее рассуждение:
> Собственно, табличка показывает, что новички хватаются теперь не только за Андроид, но
> и за iOS. Причем желательно одновременно.
> Стараясь не повторять одну и ту же работу на двух языках (Java
> и Objective C), они стараются писать код, который может быть использован
> под обеими платформами (на С / С++).
> Интересные мобильные платформы отвлекли быдлокодеров от формоклепания (падение С#).
> Вот и все тенденции. Предсказать их можно было без всякого анализа запросов...Как вы правильно подметили, опровергать это мнение можно, надавив на объективность исходного исследования. Но почему тогда, вы спорите со мной, а не с автором того коммента? Вы пытаетесь опровергнуть моё опровержение, приведя ещё более жёсткое опровержение исходного сообщения? Вам не кажется, что логика сего излишне запутана, чтобы служить блестящей демонстрацией вашего ума и сообразительности?
[upd] Ох, я даже не обратил внимания, что вы тоже автор исходного сообщения. М-м-м... Вы точно не хотите обратиться к специалисту, который может изложить азы логического мышления?
Я читал свой коммент и совершенно с ним не спорю.
Мне, как человеку, реально вынужденному заниматься портированием на мобильные устройства и повышать то самое количество запросов по четырем языкам сразу, мои комментарии представляются вполне логичными.Попробую разжевать на уровне столь любимых вами азов: даже если вы нормальный человек и пишете нативный код на С / С++, запустить его на планшетах без обвязки на Java или Objective C довольно проблематично. Так что ваше гугление незначительно поднимет результаты по С / С++, и так имеющим высокие позиции, но вполне может сделать Objective C (никому, кроме маководов, не упершийся) языком года.
> Я читал свой коммент и совершенно с ним не спорю.
> Мне, как человеку, реально вынужденному заниматься портированием на мобильные устройства
> и повышать то самое количество запросов по четырем языкам сразу, мои
> комментарии представляются вполне логичными.
> Попробую разжевать на уровне столь любимых вами азов: даже если вы нормальный
> человек и пишете нативный код на С / С++, запустить его
> на планшетах без обвязки на Java или Objective C довольно проблематично.
> Так что ваше гугление незначительно поднимет результаты по С / С++,
> и так имеющим высокие позиции, но вполне может сделать Objective C
> (никому, кроме маководов, не упершийся) языком года.А... Я, кажется, начинаю понимать вашу позицию. Извините, за то, что тем не менее я продолжаю переходить на личности, но проблема ваша не в отсутствии логики, а в неумении излагать свои мысли. Да, а за необоснованные (как выяснилось) подозрения в отсутствии логического мышления, я приношу свои извинения. Был неправ, каюсь.
Я просто стараюсь быть кратким. Вы же возражали на то, чего в моем комментарии просто-напросто не было. Это отсутствующее мы с вами додумывали по-разному, из-за этого и произошло непонимание.
Я сверяюсь по indeed.com/jobtrends, а эта статистика лажа полная
Я сверяю по tiobe.com, а эта статистика лажа полная
Молодец!
вот и на www.google.com/trends картина совершенно иная, чем в новости
пущай методику свою публикуют, а то как-то довверия не внушает
> вот и на www.google.com/trends картина совершенно иная, чем в новости
> пущай методику свою публикуют, а то как-то довверия не внушаетНу так давно публикуют - http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_d...
Так себе методика, но тем не менее...
Все логично.З. Ы. Будет чем потроллить Java-филов, а точнее тех из них, которые кроме Java ничего не видели :)
Этой статистикой кого-то троллить - слоновья толщина.
А что жаба, жаба стабильна (на уровне погрешности), никто никуда не бежит, никто никуда не набегает. Удивило сильное падение шарпа только.
> Удивило сильное падение шарпа только.Это дух вендекапца.
ничего-ничего - подождите выхода Java 8, тогда посмотрим, кто кого затроллит :)
> На две позиции вниз упала популярность языка C#Просто отличная новость!
Популярность дерьмонета падает вместе с windoze!
Количество поисковых запросов коррелирует не только с популярностью языка, но и с количеством геморроя которое порождает использование оного, и ради избавления от которого кодер люто гуглит. Причем чем меньше доступно решений тем кодер гуглит бешенней.Поскольку 20% населения как известно выпивают 80% производимого пива выборку релевантной считать низзя.
> Количество поисковых запросов коррелирует не только с популярностью языкаЛажа.
Гиморными языками в массе поросту не пользуются - где хаскель, на каком месте?
Или скала?
Так уж получилось, что хаскель и скала — не геморные языки.
Сие не геморные языки. Я на сях и языках алгольной группы кодю уже лет 15 как, но до сих пор без гугля и пары-торйки тыков не могу описать на сях тип указателя на массив указателей на структуры, содержащие указатели на функции с определенными прототипами. Или когда мне надо расположить структуру по абсолютному адресу в памяти без трюкачества. А на языках алгольной группы (на той-же аде или модуле-2) я делаю это с первой попытки просто по аналогии без заглядывания в ламерку и с первого раза попадаю.Я удивляюсь как пёрл на первое место не вышел, вот уж где существует стопицот способов сделать очевидную вещь черезжопным способом.
В итоге языками алгольной группы я пользуюсь на круг чаще, но по ним гуглю намного реже.
Эм... Такое, в общем-то, за раз описывать и не надо. У вас же там сущности какие-то? Вот и объявите их отдельно, с именами, чтобы было понятно, о чём оно. Тогда и читателю проще. насчёт структуры по абсолютному адресу не скажу - не надо было, но по идее же один раз макрос под это дело пишется?Это не то чтобы в защиту плюсов (я их как раз за примитивизм не особо люблю) - просто не пойму, зачем это гуглить сто раз.
> Сие не геморные языки. Я на сях и языках алгольной группы кодю
> уже лет 15 как, но до сих пор без гугля и
> пары-торйки тыков не могу описать на сях тип указателя на массив
> указателей на структуры, содержащие указатели на функции с определенными прототипами.
> Или когда мне надо расположить структуру по абсолютному адресу в памяти
> без трюкачества.Неудачные примеры. Про структуру по адресу: её не надо располагать, надо приводить тип указателя. А про указатель на структуру, указателей на функции, указателей на структуры, выше правильно написали, не надо забывать про существование typedef.
Зато я могу предложить другой пример, демонстрирующий неудачности синтаксиса: слово const. Попробуйте-ка объявить константный указатель на неконстантный массив константных строк. Слабо?
> В итоге языками алгольной группы я пользуюсь на круг чаще, но по
> ним гуглю намного реже.Странно, что это так. Ведь постоянно приходится искать в гугле какие-нибудь библиотеки, описания этих библиотек, куски кода для копипасты, и прочая, и прочая. Вы что, пользуясь языками алгольной группы, на постоянной основе используете C'шные библиотеки?
Понятная и хорошая библиотека идет с читабельной докой и стопятистами примерами. А системную как правило и так помнишь на память.Мне приходится как правило гуглить чтобы понять какого насыпать синтаксического сахару если он сыпется неочевидным образом. В сях очень много таких нелогичностей.
Самый простой (правда несколько притянутый за уши, но тем не менее) пример. Обращение к структуре по имени и через разыменовывание указателя. Если на алгольном языке мне достаточно знать что разыменовывание указателя делается через ^, взятие адреса через @ а обращение к полю структуры или юниона через . то я не грея голову пишу ptr^.field когда разыменовываю указатель, и foo.field когда обращаюсь в адрес. Или @foo^.field если мне хочется странного, но это по крайней мере все равно очевидно, логично и всегда так а не иначе, вне зависимости от контекста. Надо два указателя разыменовать ptrptr^^.field. Надо три - ptrptrptr^^^.field.
А на сях тех-же самых синтаксис выходит разный, и я, зная, что указатель разыменовывается через * а обращение к полю через . внезапно должен писать ptr->field разыменовывая указатель и foo.field обращаясь в символическое имя (чудны дела твои господи). Двойной указатель будет уже *ptrptr->field, а не, внезапно, ptrptr->->field как бы можно было логически предположить. Интуитивность такой записи за гранью добра и зла. То есть вместо того чтобы помнить два правила которые применимы везде я должен помнить уже три которые применимы каждое в своем случае, причем там где двух по идее вполне достаточно. А голова то не резиновая, а это самый простой пример который только удумать можно.
Когда существует куча одинаковых но разных правил, употребимых в одинаковых, но разных контекстах, тогда и приходится ломать голову как правильно покрошить из них нужный винегрет, и гуглить на предмет того, как же блин там коран то это учит делать в данном конкретном случае.
Хотя мож я просто дурак и у меня в голове ничего не держится =)
> Понятная и хорошая библиотека идет с читабельной докой и стопятистами примерами. А
> системную как правило и так помнишь на память.Да, наверное. Это вероятно дело личных предпочтений, но я читаю доки в интернете: быстрее найти и открыть мануал через гугл, нежели искать его на диске. Собственно, в моей домашней генте, я несколько лет назад удалил флаг doc из глобальных USE флагов, поскольку вся документация к библиотекам лежала на диске бесполезным грузом.
Но, помимо этого, сначала ведь надо найти эту понятную и хорошую библиотеку, причём для этого надо перебрать, просмотреть и отринуть несколько непонятных и плохих библиотек.> А на сях тех-же самых синтаксис выходит разный, и я, зная, что
> указатель разыменовывается через * а обращение к полю через . внезапно
> должен писать ptr->field разыменовывая указатель и foo.field обращаясь в символическое
> имя (чудны дела твои господи). Двойной указатель будет уже *ptrptr->field, а
> не, внезапно, ptrptr->->field как бы можно было логически предположить.Если это вызывает проблем, то можно писать вместо ptr->field так: (*ptr).field. И указатели высших порядков тогда используются по той же схеме: (**ptr).field, (***ptr).field и тп. Тот же самый паскаль, но вместо ^ ставим * и порядок символов другой. А оператор -> лишь, как вы правильно назвали, синтаксический сахар, позволяющий уменьшить количество * перед ptr. В большинстве ситуаций уменьшить количество до нуля, и, вероятно, именно красота и законченность этого нуля и явился причиной введения такого оператора в язык.
> [...]
> Хотя мож я просто дурак и у меня в голове ничего не
> держится =)Я думаю дело не в личных свойствах интеллекта. Дело лишь в том, что на C вы пишите редко. Причём вам не доводилось читать чужой код. Ну или доводилось, но иногда, нерегулярно и понемногу.
Такие проблемы стандартны: когда влезаешь в незнакомый язык, начинаешь спотыкаться о каждую мелочь, потому что тот раздел мануала к языку ещё не прочитан, или потому что он после прочтения успешно забыт, или потому, что в мануале явно не описана какая-то тонкость, а прочтение по диагонали не подразумевает вдумчивого восприятия информации.
Я точно так же буду спотыкаться, если мне приспичит писать под какой-нибудь там gnat или fpc. Я точно так же спотыкаюсь, когда суюсь в схему после коммон лиспа. Когда не пользуюсь пару-тройку лет python'ом/ruby/чем-угодно-ещё, а потом вдруг что-то начинаю на нём ваять.
Ну вот есть же JavaScript ... сам язык убогий да и глюки в реализации под разные браузеры ... и тем не менее все пользуются ибо альтернатив запустить какую нить менюшечку на страничке просто нету.
Dart. не пробовал. помнится переводит код в JavaScript
Оно монструозное и экспериментальное. В этом плане MS-овский вариант куда интереснее - оверхеда 0 и по фичам вкуснее - в частности, легко интегрируется с существующим JS, позволяя его аннотировать.
Тем не менее m$-овский вариант распространения не получит по очевидным причинам.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
Erlang - 31, Haskell - 32, Scala - 33
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
> Erlang - 31, Haskell - 32, Scala - 33А Tcl 49-ый. При этом, проектов на haskell/erlang существенно меньше, имхо. Да и вообще языки скорее эзотерические, нежели коммерческие. С другой стороны, какой смысл гуглить по языку, документация к которому сосредоточена либо в man 3tcl $command, либо на wiki.tcl.tk? Аналогично для python/perl/ruby. Статистика из серии "не пришей кобыле хвост".
> Количество поисковых запросов коррелирует не только с популярностью языка, но и с
> количеством геморроя которое порождает использование оного, и ради избавления от которого
> кодер люто гуглит. Причем чем меньше доступно решений тем кодер гуглит
> бешенней.
> Поскольку 20% населения как известно выпивают 80% производимого пива выборку релевантной
> считать низзя.Есть мнение, что Парето-отношение просто троллинг переменной толщины, ни в коей мере не являющийся объективным законом. И даже на закономерность не тянущим.
> Количество поисковых запросов коррелирует не только с популярностью языка, но и с
> количеством геморроя которое порождает использование оного, и ради избавления от которогоЛол, еще один дилетант. Ты для iOS/OSX писал?
Апле с каждым годом улучшает язык, добавляя новые фичи, которые помогают решать проблемы донимавшие ранее. Кроме того xcode организован так что весь хелп ты получаешь очень легко без гуглений.
> Количество поисковых запросов коррелирует не только с популярностью языка, но и с
> количеством геморроя которое порождает использование оного, и ради избавления от которого
> кодер люто гуглит. Причем чем меньше доступно решений тем кодер гуглит
> бешенней.
> Поскольку 20% населения как известно выпивают 80% производимого пива выборку релевантной
> считать низзя.Скала - роксь! Хаскель фарева :)
А если серьезно, ну кому етот Хаскель смешной вперся? Смысл криптовать на нем какой, кроме тешения самолюбия? :) Следующий прогрраммист же обязательно перепишет с нуля; вспоминается П. Грэм со своим Вебпорталом на Лиспе: пришла Яху и переписала по-быстрому ВСЕ-ТО ЖЕ и на Яве. Из чего делается вывод, что написанное на Хаскеле легко и непринужденно, совершенно читабельно и всеми-легко-сопровождаемо можно переписать... да даже на Бейсико-Явах :) И ведь с точки зрения БИЗНЕСА (!) - это самое обоснованное...
Все было, все это уже было.. :)
> Причем чем меньше доступно решений тем кодер гуглит бешенней.я бы выбросил язык по которому нет решений проблем.
Lisp на 13ом месте, уже неплохо
> Lisp на 13ом месте, уже неплохоТам ниже ещё есть Common Lisp. Мне вот интересно, строчка Lisp включает в себя достижения Common Lisp'а, или, по мнению TIOBE, Common Lisp -- это не Lisp?
ps. Да, если просуммировать достижения Lisp и Common Lisp, то Lisp оказывается на 12 месте. =)
тоже интересно. Scheme наверное тоже не попал в категорию Lisp.
Херня этот рейтинг.JavaScript тренд, JQuery в частности.
Objective-C тренд, но никак 10% ни использования, ни интереса не может быть.
Basic 7-ое, ну-ну.
Ну и С на первом как бы намекает на полное отсутствие релевантности.
> Objective-C тренд, но никак 10% ни использования, ни интереса не может быть.Ты отстал от жизни.
Айпады и прочая подобная фигня уже везде.
> Ну и С на первом как бы намекает на полное отсутствие релевантности.Смешно. Кроме "трендовых" веб-приложений и всякого вашего Ынтерпрайза есть огромный мир embedded (надо пояснять, что софт сейчас есть и в копеечных детских игрушках и в утюгах и холодильниках не говоря уже о более традиционных и специфических вещах?). Угадайте, на чем же там пишут софт? Есть, есть там и javascript - в каждом встроенном веб-сервере пара скриптов всегда найдется, правда он там "зашит" зачастую в виде С-шных строк, но это ведь тоже считается?
А что так все взъелись на бейсик? В школах только его и проходят... по всему миру... и лишь немногие из них станут программистами... Но скока поисковых запросов перед контрольными/экзаменами по информатике =)
От бэйсика рождаются быдлокодеры макросов и опытные пользователи эксель(tm)
От бейсика рождается возможность для пользователя автоматизировать свою работу. Что прекрасно, по-моему.
> От бейсика рождается возможность для пользователя автоматизировать свою работу. Что прекрасно,
> по-моему.Да, если бы это давало независимость от платформы.
а как же ассемблер ?
Две стрелочки вверх! ;-)
Он вне конкуренции.
судя по графику, точность измерений где-то в районе ±1-2%
а где 1с?
Действительно, где?
именно там
в мировом рейте его не будет.
Настанет ява капец, будет счастье!
А мне всё равно )) Пишу на том, на чём мне надо.
http://www.ioncannon.net/projects/code2012/ тут твиттероюзеры забавный рейтинг устроили
С Си всё понятно это классика, но неужели джава всё ещё модный язык!
Модный не Джава -- а Андроид! Где и лицензию за 100 баксов не нужно покупать в отличаи от Айяйпада-йте...
Ну, тогда всё сходиться, андроид в моде, язык для кофеварок тоже в моде.Айпад в моде Objective-C тоже в моде.
Вышла Виндоус 8 через год график должен покажет какая платформа в моде
> Вышла Виндоус 8 через год график должен покажет какая платформа в модеВиндус 8 в моде явно не будет. Потому что страшенное уродство. Гунявый планшет и отстойный десктоп - два в одном!
ни на что Win8 не повлияет. вместе с падением продаж PC падают продажи OS. к тому же ОС ужасна. есть опыт использования. Surface не прижился. WP тоже не особо. кстати это не первая попытка одна ОС для всего. была еще с Windows Mobile
> ни на что Win8 не повлияет. вместе с падением продаж PC падают
> продажи OS. к тому же ОС ужасна. есть опыт использования. Surface
> не прижился. WP тоже не особо. кстати это не первая попытка
> одна ОС для всего. была еще с Windows MobileХоливарная тема, так что лучше дождаться нового года и посмотреть что из этого выйдет, а не гадать на кофейной гуще
Никчему ждать, гадать, уже достаточно статистики - windoze 8 распространяется много хуже висты.
Surface вообще не продаётся.
Кстати Win9 будет просто обновлением
Похоже на заказной рейтинг вроде опросов ВЦИОМ или ФОМ. Интересует заказчик этого рейтинга...
Деннис Ритчи перед смертью проплатил рейтинг на 5 лет вперёд.
> TIOBE .. строит свои доводы по изменению интереса к языкам, на основе анализа статистики поисковых запросовЛюди массово ищут инфу, потому что язык:
1) действительно популярен
2) гемморойныйИ как прикажите трактовать табличку?
> Люди массово ищут инфу, потому что язык:
> 1) действительно популярен
> 2) гемморойный
> И как прикажите трактовать табличку?Популярен, но гемморойный )
> Популярен, но гемморойный )Тогда выводы напрашиваются такие:
1) Си самый популярно-геморойный язык
2) Руби наиболее понятный и незаслуженно обделенный вниманиемКороче, не зря я пишу на Руби )))
> И как прикажите трактовать табличку?чем сложнее и мощнее, тем больше траблов.
зависимость геометрическая...
> чем сложнее и мощнее, тем больше траблов.Пруфы есть или так сбзднул?
если язык популярен, то он конечно геморойный. Потому что безгеморойный язык это тот, на котором не пишут. Это как идеальный муж: не пьет, не курит, не смотрит футбол и не существует.
О, я, оказывается, идеальный муж... Где сертификат идеальности получить?
Хотя, в принципе, меня и справка о несуществовании устроит. Для налоговой ;)
Ура в слудующем году (Visual) Basic , будет на 4 месте а то и на первом. Слава TIOBE, и самому шизанутому рейтингу который я виде в IT.
где nodejs ?
Я подумывал о питоне, чтоб не заморачиваться на Си. Передумал. Я прав?
Нет. Надо не подумывать и спрашивать, а пробовать и формировать собственное мнение.
