форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от opennews (ok) on 08-Янв-13, 13:03
Компания 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.dev/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.dev/opennews/art.shtml?num=35779
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Анализ популярности языков программирования в 2012 году "	–2 +/–
Сообщение от бедный буратино (ok) on 08-Янв-13, 13:03
Perl популярнее JavaScript и Ruby - мощно задвинули, внушает. Бейсик растёт. Видимо, к дождю... Как они, кстати, Бейсик вычленяют из запросов? Как отличают ruby и рубин, python от удава и т.д.?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от Alex (??) on 08-Янв-13, 13:08
	> Как они, кстати, Бейсик вычленяют из запросов? Как отличают ruby и рубин, python от удава и т.д.? По контексту же, очевидно
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от бедный буратино (ok) on 08-Янв-13, 13:11
	>> Как они, кстати, Бейсик вычленяют из запросов? Как отличают ruby и рубин, python от удава и т.д.? > По контексту же, очевидно basic help это про программирование или нет?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	10. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от meequz (ok) on 08-Янв-13, 13:41
	Monty Python
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	71. "Анализ популярности языков программирования в 2012 году "	–10 +/–
	Сообщение от Аноним (??) on 08-Янв-13, 22:53
	> Monty Python Хорошо отражает суть языка. Сплошной стеб над хомяками использующими это а не ЯП.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	52. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от BratSinot (ok) on 08-Янв-13, 18:05
	Смотря какую ссылку пользователь выбрал, ваш КО. И да, это словосочетание на английском не имеет смысла.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	3. "Анализ популярности языков программирования в 2012 году "	+5 +/–
	Сообщение от BSA on 08-Янв-13, 13:09
	Количество запросов зависит не только от популярности, но и от гемморойности языка. Думаю, именно с этим связано опережение Perl JavaScript.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Анализ популярности языков программирования в 2012 году "	+6 +/–
	Сообщение от бедный буратино (ok) on 08-Янв-13, 13:12
	> Количество запросов зависит не только от популярности, но и от гемморойности языка. > Думаю, именно с этим связано опережение Perl JavaScript. Да, надо ещё отдельную табличку - сколько раз при запросе фигурировали слова fuck и fuckin'
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	31. "Анализ популярности языков программирования в 2012 году "	+5 +/–
	Сообщение от angra (ok) on 08-Янв-13, 15:59
	Ну тогда надо еще учитывать доступность и качество документации языка, идущей вместе с ним и в комплекте. Для perl/ruby/python лазить в интернет за докой как по базовым вещам, так и по дополнительным модулям нет нужды, все это устанавливается локально, документирование в них это часть языка. А вот для js локальной доки нет и не будет, вся информация только в инете.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	77. "Анализ популярности языков программирования в 2012 году "	–1 +/–
	Сообщение от анони on 08-Янв-13, 23:35
	Python простой язык. ужасная реализация. неповоротливый интерпретатор. отсутствие многопоточности из-за GIL. в любой момент только один поток активен. для большого проекта трудно отлаживаемый. при смене имени класса или параметров не выдает ошибок. нужно многое в голове держать. второй год по работе приходится писать. ненавижу.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	80. "Анализ популярности языков программирования в 2012 году "	+4 +/–
	Сообщение от Xasd (ok) on 09-Янв-13, 01:29
	> при смене имени класса или параметров не выдает ошибок. какая нелепая критика. детка, это утиная типизация! и она сделана специально для удобства! если ты пишешь на 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++-кода. > второй год по работе приходится писать. ненавижу. а до этого (или кроме этого?) на чём? очевидно на чём-то на том что является противоположностью Пайтона по самой идеологии [тоесть: статико-типизированном, компилируемом, со сложным синтаксисом].
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	82. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 09-Янв-13, 03:44
	>[оверквотинг удален] > 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 неплохой язык, для простеньких задач. Но он начался с идеологии, и до сих пор не может отказаться от этой идеологии "всё можно сделать единственным путём". Идеологию фтопку. Есть вполне определённые практические задачи, которые предъявляют вполне определённые требования к языку. Когда же язык, вместо того, чтобы удовлетворять этим требованиям, начинает швыряться лозунгами, и говорить что требования некошерны... Это как минимум странно.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	88. "Анализ популярности языков программирования в 2012 году "	–1 +/–
	Сообщение от Имяноним on 09-Янв-13, 06:31
	> Когда же язык, вместо того, чтобы удовлетворять этим требованиям, начинает швыряться лозунгами, и говорить что требования некошерны... Это как минимум странно. тыг что-то давно я не видел в каких-то требованиях пункта *ПОЛНЕЙШАЯ* многозадачность :-) .. тут вот товаришь пытался нам сообщить что в Python совершенно нет многозадачности. на что ему ответили что многозадачность есть, но она распространяется не на всю программу, а на ввод-вывод. в требованиях же к разрабатываемым утилитам обычно так и сказано "обеспечить многозадачность" (тоесть -- хотябы какую-то! без намёка на то что что математика якобы тоже должна быть многозадачной :-)). и не забывайте пожалуйста что если мы будем перекладывать часть функционала на операционную подсистему -- то от этого эти функции сёравно всё также будут выполняться на процессоре а не внутри астрала  (нагрузка на процессоре будет возрастать!).
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	89. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 09-Янв-13, 07:22
	>> Когда же язык, вместо того, чтобы удовлетворять этим требованиям, начинает швыряться лозунгами, и говорить что требования некошерны... Это как минимум странно. > тыг что-то давно я не видел в каких-то требованиях пункта *ПОЛНЕЙШАЯ* многозадачность > :-) .. > тут вот товаришь пытался нам сообщить что в Python совершенно нет многозадачности. > на что ему ответили что многозадачность есть, но она распространяется не > на всю программу, а на ввод-вывод. Я выше предложил на выбор два термина для обозначения такой многозадачности: user-space многозадачность, и кооперативная многозадачность. Первый термин, по-моему, лучше описывает особенности питона, но второй, в общем, тоже об этом. И я предлагаю пользоваться этой устоявшейся терминологией, не изобретая велосипедов, типа "многозадачности, распространяемой на ввод/вывод". > в требованиях же к разрабатываемым утилитам обычно так и сказано "обеспечить многозадачность" > (тоесть -- хотябы какую-то! без намёка на то что что математика > якобы тоже должна быть многозадачной :-)). > и не забывайте пожалуйста что если мы будем перекладывать часть функционала на > операционную подсистему -- то от этого эти функции сёравно всё также > будут выполняться на процессоре а не внутри астрала  (нагрузка на > процессоре будет возрастать!). В ТЗ обычно пишется, для чего нужна многозадачность, и соответственно становится ясным, какого типа многозадачность подразумевается. Лет десять-пятнадцать назад, kernel-space реализация thread'ов, очевидно, была оверхедом в большинстве случаев, а на десктопах -- даже не в большинстве, а всегда. Но в современных системах, в которых количество процессоров/ядер подчастую больше единицы, достаточно загадочной выглядит насильственная привязка языка к user-space многозадачности. Да, я замечу, что лет пять назад я бредил идеей создания сервера использующего user-space многозадачность с целью повышения производительности. На базе той самой, упомянутой мною, libpth. Сегодня же, в виду того, что у меня дома стоит четырёхядерный проц, а на серверах с которыми я имею дело, подчастую, ядер ещё больше, у меня рождаются серьёзные сомнения в том, что овчинка стоит выделки. И к сомнениям добавляется подозрение, что сомнения превратятся в уверенность лет через десять, когда для процессоров станет нормальным иметь двух-трёх-значное число ядер.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	118. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от Xasd (ok) on 10-Янв-13, 12:13
	`
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	101. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от netch (ok) on 09-Янв-13, 14:41
	>>[оверквотинг удален] > Несмотря на всё это почему-то в C кооперативная многозадачность непопулярна. Кооперативной многозадачности в C чуть более, чем на каждом углу. Только реализуется она через FSM'ы и select/poll/etc, или через движки типа eventlib. Боюсь, что то, что Вы рассказываете, объясняется личными проблемами libpth, а не общего подхода. > Странно при этом, что, например, Haskell, зачем-то в дополнение к юзер-спейс потокам, > в библиотеках есть и ядерные потоки. Странно, что Microsoft, при создании > Windows '95 отказалась от корпоративной многозадачности, используемой в предыдущих версиях > Windows в пользу вытесняющей. Чего ж это им всем так не > нравится корпоративная многозадачность, а? Ну, во-первых, кооперативная, а не корпоративная:) Во-вторых, к чему Вы это? Хотите полноценную вытесняющую многозадачность в Python? Модуль multiprocessing находится в стандартной поставке, начиная с 2.6. Представляете, там есть даже разделяемые переменные и возможность делать менеджеры доступа с персональной политикой синхронизации. > А вы не сталкивались с такой фишкой, как опциональная типизация переменных? То > есть когда язык позволяет создать как типизированную переменную, так и не > типизированную. Помимо удобств отладки (рантайм исключения, при попытки записать int в > переменную типа string), возникает офигенный простор для оптимизации, путём выпиливания > из бутылочных горлышек тормозов порождённых динамической типизацией. Ага, для этого давно уже есть Cython. > Python неплохой язык, для простеньких задач. Но он начался с идеологии, и > до сих пор не может отказаться от этой идеологии "всё можно > сделать единственным путём". Идеологию фтопку. Есть вполне определённые практические > задачи, которые предъявляют вполне определённые требования к языку. Когда же язык, > вместо того, чтобы удовлетворять этим требованиям, начинает швыряться лозунгами, и говорить > что требования некошерны... Это как минимум странно. Там есть странные вещи, но, о чём Вы говорите, давно и успешно решается. Просто надо знать чуть шире, чем одно базовое средство.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	102. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 09-Янв-13, 16:29
	>>>[оверквотинг удален] >> Несмотря на всё это почему-то в 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.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	119. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от Xasd (ok) on 10-Янв-13, 12:23
	Ruby это по сути тотже Python , но сделанный для волшебников (хакеров). тяжёлая магия -- в Ruby -- будто бы считается нормой. характерный пример: например, в Ruby [где-нибудь в середине кода, в одном из файлов] можно написать:     foo = Bar.new а теперь [если ты не являешься автором кода] -- КАК ИМЕННО ты узнаешь где именно находится описание класса "Bar" ? оно может быть где угодно (в непонятно каком файле) ! искать через grep чтоле? и подобных примеров -- огромное множество! Python же ориентирован больше на то что не все люди являются экстрасенсами :) .. там чётко:     from baz import Bar     #... ... ...     #... ... ...     #... ... ...     foo = Bar()     #... ... ...     #... ... ...     #... ... ... это значит что "Bar" задекларирован внутри "baz". потомучто магия -- она хороша только когда автор кода является один.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	132. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 11-Янв-13, 03:09
	> Ruby это по сути тотже Python , но сделанный для волшебников (хакеров). > [...] > потомучто магия -- она хороша только когда автор кода является один. Много слов, в конечном итоге сводящихся к тому, что на Ruby проще написать нечитабельную программу. Я правильно понял вашу позицию? Мне кажется, что если в отношении Perl'а такого рода обвинения достаточно обоснованы: всем я думаю приходилось сталкиваться с совершенно нечитаемыми скриптами на Perl, и матерясь так, что жена с кухни прибегает выяснить в чём же дело, разгребать дерьмо пытаясь понять, почему оно не работает. Но когда речь идёт о сравнении Python и Ruby, мне это больше напоминает давно забытый холивар Pascal vs C. Одним из основных аргументов ведущего этого холивара, проф. Н. Вирта, был именно аргумент о том, что на C проще написать плохой код. То есть мне кажется, что в случае Ruby, дополнительные возможности создать нечитаемый код не столь уж и существенны, что бы изменить ситуацию с чтением сорцов в худшую сторону. ps. Да. И если вам не удаётся найти описание символа программы, то find+grep, при всей его универсальности, не единственный способ. И не всегда самый удачный. Есть ещё ctags/etags. Я, правда не пробовал (не возникало нужды) etags применительно к ruby, и не знаю насколько он может помочь, но сейчас погуглил: он умеет и ruby.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	121. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от netch (ok) on 10-Янв-13, 15:54
	>>> Несмотря на всё это почему-то в 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> объектную ориентированность, причём записать это всё по-японски, чтобы круче выглядело".
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	130. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 11-Янв-13, 02:16
	> [...] > Насколько я понимаю, это аргументы в ту же сторону, куда и Вы > клоните? Но тогда что от этого меняется? > [...] > То есть Вам по факту пофиг, будут 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, я так и не понял, зачем, прежде чем высказать его, вы заранее испрашивали извинений.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	136. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от netch (ok) on 12-Янв-13, 11:09
	>[оверквотинг удален] >> Простите, я не понимаю, откуда у Вас такие выводы. С 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, я так и не понял, зачем, прежде чем > высказать его, вы заранее испрашивали извинений. Ну Вы как-то уж очень агитировали за него.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	137. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 12-Янв-13, 17:31
	> А какие именно фразы говорят про "перл наоборот"? Неужели "Beatiful is better > than ugly"? ;) И эта тоже. А что, скажете, нет? >> Вы хотите сказать о том, что мэйнстим как всегда ездит по проторенной >> дорожке боясь свернуть в сторону? Я знаю это. И все, по-моему, >> знают. И даже причины тому известны. Скучны и неинетересны ибо обсуждались >> тысячи раз. > Не так. Перед майнстримом есть огромное количество народу, который экспериментирует со > всем. И уже по их результатам что-то попадает в майнстрим. Так > вот - их любовь к тому же Ruby подозрительно быстро прошла > в последнее время. Что значит "не так"? Вы не натыкались на подобные обсуждения, почему мейнстрим столь ограниченно мыслит? Но давайте всё же не будем поднимать тему, она ещё более холиварная, нежели ущербности питона. Я даже боюсь подумать о том, в чём меня начнут подозревать, если я влезу в эту тему: в мейнстримности головного мозга? Или наоборот в непонимании всей мудрости и профессионализма мейнстрим-разработчика? Или в чём-то третьем? >> Явно надо указывать, что создавая объект надо выделять его из SHM кучи, >> а не из локальной. > Это проблема? Мне кажется, это скорее преимущество. Ключевое слово "кажется". Тогда и файловый дескриптор -- сплошное преимущество перед std::stream: файловый дескриптор даёт удивительно тонкий контроль над ситуацией, и, главное -- всё наглядно. Читая код, всегда будешь в курсе какая стратегия буферизации используется, всегда будет понятно, какой формат вывода числовых данных активен в данный момент. И никаких сбивающих с толку неявностей. > Кстати, мультитрединг в Perl такой же - взаимодействие между нитями только явное. Ну это вам виднее. В перле я не писатель, в перле я читатель. Но при чём тут перл? Это в к тому, что реализовывая мультитрединг Python пошёл не в абсолютно противоположную сторону? Может быть. Но что нашему диалогу даёт понимание этого факта? >> При необходимости передать открытый файловый дескриптор надо >> прибить дочерний процесс и создать новый. > Вообще-то передача дескриптора между процессами работала через Unix sockets ещё в 80-х > годах. Да, это может потребовать вспомогательного модуля на Си, но это > ничтожная плата в большинстве случаев. Вы не могли бы привести здесь кусочек кода на Python, который продемонстрирует передачу открытого файла между процессами? >> Вполне себе honest opinion, я так и не понял, зачем, прежде чем >> высказать его, вы заранее испрашивали извинений. > Ну Вы как-то уж очень агитировали за него. Вам опять "кажется". Я никого ни на что не агитирую. Уверен твёрдо, что каждый сам кузнец своего счастья, и мои подсказки не требуются. Вот представьте, на секундочку, а если я займусь агитацией, но ошибусь с выбором предмета агитации. И представьте, что мне случится убедить окружающих в том, что дерьмо сладкое и вкусное. Они же наевшись дерьма, меня обвинят в том, что я насильно им дерьмо в рот засовывал. Зачем мне это надо? Я не агитирую, лишь рассказываю, что мне не нравится в питоне. А руби, перл, C, и все прочие языки, что я упоминал -- это лишь примеры, приведённые для пояснения различных моих высказываний.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	138. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от netch (ok) on 13-Янв-13, 11:24
	>> А какие именно фразы говорят про "перл наоборот"? Неужели "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, и все прочие языки, что я упоминал -- > это лишь примеры, приведённые для пояснения различных моих высказываний. Вы слишком несистемно поясняете, и это сильно мешает понять основную идею.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	140. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 14-Янв-13, 15:55
	>>> А какие именно фразы говорят про "перл наоборот"? Неужели "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, и все прочие языки, что я упоминал -- >> это лишь примеры, приведённые для пояснения различных моих высказываний. > Вы слишком несистемно поясняете, и это сильно мешает понять основную идею. Ничем помочь не могу. Либо вы имеете желание понимать, и поэтому вчитываетесь, и понимаете или задаёте вопросы, чтобы выяснить то, что неясно, либо помочь ничем не могу: если вместо того, чтобы выяснять у меня то, что вам непонятно, вы агитируете за питон, то наш разговор -- это разговор глухого с немым. Меня бесполезно агитировать, и за апельсины, и за картошку с говяжьим стейком. И особенно за питон. Я равнодушен к процессу еды, воспринимаю его как надоевшую физиологическую потребность, поэтому мне практически без разницы, чем питаться. А почему меня бесполезно агитировать за питон, я уже объяснял вам. Позвольте я не буду повторяться.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	141. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от netch (ok) on 14-Янв-13, 17:26
	> Уточняю: не правильно. У перла это не основополагающий принцип, а следствие. Разных > причин следствие. Ну тогда вообще любое другое средство должно стремиться уйти от такого результата. >> В итоге я даже на C++ предпочту stdio для текстового >> общения: оно не страдает ерундой на ровном месте. > О, даже как! Круто. А tail-рекурсию в C++ вы, наверное, реализуете asm-вставкой, > чтобы не связываться с компилятором, который может как-нибудь не так соптимизировать > рекурсивный вызов? Я не могу ничего сказать про такие вещи в C++, потому что не разбираюсь в них. Но мне кажется, что сравнение некорректно. И, BTW, я сказал, чего не хватает iostream'у, чтобы быть нормально использованным, с моей точки зрения (в смысле, так, чтобы не иметь этот тяжёлый недостаток). > Ладно, давайте считать что он шёл своей дорогой, а то что его > принципы во многом противоположные тому, к чему пришёл перл следуя своим > принципам -- это чистой воды случайность, и все причинно-следственные связи мне > лишь кажутся. Ну, наверно, так оно и есть. >> Зачем агитировать за дерьмо, я таки не знаю:) А вот зачем агитировать >> за апельсин, картошку или говяжий стейк, я могу себе представить без >> проблем. > И, интересно, зачем? Вы, кстати, пробовали? Как успехи? Достаточно успешно (не за этот конкретный набор продуктов, но за похожие). Разумеется, когда собеседник в принципе был готов принять какой-то совет. >>> Я не агитирую, лишь рассказываю, что мне не нравится в питоне. А >>> руби, перл, C, и все прочие языки, что я упоминал -- >>> это лишь примеры, приведённые для пояснения различных моих высказываний. >> Вы слишком несистемно поясняете, и это сильно мешает понять основную идею. > Ничем помочь не могу. Либо вы имеете желание понимать, и поэтому вчитываетесь, > и понимаете или задаёте вопросы, чтобы выяснить то, что неясно, либо > помочь ничем не могу: если вместо того, чтобы выяснять у меня > то, что вам непонятно, вы агитируете за питон, то наш разговор > -- это разговор глухого с немым. Это воистину разговор глухого с кем-то ещё, если Вы не хотите понимать, что я *не агитирую* за Питон. Я объясняю, чем он, с моей точки зрения, хорош (в частности, лучше Ruby или Perl), чем меня не устраивают аналоги. Тем более, что Вы сами тут несколько циклов переписки устраивали подробное расспрашивание, что я собственно думаю. Вы же сосредоточены на одном - что Питон плох. Вы пытаетесь это объяснить сравнением с одним, другим, третьим, но всё равно он Вам плох. Может, это действительно первичный фактор, а все попытки сравнения это попытки рационализации нерационального? > Меня бесполезно агитировать, и за апельсины, и за картошку с говяжьим стейком. > И особенно за питон. Я равнодушен к процессу еды, воспринимаю его > как надоевшую физиологическую потребность, поэтому мне практически без разницы, чем питаться. Где-то я это уже читал. "...Александр Иванович Корейко не ел, а питался. Он не завтракал, а совершал физиологический процесс введения в организм должного количества жиров, углеводов и витаминов..." Но даже в этом случае подбор оптимального сочетания компонентов еды полезен для организма, не так ли? > А почему меня бесполезно агитировать за питон, я уже объяснял вам. > Позвольте я не буду повторяться. Позволяю. Но и Вы тогда не агитируйте за Ruby или что там ещё, раз уж так это воспринимаете.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	142. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 15-Янв-13, 07:27
	>[оверквотинг удален] >>>> это лишь примеры, приведённые для пояснения различных моих высказываний. >>> Вы слишком несистемно поясняете, и это сильно мешает понять основную идею. >> Ничем помочь не могу. Либо вы имеете желание понимать, и поэтому вчитываетесь, >> и понимаете или задаёте вопросы, чтобы выяснить то, что неясно, либо >> помочь ничем не могу: если вместо того, чтобы выяснять у меня >> то, что вам непонятно, вы агитируете за питон, то наш разговор >> -- это разговор глухого с немым. > Это воистину разговор глухого с кем-то ещё, если Вы не хотите понимать, > что я *не агитирую* за Питон. Я объясняю, чем он, с > моей точки зрения, хорош (в частности, лучше Ruby или Perl), Мне нравится ваш настрой. Но я вижу именно агитацию. То есть да, быть может я и глухой и слепой, но каждый раз когда я высказываю то, что меня не устраивает в питоне, вы начинаете рассказывать мне, почему вас это устраивает. Это ли не агитация? То есть с какой целью вы рассказываете мне об этом? Вы думаете, что мне очень интересно, что вам нравится, а что нет? Если да, то вы меня переоцениваете. > чем меня не устраивают аналоги. Тем более, что Вы сами тут несколько > циклов переписки устраивали подробное расспрашивание, что я собственно думаю. > Вы же сосредоточены на одном - что Питон плох. Вы пытаетесь это > объяснить сравнением с одним, другим, третьим, но всё равно он Вам > плох. Может, это действительно первичный фактор, а все попытки сравнения это > попытки рационализации нерационального? Может быть. Но если и так то "нерациональное" -- это прямое следствие опыта использования питона. С последующим опытом использования прочих языков в тех же целях. А сравнение -- единственный способ познать удобства и неудобства языка. Будь то python, ruby, javascript или bash. Не сравнив язык с другим (а лучше с несколькими), невозможно понять что в нём удобно или неудобно. > Где-то я это уже читал. "...Александр Иванович Корейко не ел, а питался. > Он не завтракал, а совершал физиологический процесс введения в организм должного > количества жиров, углеводов и витаминов..." Но даже в этом случае подбор > оптимального сочетания компонентов еды полезен для организма, не так ли? Да-да. Почти. С единственной разницей: Корейко питался, а не ел, поскольку (если память мне не изменяет) берёг здоровье своё. У него была цель, ради которой он отказывался от радостей жизни. Для меня же, этой радости просто не существует, и отказываться не от чего. Витамины же подсчитывать... Я ещё не в том возрасте, чтобы заботиться о своём здоровье, высчитывая что-то там на калькуляторе. Поэтому мне важнее эффективность удовлетворения потребности "здесь и сейчас." >> А почему меня бесполезно агитировать за питон, я уже объяснял вам. >> Позвольте я не буду повторяться. > Позволяю. Но и Вы тогда не агитируйте за Ruby или что там > ещё, раз уж так это воспринимаете. То есть не повторяться насчёт питона вы позволяете, но вынуждаете повторить, что фразу "руби ближе к идеалу чем питон" не стоит воспринимать как агитацию? Хорошо, повторю, раскрыв: это не агитация, а наилучший компромисс между лаконичностью высказывания своего мнения и информативностью. Ведь если я просто скажу: мне не нравится питон, это будет очень неконкретное высказывание, которое не даст никаких шансов собеседнику понять почему же так. Но если я приведу в качестве примера что-то (например, ruby), то зная это "что-то" собеседник без дальнейших объяснений поймёт, что именно в питоне мне не нравится. И такая лаконичность, на мой взгляд, гораздо лучше многословной конкретики не только тем, что мне меньше писать: собеседнику не придётся продираться сквозь килобайты текста, выясняя чем же какой-то там язык не нравится непонятно кому. А ruby я выбрал в качестве языка для сравнения, потому что он вообще очень похож на питон. И сравнение с ним, наиболее рельефно показывает недостатки питона.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	143. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от netch (ok) on 15-Янв-13, 10:23
	>> Это воистину разговор глухого с кем-то ещё, если Вы не хотите понимать, >> что я *не агитирую* за Питон. Я объясняю, чем он, с >> моей точки зрения, хорош (в частности, лучше Ruby или Perl), > Мне нравится ваш настрой. Но я вижу именно агитацию. То есть да, > быть может я и глухой и слепой, но каждый раз когда > я высказываю то, что меня не устраивает в питоне, вы начинаете > рассказывать мне, почему вас это устраивает. Это ли не агитация? Нет. Это обмен мнениями. > То есть с какой целью вы рассказываете мне об этом? Вы думаете, > что мне очень интересно, что вам нравится, а что нет? Если > да, то вы меня переоцениваете. Вы подняли эту тему сами, начав рассказывать про недостатки. Тогда почему Вы удивляетесь, что Вам отвечают? > Может быть. Но если и так то "нерациональное" -- это прямое следствие > опыта использования питона. С последующим опытом использования прочих языков в тех > же целях. А сравнение -- единственный способ познать удобства и неудобства > языка. Будь то python, ruby, javascript или bash. Не сравнив язык > с другим (а лучше с несколькими), невозможно понять что в нём > удобно или неудобно. Я это не могу понять иначе, чем Питон Вам нанёс каким-то непонятным мне образом эмоциональную травму, и теперь Вы для дискуссии ищете любой вариант, с чем бы этаким его сравнить, лишь бы показать недостатки, а для практики - чем бы его заменить, лишь бы не использовать. Извините, но из данной дискуссии крайне сложно сделать иной вывод. Если Вас вообще интересует другая (возможно, более адекватная) оценка Вашего подхода другими участниками форума, включая меня, то попробуйте объяснить свою позицию иначе. > Да-да. Почти. С единственной разницей: Корейко питался, а не ел, поскольку (если > память мне не изменяет) берёг здоровье своё. У него была цель, > ради которой он отказывался от радостей жизни. Для меня же, этой > радости просто не существует, и отказываться не от чего. Простите, чего именно не существует - цели или радости? >[оверквотинг удален] >>> Позвольте я не буду повторяться. >> Позволяю. Но и Вы тогда не агитируйте за Ruby или что там >> ещё, раз уж так это воспринимаете. > То есть не повторяться насчёт питона вы позволяете, но вынуждаете повторить, что > фразу "руби ближе к идеалу чем питон" не стоит воспринимать как > агитацию? Хорошо, повторю, раскрыв: это не агитация, а наилучший компромисс между > лаконичностью высказывания своего мнения и информативностью. Ведь если я просто скажу: > мне не нравится питон, это будет очень неконкретное высказывание, которое не > даст никаких шансов собеседнику понять почему же так. Но если я > приведу в качестве примера что-то (например, ruby), Проблема именно в том, что Вам не нравится питон не потому, что нравится что-то ещё, а потому, что не нравится питон. Потому Вы и ищете кучу вариантов, с чем бы его сравнить, а не что-то одно. Это именно попытка рационализации эмоционального. Я не вижу причин, почему это должно учитываться для работы других программистов. > А ruby я выбрал в качестве языка для сравнения, потому что он > вообще очень похож на питон. И сравнение с ним, наиболее рельефно > показывает недостатки питона. Понятно, но всё равно не могу согласиться. См. выше.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	147. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 17-Янв-13, 09:19
	>>> Это воистину разговор глухого с кем-то ещё, если Вы не хотите понимать, >>> что я *не агитирую* за Питон. Я объясняю, чем он, с >>> моей точки зрения, хорош (в частности, лучше Ruby или Perl), >> Мне нравится ваш настрой. Но я вижу именно агитацию. То есть да, >> быть может я и глухой и слепой, но каждый раз когда >> я высказываю то, что меня не устраивает в питоне, вы начинаете >> рассказывать мне, почему вас это устраивает. Это ли не агитация? > Нет. Это обмен мнениями. Это хорошо. А то я уж начал подозревать худшее. >> То есть с какой целью вы рассказываете мне об этом? Вы думаете, >> что мне очень интересно, что вам нравится, а что нет? Если >> да, то вы меня переоцениваете. > Вы подняли эту тему сами, начав рассказывать про недостатки. Тогда почему Вы > удивляетесь, что Вам отвечают? Не надо приписывать мне заслуг, которых за мной нет. Меня удивляет вовсе не то, что мне отвечают. Меня удивляет настойчивость, с который вы раз за разом повторяете мне своё мнение о питоне. Оно было ясно с самого начала, я даже там фразу оставил, чтобы вам было понятно, что до меня дошло ваше мнение. Но вы до сих пор не можете успокоится, и продолжаете мне это мнение рассказывать. Естественно, это удивляет. Точнее не удивляет, а озадачивает. И становится интересно, к чему же вы пытаетесь привести сию беседу, развивая её таким образом. > Я это не могу понять иначе, чем Питон Вам нанёс каким-то непонятным > мне образом эмоциональную травму, и теперь Вы для дискуссии ищете любой > вариант, с чем бы этаким его сравнить, лишь бы показать недостатки, > а для практики - чем бы его заменить, лишь бы не > использовать. Извините, но из данной дискуссии крайне сложно сделать иной вывод. Нет, он не наносил мне травмы. Но и тем не менее, считать его удобным языком я не могу. Неожиданно, да? > Если Вас вообще интересует другая (возможно, более адекватная) оценка Вашего подхода другими > участниками форума, включая меня, то попробуйте объяснить свою позицию иначе. >> Да-да. Почти. С единственной разницей: Корейко питался, а не ел, поскольку (если >> память мне не изменяет) берёг здоровье своё. У него была цель, >> ради которой он отказывался от радостей жизни. Для меня же, этой >> радости просто не существует, и отказываться не от чего. > Простите, чего именно не существует - цели или радости? Прощаю. Поясняю: ни того, ни другого. Но на будущее: не надо так обрезать цитату. В том, что вы процитировали, объяснено отсутствие радости. В хвосте же абзаца (который вы обрезали, цитируя), объяснялось отсутствие цели. > Проблема именно в том, что Вам не нравится питон не потому, что > нравится что-то ещё, а потому, что не нравится питон. Да. И никто, замечу, не в состоянии эту "проблему" решить, предложив мне удачную замену питону. Так что проблема, вероятно, шире и не сводится к одному питону. > Потому Вы и ищете кучу вариантов, с чем бы его сравнить, а не > что-то одно. Это именно попытка рационализации эмоционального. Я не вижу причин, > почему это должно учитываться для работы других программистов. Фраза про работу других программистов, мне не совсем понятна. При чём тут программисты? "Другие" -- это относительно кого? >> А ruby я выбрал в качестве языка для сравнения, потому что он >> вообще очень похож на питон. И сравнение с ним, наиболее рельефно >> показывает недостатки питона. > Понятно, но всё равно не могу согласиться. См. выше. То что вы с этим не можете согласиться было понятно в самом начале треда. Где-то именно там мы с вами это выяснили. Непонятно, зачем вы теперь это повторяете? Надо ли воспринимать это как гнусные намёки на то, что у меня склероз?
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	149. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от netch (ok) on 17-Янв-13, 10:19
	>>> Это ли не агитация? >> Нет. Это обмен мнениями. > Это хорошо. А то я уж начал подозревать худшее. "Худшее" это агитация? > Не надо приписывать мне заслуг, которых за мной нет. Меня удивляет вовсе > не то, что мне отвечают. Меня удивляет настойчивость, с который вы > раз за разом повторяете мне своё мнение о питоне. Оно было > ясно с самого начала, я даже там фразу оставил, чтобы вам > было понятно, что до меня дошло ваше мнение. Но вы до > сих пор не можете успокоится, и продолжаете мне это мнение рассказывать. Не продолжайте тему и не будет, на что отвечать. > Естественно, это удивляет. Точнее не удивляет, а озадачивает. И становится интересно, > к чему же вы пытаетесь привести сию беседу, развивая её таким > образом. У меня нет никакой твёрдой направленности данного треда. > То что вы с этим не можете согласиться было понятно в самом > начале треда. Где-то именно там мы с вами это выяснили. Непонятно, > зачем вы теперь это повторяете? Надо ли воспринимать это как гнусные > намёки на то, что у меня склероз? Это надо воспринимать как стиль, который рекомендуется для облегчения чтения. P.S. Кажется, тред выродился. Не вижу смысла продолжать.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	150. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 18-Янв-13, 17:15
	>>>> Это ли не агитация? >>> Нет. Это обмен мнениями. >> Это хорошо. А то я уж начал подозревать худшее. > "Худшее" это агитация? Нет. > Не продолжайте тему и не будет, на что отвечать. Как скажете. >> Естественно, это удивляет. Точнее не удивляет, а озадачивает. И становится интересно, >> к чему же вы пытаетесь привести сию беседу, развивая её таким >> образом. > У меня нет никакой твёрдой направленности данного треда. Твёрдой... Мягкой... Направленность треда -- это немного другое. Речь о целях, которые вы преследуете участвуя в нём. Очевидно, вы придерживаетесь какой-то определённой линии поведения. Странной на мой взгляд. Интересно было бы посмотреть, к чему таким образом вы надеетесь придти. > P.S. Кажется, тред выродился. Не вижу смысла продолжать. Мне так кажется, буквально с начала обсуждения. Отсутствие общепринятой фичи это никоим образом не преимущество. В этом могут быть плюсы, и могут быть даже существенные плюсы, заслуживающие того, чтобы не запиливать фичу. Но уже само по себе отсутствие -- это самым очевидным образом минус. И когда я читаю доказательства тому, что отсутствие кернел-спейс потоков -- это целая гора несомненных плюсов и ничего больше, естественно, вывод напрашивается один: тред выродился в демагогию.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	144. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от неймофаг on 15-Янв-13, 19:13
	>Это называется user-space cooperative threading. Такая хрень доступна и для C, например, >через библиотечку libpth. Но почему-то, никто не использует libpth, предпочитая >libpthread. Странно да? Вот несмотря на все преимущества кооперативной многозадачности, >например, отсутствие необходимости в реентерабельности кода (что существенно упрощает >синхронизацию нитей), несмотря на то, что при кооперативной многозадачности стоимость >нити минимальна, и процесс легко может позволить наплодить себе десять тысяч нитей (на >каждый открытый файловый дескриптор сокета по нити) и не положить систему... Несмотря на >всё это почему-то в C кооперативная многозадачность непопулярна. >Странно при этом, что, например, Haskell, зачем-то в дополнение к юзер-спейс потокам, в >библиотеках есть и ядерные потоки. Странно, что Microsoft, при создании Windows '95 >отказалась от корпоративной многозадачности, используемой в предыдущих версиях Windows в >пользу вытесняющей. Чего ж это им всем так не нравится корпоративная многозадачность, а? Есть целые операционные системы где нет вытесняющей многозодачности в потоках или даже в процессах операционной системы. И количество ядер, а иногда даже и сокетов в этих системах бывает больше единицы. При этом там есть C, Python и Java, только программы там работают не совсем так как думает пргораммист, не знакомый с системой. Все-таки, когда язык скрывает от программиста всю подноготную - это оболванивает. К хорошему быстро привыкаешь и начинаешь воспринимать как должное любую фишку библиотеки расширения языка.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	148. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 17-Янв-13, 09:22
	>>Это называется user-space cooperative threading. Такая хрень доступна и для C, например, >через библиотечку libpth. Но почему-то, никто не использует libpth, предпочитая >libpthread. Странно да? Вот несмотря на все преимущества кооперативной многозадачности, >например, отсутствие необходимости в реентерабельности кода (что существенно упрощает >синхронизацию нитей), несмотря на то, что при кооперативной многозадачности стоимость >нити минимальна, и процесс легко может позволить наплодить себе десять тысяч нитей (на >каждый открытый файловый дескриптор сокета по нити) и не положить систему... Несмотря на >всё это почему-то в C кооперативная многозадачность непопулярна. >>Странно при этом, что, например, Haskell, зачем-то в дополнение к юзер-спейс потокам, в >библиотеках есть и ядерные потоки. Странно, что Microsoft, при создании Windows '95 >отказалась от корпоративной многозадачности, используемой в предыдущих версиях Windows в >пользу вытесняющей. Чего ж это им всем так не нравится корпоративная многозадачность, а? > Есть целые операционные системы где нет вытесняющей многозодачности в потоках или даже > в процессах операционной системы. И количество ядер, а иногда даже и > сокетов в этих системах бывает больше единицы. При этом там есть > C, Python и Java, только программы там работают не совсем так > как думает пргораммист, не знакомый с системой. > Все-таки, когда язык скрывает от программиста всю подноготную - это оболванивает. К > хорошему быстро привыкаешь и начинаешь воспринимать как должное любую фишку библиотеки > расширения языка. К чему вы этот пассаж оставили тут? К тому, что я, используя linux на платформе amd64, обязан ориентироваться в других платформах, для того, чтобы меня не обвинили в том, что я "оболванен"? Или я не правильно понял? Поясните, пожалуйста.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	90. "Анализ популярности языков программирования в 2012 году "	–2 +/–
	Сообщение от анониммм on 09-Янв-13, 08:20
	> это утиная типизация! таже Java при компиляции выдаст ошибку - нет такого класса, нет таких параметров (интерпретатор тоже так может:)) > сделана специально для удобства! Python? Python ничего не скажет пока не грохнется при выполнении. очень удобно. согласен. > GIL ускоряет Python (а не замедляет его) вот именно, что Python > внутри многонитевой Python-программы вся математичка остаётся последовательной, а ввод-вывод паралелльный очевидно ввод-вывод реализован на C/C++ средствами ОС? :) > куда не поворотливый? не хотелось писать медленный > 1. ...встраивать внутрь C/C++ программы. > 2. ...расширять его модули за счёт C/C++-кода. не проще написать все на C/C++?
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	120. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от Xasd (ok) on 10-Янв-13, 12:46
	>> это утиная типизация! > таже Java при компиляции выдаст ошибку - нет такого класса, нет таких параметров (интерпретатор тоже так может:)) читая эти сообщени форумов -- у меня иногда создаётся такое впечатление что программисты статически-типизируемых языков -- БЫСТРЕЙ БЫСТРЕЙ БЫСТРЕЙ (на БЕШЕННОЙ СКОРОСТИ) печатают огромные абзацы кода... ...а потом просят компилятор найти ошибки :) [обычно эти языка многословны. так что не странно, если так] блин.. ну конешно я понимаю что компилятор находяит эти ошибки... но ведь наверняка 95% ошибок которые находит компилятор -- это ошибки которые вызванны именно много словностью синтаксиса! полезность этих синтаксических анализаторов сводится к той аналогии как еслибы я сказал: """     * компьютер это очень полезая вешь, так как он может обнаруживать компьютерные вирусы!     * автомобиль это очень полезная вешь, так как автомобиль может быстро довезти водителя до ГАИ! """ ну как-то так :-) :-)
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	123. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от анони on 10-Янв-13, 16:44
	Что за чушь? Как удобно сразу же видеть в какой строке опечатался. Отчасти это связано с IDE
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	126. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Xasd (ok) on 10-Янв-13, 17:03
	ненавижу IDE
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	124. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от анониммм on 10-Янв-13, 16:51
	Или. Нет у тебя такого класса (во время выполнения). Фигак. Или. Что ты мне подсовываешь два параметра, давая пять. Фигак вылет или исключение. Но это на действительно больших проектах. Простенькие скрипты пишу на Python с удовольствием. Пробую какие-то идеи иногда.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	127. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Xasd (ok) on 10-Янв-13, 17:06
	> Простенькие скрипты пишу на Python > с удовольствием. Пробую какие-то идеи иногда. ну так-то всё правильно. только как-бы оно так не получилось, что если взять "сложую" программу и переписать её из <название-энтэрпрайзого-языка> в Python -- то получится "простенький скрипт" :-)  [убрав по-ходу-дела кучу кода отвечающего за объектно-ориентированность алгоритма, переписав всё это в функцинальный стиль] ..
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	146. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Аноним (??) on 15-Янв-13, 20:34
	> то получится "простенький скрипт" :-) В котором будаки типа вас забили даже на обработку ошибок и прочая. Поэтому какой-нибудь скрипт системного апдейтера убунты не найдя каких-то файлов локали просто виснет колом навечно. Успев переключить репы, но не успев сделать апгрейд системы. Потому что питонист вообще не знает что за фигня - I/O error и его обработка.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	125. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от анониммм on 10-Янв-13, 16:53
	В общем приходится выискивать все проблемные места вручную самому.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	93. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от анониммм on 09-Янв-13, 08:49
	с ненавижу загнул. на нем хорошо писать простенькие вещи. пробовать какие-то идеи. раздражает маниакальное пристрастие писать на нем все.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	107. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Аноним (??) on 09-Янв-13, 18:41
	> т.е.: внутри многонитевой Python-программы вся математичка остаётся > последовательной, а ввод-вывод паралелльный. Вот только обычно все упиратеся в ввод-вывод и параллелить его толку мало. А иногда и сплошной вред, например на механическом винчестере.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	114. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от анониммм on 10-Янв-13, 10:30
	Вообще-то я обычно как раз способные параллельно выполняться задачи распараллеливаю. С Python это не возможно, так как всегда выполняется только один поток и это очень очень очень расстраивает
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	128. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Xasd (ok) on 10-Янв-13, 17:20
	>> т.е.: внутри многонитевой Python-программы вся математичка остаётся >> последовательной, а ввод-вывод паралелльный. > Вот только обычно все упиратеся в ввод-вывод и параллелить его толку мало. > А иногда и сплошной вред, например на механическом винчестере. ну это вредно конешно для механники. но что касается производительности -- попробуй сам же и вдумайся в свои слова -- "обычно все упиратеся в ввод-вывод"! как минимум в многонитевых программах написанных на Python -- Математика работает в ПАРАЛЛЕЛЬНОЙ ните относительно нитей ввода-вывода! и механизм GIL это ни как это НЕ ухудшает. таким образом в случае если "все упиратеся в ввод-вывод" -- то совершенно пофигу паралельная ли математика или не паралельная. (главное чтобы Математика не мешала вводу-выводу. а она как раз и НЕ мешает в случае с GIL Python). Математика не параллелится ЛИШЬ ТОЛЬКО ОТНОСИТЕЛЬНО СЕБЯ САМОЙ. # P.S.: блин, почему я всё это так разжовываю? неужеле нельзя самим поглядеть как работает GIL? вот вы вбили себе в голову что якобы активна только одна нить и всё. даже не пытаетесь проверить это на практике, например, тэстом каким-нибудь.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	100. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от netch (ok) on 09-Янв-13, 14:36
	> Python простой язык. ужасная реализация. неповоротливый интерпретатор. отсутствие многопоточности > из-за GIL. Вам религия запрещает применить модуль multiprocessing? > в любой момент только один поток активен. для большого > проекта трудно отлаживаемый. Это в чём же он трудно отлаживаемый? > при смене имени класса или параметров не выдает > ошибок. Тесты надо писать независимо от языка. А покрытое тестом не имеет таких проблем. > нужно многое в голове держать. Подробнее, пожалуйста. > второй год по работе приходится > писать. ненавижу. А я - ну не обожаю - но для массы типичных задач не вижу ничего лучше. Потому что его просто нет. Так что как средство сложного скриптования по умолчанию Python - лучший среди имеющегося.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	115. "Анализ популярности языков программирования в 2012 году "	–1 +/–
	Сообщение от анониммм on 10-Янв-13, 10:55
	> Вам религия запрещает применить модуль 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 (компиляция на лету).
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	116. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от netch (ok) on 10-Янв-13, 11:05
	>> Вам религия запрещает применить модуль multiprocessing? > Вам объяснить чем процесс отличается от потока? Объясните. В частности, насколько эти различия существенны при работе через блок разделяемой памяти. А также, почему существуют вызовы rfork() и clone() с массой промежуточных между процессом и тредом вариантов. > Стандартная отмазка питониста. Вместо нормальной > реализации интерпретатора сделали костыль. <mode="mirror">Стандартный наезд того, который сам не знает, чем и как процесс отличается от треда (особенно в Unix-системах).</mode> Прежде чем говорить о "нормальной" реализации, надо определить критерии нормальности. Я не вижу никакого смысла в требовании их определения как "для ОС это один процесс", в условиях, когда собственно ОС такие различия пофиг почти во всём. >> Тесты надо писать независимо от языка > На все функции? O_o Это отдельный огромный вопрос. Но вкратце - BDD наше всё, плюс соображения автора кода о том, где могут быть острые углы. >> Так что как средство сложного скриптования по умолчанию Python - лучший среди имеющегося. > Думал над этим. Scala. JVM не страдает от GIL > Другое дело, что порог вхождения у Scala выше. Он очень сильно выше, в этом и проблема. И REPL у него нет, а для средства такого типа это обязательное условие.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	122. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от анони on 10-Янв-13, 16:41
	Накладные расходы на процесс. Иногда существенно иногда нет.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	135. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Anonimouse on 11-Янв-13, 23:03
	>И REPL у него нет, а для средства такого типа это обязательное условие. REPL у scala в наличии.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	32. "Анализ популярности языков программирования в 2012 году "	–3 +/–
	Сообщение от rshadow (ok) on 08-Янв-13, 16:10
	Языки сами по себе примерно одинаковые, состоят из N (~100) ключевых слов и символов, плюс N (~20) конструкций исключая конечно всякие asm и брейнфаки... А запросы чаще всего связаны с поиском решений каких либо задач а не с самим языком. 1. Например: в спавочник яваскрипта заглядываешь редко, но на jquery.com частенько. В справочник по php/perl/python/rubi редко, а ищещь какую-нибудь либу чаще, или например запрос в MySQL/PosgreSQL и т.д. 2. К тому же рейтинг не учитывает собственно библиотеки языков. В том же перле нету смысла ходить в гугл если есть cpan.org Вообщем я бы рейтинг рассматривал с точки зрения начинающих программистов. Так сказать общие тенденции куда сейчас идет народ. Но это ни в коей мере не показатель сколько им _уже_ пользуются, и насколько он _уже_ популярен.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	54. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Crazy Alex (ok) on 08-Янв-13, 18:31
	Ну вот по плюсам показательно - это ж явно народ ринулся C++11 осваивать
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	72. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Аноним (??) on 08-Янв-13, 22:54
	> Ну вот по плюсам показательно - это ж явно народ ринулся C++11 осваивать Ну а что, очеловечили малость - результат налицо. А си хороши сами по себе. В своих нишах они просто как рыба в воде.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	44. "Анализ популярности языков программирования в 2012 году "	+2 +/–
	Сообщение от kurokaze (ok) on 08-Янв-13, 17:03
	> Количество запросов зависит не только от популярности, но и от гемморойности языка. Думаю, именно с этим связано опережение Perl JavaScript. Такое мог написать только тот кто ни одного из них не знает, хехе
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	55. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Crazy Alex (ok) on 08-Янв-13, 18:32
	Воистину. Сейчас как раз на обоих пишу...
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	26. "Анализ популярности языков программирования в 2012 году "	–1 +/–
	Сообщение от Ононим on 08-Янв-13, 15:23
	Тогда brainfuck должен быть в тройке. :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	43. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от TS (ok) on 08-Янв-13, 17:02
	> 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"' :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	73. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Аноним (??) on 08-Янв-13, 22:55
	> например - https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY... ...эталонный притон питонистов. Все за PyPy-кали. Не стуль мышления а Pyздец!
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	103. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от 00OO on 09-Янв-13, 16:33
	И вот это-то крайне странно, я нащщёт JavaScriptа. На фоне ноды и пакетов для нее, что-то как-то маловероятно, не?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

7. "Анализ популярности языков программирования в 2012 году "	+9 +/–
Сообщение от тоже Аноним (ok) on 08-Янв-13, 13:29
Собственно, табличка показывает, что новички хватаются теперь не только за Андроид, но и за iOS. Причем желательно одновременно. Стараясь не повторять одну и ту же работу на двух языках (Java и Objective C), они стараются писать код, который может быть использован под обеими платформами (на С / С++). Интересные мобильные платформы отвлекли быдлокодеров от формоклепания (падение С#). Вот и все тенденции. Предсказать их можно было без всякого анализа запросов...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Анализ популярности языков программирования в 2012 году "	+2 +/–
	Сообщение от Аноним (??) on 08-Янв-13, 13:42
	…и тем не менее ты не высказал предсказания всех этих тенденций до этого анализа запросов. Ты уверен, что всё, что ты высказал — не рационализация?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	23. "Анализ популярности языков программирования в 2012 году "	+3 +/–
	Сообщение от Crazy Alex (ok) on 08-Янв-13, 15:03
	С плюсами проще. Они язык не модный, на них просто пишут. СЧоответственно новичков там довольно мало. Но вот появился 11-й стандарт. Люди пытаются его освоить. А плюсовиков мноого...
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	81. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от тоже Аноним (ok) on 09-Янв-13, 02:06
	Плюсы и просто С еще и часто входят в учебную программу. Поэтому гуглят по ним много. Но это количество от веяний моды не меняется. Тенденции - не в графике, а в первой-второй производной к нему ;)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	45. "Анализ популярности языков программирования в 2012 году "	+2 +/–
	Сообщение от kurokaze (ok) on 08-Янв-13, 17:05
	> Собственно, табличка показывает, что новички хватаются теперь не только за Андроид, но > и за iOS. Причем желательно одновременно. > Стараясь не повторять одну и ту же работу на двух языках (Java > и Objective C), они стараются писать код, который может быть использован > под обеими платформами (на С / С++). Отличная иллюстрация к термину "мнение дилетанта", спасибо!
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	104. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от 00OO on 09-Янв-13, 16:35
	>> Собственно, табличка показывает, что новички хватаются теперь не только за Андроид, но >> и за iOS. Причем желательно одновременно. >> Стараясь не повторять одну и ту же работу на двух языках (Java >> и Objective C), они стараются писать код, который может быть использован >> под обеими платформами (на С / С++). > Отличная иллюстрация к термину "мнение дилетанта", спасибо! ДЫк ничо как бы удивительново с Объетками С и нету, стока с етим АйФоном носились, уши все прожужжжали
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	113. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Аноним (??) on 10-Янв-13, 07:43
	> Отличная иллюстрация к термину "мнение дилетанта", спасибо! ну ка, давай, покажи нам не дилетантское мнение.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	83. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 09-Янв-13, 03:49
	> Собственно, табличка показывает, что новички хватаются теперь не только за Андроид, но > и за iOS. Причем желательно одновременно. > Стараясь не повторять одну и ту же работу на двух языках (Java > и Objective C), они стараются писать код, который может быть использован > под обеими платформами (на С / С++). > Интересные мобильные платформы отвлекли быдлокодеров от формоклепания (падение С#). > Вот и все тенденции. Предсказать их можно было без всякого анализа запросов... Если сходить по ссылке и посмотреть внимательно, то видно, что изменения популярности C++ невелики, а вот Objective-C как паровоз летит вперёд, причём уже два года подряд он признан языком года по версии TIOBE (он больше всех увеличил свою популярность за год). На фоне всего этого ваши рассуждения выглядят несколько сомнительными. И насчёт "формоклепания", кстати тоже: Visual Basic.NET популярность стремительно набирает.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	92. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от тоже Аноним (ok) on 09-Янв-13, 08:34
	Я вам даже могу соообщить вопрос года, который привел к такому всплеску запросов по Objective C. Вопрос звучит обычно так: "А вашу программу можно запустить на iPad или iPhone?" К VB я, к счастью, не имею никакого касательства, поэтому задумываться о его популярности даже не собираюсь.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	94. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 09-Янв-13, 09:25
	> Я вам даже могу соообщить вопрос года, который привел к такому всплеску > запросов по Objective C. > Вопрос звучит обычно так: "А вашу программу можно запустить на iPad или > iPhone?" > К VB я, к счастью, не имею никакого касательства, поэтому задумываться о > его популярности даже не собираюсь. LoL. Вы читали только мой коммент, или так же читали коммент на который я отвечал? Давайте мы определимся, кто с кем и о чём спорит. Я выступал, излагая мнение, почему неверно следующее рассуждение: > Собственно, табличка показывает, что новички хватаются теперь не только за Андроид, но > и за iOS. Причем желательно одновременно. > Стараясь не повторять одну и ту же работу на двух языках (Java > и Objective C), они стараются писать код, который может быть использован > под обеими платформами (на С / С++). > Интересные мобильные платформы отвлекли быдлокодеров от формоклепания (падение С#). > Вот и все тенденции. Предсказать их можно было без всякого анализа запросов... Как вы правильно подметили, опровергать это мнение можно, надавив на объективность исходного исследования. Но почему тогда, вы спорите со мной, а не с автором того коммента? Вы пытаетесь опровергнуть моё опровержение, приведя ещё более жёсткое опровержение исходного сообщения? Вам не кажется, что логика сего излишне запутана, чтобы служить блестящей демонстрацией вашего ума и сообразительности? [upd] Ох, я даже не обратил внимания, что вы тоже автор исходного сообщения. М-м-м... Вы точно не хотите обратиться к специалисту, который может изложить азы логического мышления?
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	96. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от тоже Аноним (ok) on 09-Янв-13, 10:07
	Я читал свой коммент и совершенно с ним не спорю. Мне, как человеку, реально вынужденному заниматься портированием на мобильные устройства и повышать то самое количество запросов по четырем языкам сразу, мои комментарии представляются вполне логичными. Попробую разжевать на уровне столь любимых вами азов: даже если вы нормальный человек и пишете нативный код на С / С++, запустить его на планшетах без обвязки на Java или Objective C довольно проблематично. Так что ваше гугление незначительно поднимет результаты по С / С++, и так имеющим высокие позиции, но вполне может сделать Objective C (никому, кроме маководов, не упершийся) языком года.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	97. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 09-Янв-13, 10:51
	> Я читал свой коммент и совершенно с ним не спорю. > Мне, как человеку, реально вынужденному заниматься портированием на мобильные устройства > и повышать то самое количество запросов по четырем языкам сразу, мои > комментарии представляются вполне логичными. > Попробую разжевать на уровне столь любимых вами азов: даже если вы нормальный > человек и пишете нативный код на С / С++, запустить его > на планшетах без обвязки на Java или Objective C довольно проблематично. > Так что ваше гугление незначительно поднимет результаты по С / С++, > и так имеющим высокие позиции, но вполне может сделать Objective C > (никому, кроме маководов, не упершийся) языком года. А... Я, кажется, начинаю понимать вашу позицию. Извините, за то, что тем не менее я продолжаю переходить на личности, но проблема ваша не в отсутствии логики, а в неумении излагать свои мысли. Да, а за необоснованные (как выяснилось) подозрения в отсутствии логического мышления, я приношу свои извинения. Был неправ, каюсь.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	98. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от тоже Аноним (ok) on 09-Янв-13, 10:59
	Я просто стараюсь быть кратким. Вы же возражали на то, чего в моем комментарии просто-напросто не было. Это отсутствующее мы с вами додумывали по-разному, из-за этого и произошло непонимание.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

8. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от Аноним (??) on 08-Янв-13, 13:31
Я сверяюсь по indeed.com/jobtrends, а эта статистика лажа полная
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Анализ популярности языков программирования в 2012 году "	+3 +/–
	Сообщение от meequz (ok) on 08-Янв-13, 13:46
	Я сверяю по tiobe.com, а эта статистика лажа полная
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	21. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Аноним (??) on 08-Янв-13, 14:47
	Молодец!
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	38. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Аноним (??) on 08-Янв-13, 16:39
	вот и на www.google.com/trends картина совершенно иная, чем в новости пущай методику свою публикуют, а то как-то довверия не внушает
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	42. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от TS (ok) on 08-Янв-13, 16:57
	> вот и на www.google.com/trends картина совершенно иная, чем в новости > пущай методику свою публикуют, а то как-то довверия не внушает Ну так давно публикуют - http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_d... Так себе методика, но тем не менее...
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

12. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от Kroz (??) on 08-Янв-13, 13:42
Все логично. З. Ы. Будет чем потроллить Java-филов, а точнее тех из них, которые кроме Java ничего не видели :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Аноним (??) on 08-Янв-13, 14:08
	Этой статистикой кого-то троллить - слоновья толщина.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	37. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от OK (??) on 08-Янв-13, 16:33
	А что жаба, жаба стабильна (на уровне погрешности), никто никуда не бежит, никто никуда не набегает. Удивило сильное падение шарпа только.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	48. "Анализ популярности языков программирования в 2012 году "	+7 +/–
	Сообщение от гном on 08-Янв-13, 17:11
	>  Удивило сильное падение шарпа только. Это дух вендекапца.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	106. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от Аноним (??) on 09-Янв-13, 18:13
	ничего-ничего - подождите выхода Java 8, тогда посмотрим, кто кого затроллит :)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "Анализ популярности языков программирования в 2012 году "	+17 +/–
Сообщение от Anonimoyss (??) on 08-Янв-13, 13:44
> На две позиции вниз упала популярность языка C# Просто отличная новость! Популярность дерьмонета падает вместе с windoze!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Анализ популярности языков программирования в 2012 году "	–3 +/–
Сообщение от ram_scan on 08-Янв-13, 13:45
Количество поисковых запросов коррелирует не только с популярностью языка, но и с количеством геморроя которое порождает использование оного, и ради избавления от которого кодер люто гуглит. Причем чем меньше доступно решений тем кодер гуглит бешенней. Поскольку 20% населения как известно выпивают 80% производимого пива выборку релевантной считать низзя.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Анализ популярности языков программирования в 2012 году "	+6 +/–
	Сообщение от Anonimoyss (??) on 08-Янв-13, 13:51
	> Количество поисковых запросов коррелирует не только с популярностью языка Лажа. Гиморными языками в массе поросту не пользуются - где хаскель, на каком месте? Или скала?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	18. "Анализ популярности языков программирования в 2012 году "	–1 +/–
	Сообщение от Аноним (??) on 08-Янв-13, 14:10
	Так уж получилось, что хаскель и скала — не геморные языки.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	33. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от ram_scan on 08-Янв-13, 16:12
	Сие не геморные языки. Я на сях и языках алгольной группы кодю уже лет 15 как, но до сих пор без гугля и пары-торйки тыков не могу описать на сях тип указателя на массив указателей на структуры, содержащие указатели на функции с определенными прототипами. Или когда мне надо расположить структуру по абсолютному адресу в памяти без трюкачества. А на языках алгольной группы (на той-же аде или модуле-2) я делаю это с первой попытки просто по аналогии без заглядывания в ламерку и с первого раза попадаю. Я удивляюсь как пёрл на первое место не вышел, вот уж где существует стопицот способов сделать очевидную вещь черезжопным способом. В итоге языками алгольной группы я пользуюсь на круг чаще, но по ним гуглю намного реже.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	56. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Crazy Alex (ok) on 08-Янв-13, 18:36
	Эм... Такое, в общем-то, за раз описывать и не надо. У вас же там сущности какие-то? Вот и объявите их отдельно, с именами, чтобы было понятно, о чём оно. Тогда и читателю проще. насчёт структуры по абсолютному адресу не скажу - не надо было, но по идее же один раз макрос под это дело пишется? Это не то чтобы в защиту плюсов (я их как раз за примитивизм не особо люблю) - просто не пойму, зачем это гуглить сто раз.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	86. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от Ordu (ok) on 09-Янв-13, 05:57
	> Сие не геморные языки. Я на сях и языках алгольной группы кодю > уже лет 15 как, но до сих пор без гугля и > пары-торйки тыков не могу описать на сях тип указателя на массив > указателей на структуры, содержащие указатели на функции с определенными прототипами. > Или когда мне надо расположить структуру по абсолютному адресу в памяти > без трюкачества. Неудачные примеры. Про структуру по адресу: её не надо располагать, надо приводить тип указателя. А про указатель на структуру, указателей на функции, указателей на структуры, выше правильно написали, не надо забывать про существование typedef. Зато я могу предложить другой пример, демонстрирующий неудачности синтаксиса: слово const. Попробуйте-ка объявить константный указатель на неконстантный массив константных строк. Слабо?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	87. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 09-Янв-13, 06:01
	> В итоге языками алгольной группы я пользуюсь на круг чаще, но по > ним гуглю намного реже. Странно, что это так. Ведь постоянно приходится искать в гугле какие-нибудь библиотеки, описания этих библиотек, куски кода для копипасты, и прочая, и прочая. Вы что, пользуясь языками алгольной группы, на постоянной основе используете C'шные библиотеки?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	129. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от ram_scan on 10-Янв-13, 17:52
	Понятная и хорошая библиотека идет с читабельной докой и стопятистами примерами. А системную как правило и так помнишь на память. Мне приходится как правило гуглить чтобы понять какого насыпать синтаксического сахару если он сыпется неочевидным образом. В сях очень много таких нелогичностей. Самый простой (правда несколько притянутый за уши, но тем не менее) пример. Обращение к структуре по имени и через разыменовывание указателя. Если на алгольном языке мне достаточно знать что разыменовывание указателя делается через ^, взятие адреса через @ а обращение к полю структуры или юниона через . то я не грея голову пишу ptr^.field когда разыменовываю указатель, и foo.field когда обращаюсь в адрес. Или @foo^.field если мне хочется странного, но это по крайней мере все равно очевидно, логично и всегда так а не иначе, вне зависимости от контекста. Надо два указателя разыменовать ptrptr^^.field. Надо три - ptrptrptr^^^.field. А на сях тех-же самых синтаксис выходит разный, и я, зная, что указатель разыменовывается через * а обращение к полю через . внезапно должен писать ptr->field разыменовывая указатель и foo.field обращаясь в символическое имя (чудны дела твои господи). Двойной указатель будет уже *ptrptr->field, а не, внезапно, ptrptr->->field как бы можно было логически предположить. Интуитивность такой записи за гранью добра и зла. То есть вместо того чтобы помнить два правила которые применимы везде я должен помнить уже три которые применимы каждое в своем случае, причем там где двух по идее вполне достаточно. А голова то не резиновая, а это самый простой пример который только удумать можно. Когда существует куча одинаковых но разных правил, употребимых в одинаковых, но разных контекстах, тогда и приходится ломать голову как правильно покрошить из них нужный винегрет, и гуглить на предмет того, как же блин там коран то это учит делать в данном конкретном случае. Хотя мож я просто дурак и у меня в голове ничего не держится =)
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	131. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Ordu (ok) on 11-Янв-13, 02:55
	> Понятная и хорошая библиотека идет с читабельной докой и стопятистами примерами. А > системную как правило и так помнишь на память. Да, наверное. Это вероятно дело личных предпочтений, но я читаю доки в интернете: быстрее найти и открыть мануал через гугл, нежели искать его на диске. Собственно, в моей домашней генте, я несколько лет назад удалил флаг doc из глобальных USE флагов, поскольку вся документация к библиотекам лежала на диске бесполезным грузом. Но, помимо этого, сначала ведь надо найти эту понятную и хорошую библиотеку, причём для этого надо перебрать, просмотреть и отринуть несколько непонятных и плохих библиотек. > А на сях тех-же самых синтаксис выходит разный, и я, зная, что > указатель разыменовывается через * а обращение к полю через . внезапно > должен писать ptr->field разыменовывая указатель и foo.field обращаясь в символическое > имя (чудны дела твои господи). Двойной указатель будет уже *ptrptr->field, а > не, внезапно, ptrptr->->field как бы можно было логически предположить. Если это вызывает проблем, то можно писать вместо ptr->field так: (*ptr).field. И указатели высших порядков тогда используются по той же схеме: (**ptr).field, (***ptr).field и тп. Тот же самый паскаль, но вместо ^ ставим * и порядок символов другой. А оператор -> лишь, как вы правильно назвали, синтаксический сахар, позволяющий уменьшить количество * перед ptr. В большинстве ситуаций уменьшить количество до нуля, и, вероятно, именно красота и законченность этого нуля и явился причиной введения такого оператора в язык. > [...] > Хотя мож я просто дурак и у меня в голове ничего не > держится =) Я думаю дело не в личных свойствах интеллекта. Дело лишь в том, что на C вы пишите редко. Причём вам не доводилось читать чужой код. Ну или доводилось, но иногда, нерегулярно и понемногу. Такие проблемы стандартны: когда влезаешь в незнакомый язык, начинаешь спотыкаться о каждую мелочь, потому что тот раздел мануала к языку ещё не прочитан, или потому что он после прочтения успешно забыт, или потому, что в мануале явно не описана какая-то тонкость, а прочтение по диагонали не подразумевает вдумчивого восприятия информации. Я точно так же буду спотыкаться, если мне приспичит писать под какой-нибудь там gnat или fpc. Я точно так же спотыкаюсь, когда суюсь в схему после коммон лиспа. Когда не пользуюсь пару-тройку лет python'ом/ruby/чем-угодно-ещё, а потом вдруг что-то начинаю на нём ваять.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	35. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от rshadow (ok) on 08-Янв-13, 16:26
	Ну вот есть же JavaScript ... сам язык убогий да и глюки в реализации под разные браузеры ... и тем не менее все пользуются ибо альтернатив запустить какую нить менюшечку на страничке просто нету.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	76. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от анони on 08-Янв-13, 23:29
	Dart. не пробовал. помнится переводит код в JavaScript
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	95. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Crazy Alex (ok) on 09-Янв-13, 09:46
	Оно монструозное и экспериментальное. В этом плане MS-овский вариант куда интереснее - оверхеда 0 и по фичам вкуснее - в частности, легко интегрируется с существующим JS, позволяя его аннотировать.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	111. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Anonimoyss (??) on 10-Янв-13, 02:54
	Тем не менее m$-овский вариант распространения не получит по очевидным причинам.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	41. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от TS (ok) on 08-Янв-13, 16:53
	http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... Erlang - 31, Haskell - 32, Scala - 33
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	65. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от anonymous (??) on 08-Янв-13, 20:59
	> 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. Статистика из серии "не пришей кобыле хвост".
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	20. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Аноним (??) on 08-Янв-13, 14:24
	> Количество поисковых запросов коррелирует не только с популярностью языка, но и с > количеством геморроя которое порождает использование оного, и ради избавления от которого > кодер люто гуглит. Причем чем меньше доступно решений тем кодер гуглит > бешенней. > Поскольку 20% населения как известно выпивают 80% производимого пива выборку релевантной > считать низзя. Есть мнение, что Парето-отношение просто троллинг переменной толщины, ни в коей мере не являющийся объективным законом. И даже на закономерность не тянущим.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	46. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от kurokaze (ok) on 08-Янв-13, 17:08
	> Количество поисковых запросов коррелирует не только с популярностью языка, но и с > количеством геморроя которое порождает использование оного, и ради избавления от которого Лол, еще один дилетант. Ты для iOS/OSX писал? Апле с каждым годом улучшает язык, добавляя новые фичи, которые помогают решать проблемы донимавшие ранее. Кроме того xcode организован так что весь хелп ты получаешь очень легко без гуглений.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	105. "Анализ популярности языков программирования в 2012 году "	–1 +/–
	Сообщение от 00OO on 09-Янв-13, 16:44
	> Количество поисковых запросов коррелирует не только с популярностью языка, но и с > количеством геморроя которое порождает использование оного, и ради избавления от которого > кодер люто гуглит. Причем чем меньше доступно решений тем кодер гуглит > бешенней. > Поскольку 20% населения как известно выпивают 80% производимого пива выборку релевантной > считать низзя. Скала - роксь! Хаскель фарева :) А если серьезно, ну кому етот Хаскель смешной вперся? Смысл криптовать на нем какой, кроме тешения самолюбия? :) Следующий прогрраммист же обязательно перепишет с нуля; вспоминается П. Грэм со своим Вебпорталом на Лиспе: пришла Яху и переписала по-быстрому ВСЕ-ТО ЖЕ и на Яве. Из чего делается вывод, что написанное на Хаскеле легко и непринужденно, совершенно читабельно и всеми-легко-сопровождаемо можно переписать... да даже на Бейсико-Явах :) И ведь с точки зрения БИЗНЕСА (!) - это самое обоснованное... Все было, все это уже было.. :)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	108. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от trdm (ok) on 09-Янв-13, 21:14
	> Причем чем меньше доступно решений тем кодер гуглит бешенней. я бы выбросил язык по которому нет решений проблем.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

19. "Анализ популярности языков программирования в 2012 году "	+2 +/–
Сообщение от Аноним (??) on 08-Янв-13, 14:17
Lisp на 13ом месте, уже неплохо
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	84. "Анализ популярности языков программирования в 2012 году "	+2 +/–
	Сообщение от Ordu (ok) on 09-Янв-13, 03:52
	> Lisp на 13ом месте, уже неплохо Там ниже ещё есть Common Lisp. Мне вот интересно, строчка Lisp включает в себя достижения Common Lisp'а, или, по мнению TIOBE, Common Lisp -- это не Lisp? ps. Да, если просуммировать достижения Lisp и Common Lisp, то Lisp оказывается на 12 месте. =)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	117. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Аноним (??) on 10-Янв-13, 11:37
	тоже интересно. Scheme наверное тоже не попал в категорию Lisp.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

22. "Анализ популярности языков программирования в 2012 году "	–6 +/–
Сообщение от Аноним (??) on 08-Янв-13, 14:55
Херня этот рейтинг. JavaScript тренд, JQuery в частности. Objective-C тренд, но никак 10% ни использования, ни интереса не может быть. Basic 7-ое, ну-ну. Ну и С на первом как бы намекает на полное отсутствие релевантности.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Анализ популярности языков программирования в 2012 году "	+4 +/–
	Сообщение от Anonimoyss (??) on 08-Янв-13, 15:05
	> Objective-C тренд, но никак 10% ни использования, ни интереса не может быть. Ты отстал от жизни. Айпады и прочая подобная фигня уже везде.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	30. "Анализ популярности языков программирования в 2012 году "	+3 +/–
	Сообщение от Ytch (ok) on 08-Янв-13, 15:52
	> Ну и С на первом как бы намекает на полное отсутствие релевантности. Смешно. Кроме "трендовых" веб-приложений и всякого вашего Ынтерпрайза есть огромный мир embedded (надо пояснять, что софт сейчас есть и в копеечных детских игрушках и в утюгах и холодильниках не говоря уже о более традиционных и специфических вещах?). Угадайте, на чем же там пишут софт? Есть, есть там и javascript - в каждом встроенном веб-сервере пара скриптов всегда найдется, правда он там "зашит" зачастую в виде С-шных строк, но это ведь тоже считается?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	36. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от rshadow (ok) on 08-Янв-13, 16:31
	А что так все взъелись на бейсик? В школах только его и проходят... по всему миру... и лишь немногие из них станут программистами... Но скока поисковых запросов перед контрольными/экзаменами по информатике =)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	51. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от ФФ (ok) on 08-Янв-13, 17:14
	От бэйсика рождаются быдлокодеры макросов и опытные пользователи эксель(tm)
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	57. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Crazy Alex (ok) on 08-Янв-13, 18:38
	От бейсика рождается возможность для пользователя автоматизировать свою работу. Что прекрасно, по-моему.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	68. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от ФФ (ok) on 08-Янв-13, 21:55
	> От бейсика рождается возможность для пользователя автоматизировать свою работу. Что прекрасно, > по-моему. Да, если бы это давало независимость от платформы.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

28. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от IMHO on 08-Янв-13, 15:42
а как же ассемблер ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Anonimoyss (??) on 08-Янв-13, 15:45
	Две стрелочки вверх! ;-)
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	53. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от ВовкаОсиист (ok) on 08-Янв-13, 18:29
	Он вне конкуренции.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

34. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от Нанобот on 08-Янв-13, 16:19
судя по графику, точность измерений где-то в районе ±1-2%
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

39. "Анализ популярности языков программирования в 2012 году "	+2 +/–
Сообщение от Аноним (??) on 08-Янв-13, 16:39
а где 1с?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	47. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от anoname on 08-Янв-13, 17:09
	Действительно, где?
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	58. "Анализ популярности языков программирования в 2012 году "	+3 +/–
	Сообщение от Crazy Alex (ok) on 08-Янв-13, 18:39
	именно там
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	109. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от trdm (ok) on 09-Янв-13, 21:17
	в мировом рейте его не будет.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

40. "Анализ популярности языков программирования в 2012 году "	+1 +/–
Сообщение от o on 08-Янв-13, 16:39
Настанет ява капец, будет счастье!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

49. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от ФФ (ok) on 08-Янв-13, 17:12
А мне всё равно )) Пишу на том, на чём мне надо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от Сергей (??) on 08-Янв-13, 17:13
http://www.ioncannon.net/projects/code2012/ тут твиттероюзеры забавный рейтинг устроили
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

59. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от CPP (??) on 08-Янв-13, 18:40
С Си всё понятно это классика, но неужели джава всё ещё модный язык!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	64. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Aqueelone on 08-Янв-13, 20:17
	Модный не Джава -- а Андроид! Где и лицензию за 100 баксов не нужно покупать в отличаи от Айяйпада-йте...
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	67. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от CPP (??) on 08-Янв-13, 21:38
	Ну, тогда всё сходиться, андроид в моде, язык для кофеварок тоже в моде. Айпад в моде Objective-C тоже в моде. Вышла Виндоус 8 через год график должен покажет какая платформа в моде
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	74. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от Аноним (??) on 08-Янв-13, 22:57
	> Вышла Виндоус 8 через год график должен покажет какая платформа в моде Виндус 8 в моде явно не будет. Потому что страшенное уродство. Гунявый планшет и отстойный десктоп - два в одном!
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	75. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от анони on 08-Янв-13, 23:27
	ни на что Win8 не повлияет. вместе с падением продаж PC падают продажи OS. к тому же ОС ужасна. есть опыт использования. Surface не прижился. WP тоже не особо. кстати это не первая попытка одна ОС для всего. была еще с Windows Mobile
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	79. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от CPP (??) on 08-Янв-13, 23:56
	> ни на что Win8 не повлияет. вместе с падением продаж PC падают > продажи OS. к тому же ОС ужасна. есть опыт использования. Surface > не прижился. WP тоже не особо. кстати это не первая попытка > одна ОС для всего. была еще с Windows Mobile Холиварная тема, так что лучше дождаться нового года и посмотреть что из этого выйдет, а не гадать на кофейной гуще
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	85. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от Anonimoyss (??) on 09-Янв-13, 04:27
	Никчему ждать, гадать, уже достаточно статистики - windoze 8 распространяется много хуже висты. Surface вообще не продаётся.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	91. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от анониммм on 09-Янв-13, 08:23
	Кстати Win9 будет просто обновлением
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

60. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от Виктор (??) on 08-Янв-13, 18:51
Похоже на заказной рейтинг вроде опросов ВЦИОМ или ФОМ. Интересует заказчик этого рейтинга...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	69. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 08-Янв-13, 22:14
	Деннис Ритчи перед смертью проплатил рейтинг на 5 лет вперёд.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

61. "Анализ популярности языков программирования в 2012 году "	+1 +/–
Сообщение от robux (ok) on 08-Янв-13, 18:58
> TIOBE .. строит свои доводы по изменению интереса к языкам, на основе анализа статистики поисковых запросов Люди массово ищут инфу, потому что язык: 1) действительно популярен 2) гемморойный И как прикажите трактовать табличку?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	62. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от ФФ (ok) on 08-Янв-13, 19:02
	> Люди массово ищут инфу, потому что язык: > 1) действительно популярен > 2) гемморойный > И как прикажите трактовать табличку? Популярен, но гемморойный )
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	78. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от robux (ok) on 08-Янв-13, 23:45
	> Популярен, но гемморойный ) Тогда выводы напрашиваются такие: 1) Си самый популярно-геморойный язык 2) Руби наиболее понятный и незаслуженно обделенный вниманием Короче, не зря я пишу на Руби )))
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	110. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от trdm (ok) on 09-Янв-13, 21:19
	> И как прикажите трактовать табличку? чем сложнее и мощнее, тем больше траблов. зависимость геометрическая...
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	139. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от Пингвино (ok) on 13-Янв-13, 14:17
	> чем сложнее и мощнее, тем больше траблов. Пруфы есть или так сбзднул?
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

63. "Анализ популярности языков программирования в 2012 году "	+1 +/–
Сообщение от Аноним (??) on 08-Янв-13, 19:30
если язык популярен, то он конечно геморойный. Потому что безгеморойный язык это тот, на котором не пишут. Это как идеальный муж: не пьет, не курит, не смотрит футбол и не существует.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	99. "Анализ популярности языков программирования в 2012 году "	+/–
	Сообщение от тоже Аноним (ok) on 09-Янв-13, 13:44
	О, я, оказывается, идеальный муж... Где сертификат идеальности получить? Хотя, в принципе, меня и справка о несуществовании устроит. Для налоговой ;)
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

66. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от Аноним (??) on 08-Янв-13, 21:14
Ура в слудующем году (Visual) Basic , будет на 4 месте а то и на первом. Слава TIOBE, и самому шизанутому рейтингу который я виде в IT.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

112. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от Аноним (??) on 10-Янв-13, 03:02
где nodejs ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

133. "Анализ популярности языков программирования в 2012 году "	+/–
Сообщение от Аноним (??) on 11-Янв-13, 11:40
Я подумывал о питоне, чтоб не заморачиваться на Си. Передумал. Я прав?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	134. "Анализ популярности языков программирования в 2012 году "	+1 +/–
	Сообщение от тоже Аноним (ok) on 11-Янв-13, 13:32
	Нет. Надо не подумывать и спрашивать, а пробовать и формировать собственное мнение.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема