Собственно статья.
Хоть большая ее часть касается Ruby, но в первой половине автор делится интересными соображениями о механизме перехода языка/технологии в разряд mainstream-а.
(перевод мой, прошу не пинать)
Многие аналитики описывали модели принятия технологий. Одна из наиболее популярных была определена в Iowa для описания принятия сельскохозяйственных продуктов, и в дальнейшем была описана в контексте технологий в книге "Crossing the Chasm" Джефри А. Мура. В этой книге Мур описывает цикл принятия технологии в пяти различных группах:
* Технологисты (Technologists). Эта группа предрасположена к принятию новых технологий. Любая многообещающая технология может привлечь их внимание.
* Первопроходцы (Early adopters). Эта группа принимает новые технологии для получения конкурентных преимуществ, вне зависимости от того, насколько они успешные в мейнстриме.
* Прагматики (Pragmatists). Эта группа принимает технологии как только они становятся мейнстримом, или показывают достаточный рост для того, чтобы получить широкое распространение.
* Консерваторы (Conservatives). Эта группа принимает технологии только после того, как это становится необходимым.
* Скептики (Skeptics). Эта группа может принять технологию очень поздно, или не принять ее вообще.
Мур указывает, что ключем к принятию технологии является привлечение прагматиков. Однако прагматики требуют массового принятия технологии, поэтому эта группа хочет видеть других прагматиков, которые используют технологию, до того, как эта группа сама возьмется за технологию. Это ловушка-22. Вы не можете получить прагматиков без других прагматиков. Поэтому вы часто можете видеть тенденции снижения рыночного интереса к продукту после того, как появились первопроходцы, но до появления прагматиков.
...Предложенное Муром решение состоит в пошаговом преодолении этой пропасти (crossing the chasm in stages). Обычно в не можете преодолеть пропасть одним большим прыжком. Вы должны иметь свою рыночную нишу. Java сделала это нацеливаясь на Internet-клиентов сначала через апплеты, а затем перешла в servier-side вычисления, мобильные телефоны и другие ниши, такие как мобильные вычисления и enterprise сектор...
а так же наблюдение о периодичности появления новых мейнстримовых языков:
...Многие из нас понимают, что инвестиции в Lisp можгут привести к повышению производительности, но могут сделать более сложным поиск программистов, документации, библиотек и компонентов. Мы так же вынуждены будет тратить больше, чем нам хотелось бы на любую серьезную интеграцию. По этой причине массовый рынок прнимает новые значимые языки программирования только раз в десять лет или около того. Вы можете видеть эту тенденцию в языках разработки server-side систем: COBOL и Fortran получили распространение в 1954 и 1961, C в начале 1970-х, C++ в середине 1980-х и Java в 1996-м. Я не включил в выборку C# поскольку он удачный клон Java, хотя с нему относится тот же аргумент. Много других языков появилось за это время, но ни один не получил такого распространения как вышеперечисленные...
и далее больше про причины успехов новых языков:
...Взрыв популярности Java был самым большим из виденных до сих пор, но его причины понятны. Для становления нового языка необходимо, чтобы использование старого языка был болезненым и требующим больших усилий. Новый язык должен легко преодолевать эту болезненость и, в конце-концов, быстро переманивать на себя коммунити посредством какого-то катализатора...
(в случае Java таким катализатором стал Internet и Web),
а затем о причинах, по которым бывшие фавориты начинают становиться аутсайдерами:
После того, как Java достигла своего десятилетия, становится необходимым еще один способ оценки рисков. Многие знаковые книги, такие как The Mythical Man Month, Death March, и Peopleware поворят о разных видах рисков:
* Низкая производительность ведет к большим командам и дительным планам.
* Риски увеличиваются с продолжительностью проектов.
* Риски увеличиваются с размером команды.
* Риски качества, измеряемые в количестве багов, увеличиваются с размером кодовой базы.
* Риски увеличиваются со стоимостью
* Стоимость интеграции увеличивается со сложностью.
По мере взросления языка программирования, или даже парадигмы программирования, язык часто деградирует в терминах производительности и выразительности по сравнению со современными достижениями. Проектные команды разрастаются и программистам приходится писать больше строк кода для решения тех же самых проблем. Соответственно, оба этих фактора увеличивают риски. И все эти факторы ведут к неизбежному выводу:
По мере приближения к концу доминирования на рынке, риски производительности, связанные с языком, увеличиваются по сравнению с самыми современными достижениями.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Это всё интересно, но как-то странно выглядит весь этот hype вокруг руби, причём с явой было всё относительно понятно — за ней сан стоял, а за руби? Да и почему именно руби? А не, скажем, Perl 6 (или ещё толпа языков)?
К>Это всё интересно, но как-то странно выглядит весь этот hype вокруг руби, причём с явой было всё относительно понятно — за ней сан стоял, а за руби? Да и почему именно руби? А не, скажем, Perl 6 (или ещё толпа языков)?
Руби считается квинтэссенцией динамических ОО-языков (круче, чем St, к тому же, у него есть рельсы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали: T>Руби считается квинтэссенцией динамических ОО-языков (круче, чем St, к тому же, у него есть рельсы.
Ну вот я тоже думаю использовать его в очередном проекте...
Причина — ребята умеют делать вещи просто. Редкое качество по нонешним временам...
После монстрообразности большинства современных фреймворков, впечетление очень приятное.
Здравствуйте, Курилка, Вы писали:
К>Это всё интересно, но как-то странно выглядит весь этот hype вокруг руби, причём с явой было всё относительно понятно — за ней сан стоял, а за руби? Да и почему именно руби? А не, скажем, Perl 6 (или ещё толпа языков)?
Ну тут сразу много чего можно сказать
Во-первых, аналогия: откуда в начале 2000-х был hype вокруг Linux-а? За ним ведь тогда (конец девяностых, напомню), тоже не стояло еще больших игроков. IBM только в это время подтянулся. И конкуренты в то время у Linux-а были очень серьезные, один только FreeBSD 4.* чего стоил, не говоря про коммерческие Unix-ы.
Про Apache еще можно вспомнить -- как-то так взял, и пробрался тихой сапой на больше чем 50% Internet-серверов.
Во-вторых, особенности самого языка. Улучшенный Smalltalk-овскими возможностями Perl, отсутствие "только одного правильного способа" делать что-нибудь, многоуровневый (новички могут даже не замечать сложности языка, а опытным программистам доступны действительно продвинутые возможности), очень широко распространенный, с большим community. Да еще и, плюс ко всему, обладающий двумя отличными нишами на рынке -- скрипты (поскольку вырос из Perl) и небольшие Web-приложения (благодоря RubyOnRails). Так что Ruby обладает и достаточными возможностями и достаточной зрелостью, чтобы заинтересовать прагматиков.
В-третьих, речь идет о Ruby просто потому, что мне этот язык интересен, я подписан на разные ленты новостей о Ruby и потому обращаю внимание на статьи, касающиеся Ruby. Может быть, что нибудь подобное где-то сказано про Scala, Groovy, Nemerle или Perl 6. Может быть даже лучше. Да только мне это не ведомо
В-четвертых, конкретное название языка, который пытаются спозиционировать как мейнстрим, имхо, не суть важно. Данная статья (точнее первая ее часть) лично мне понравилась именно обсуждением того, как новичок вырывается в мейнстрим, а затем теряет динамизм развития, а затем устаревает. Причем мне понравилась причина, по которой бывший лидер теряет свои позиции -- он менее выразителен, чем его молодые конкуренты. Это так же объясняет, почему в некоторых нишах бывшие лидеры могут оставаться лидерами гораздо дольше, чем это предполагалось. Даже когда вокруг чуть ли не общепризнано, что он уже морально устарел. Ну, например, C++ считается старичком, который по большинству параметров уступает Java или C#. Здесь есть много людей, которые вполне открыто обзовут тебя старпером, человеком, который боится отбросить старые комплексы, ретроградом и пр. в ответ на слова о том, что ты успешно и быстро делаешь что-то на C++. Они могут очень ответственно о доходчиво объяснить, что управляемый язык с супер-пупер IDE увеличивает скорость разработки но сравнению с C++ почти на порядок. И они правы, в общем случае, если браться за какой-то проект с нуля, или делать проект в какой-нибудь модной нынче области (Web или приложения для мобильников). А вот если проект не новый, имеется масса наработок, заточенных под конкретную задачу фреймворков и инструментов, то ситуация-то меняется: новые языки может бы и позволи что-то делать проще и быстрее, но прикладных инструментов для них нет, а на создание новых инструментов нет времени. Да и необходимости, поскольку и существующие инструменты вполне конкурентоспособны.
Ну и, в-пятых, зря я в заголовок темы название статьи вынес. Получился топик с уклоном в пропаганду Ruby. Нужно было что-нибудь нейтральное в название поместить.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Многие аналитики описывали модели принятия технологий. Одна из наиболее популярных была определена в Iowa для описания принятия сельскохозяйственных продуктов, и в дальнейшем была описана в контексте технологий в книге "Crossing the Chasm" Джефри А. Мура. В этой книге Мур описывает цикл принятия технологии в пяти различных группах:
E>* Технологисты (Technologists). Эта группа предрасположена к принятию новых технологий. Любая многообещающая технология может привлечь их внимание.
E>* Первопроходцы (Early adopters). Эта группа принимает новые технологии для получения конкурентных преимуществ, вне зависимости от того, насколько они успешные в мейнстриме.
E>* Прагматики (Pragmatists). Эта группа принимает технологии как только они становятся мейнстримом, или показывают достаточный рост для того, чтобы получить широкое распространение.
E>* Консерваторы (Conservatives). Эта группа принимает технологии только после того, как это становится необходимым.
E>* Скептики (Skeptics). Эта группа может принять технологию очень поздно, или не принять ее вообще.
E>Мур указывает, что ключем к принятию технологии является привлечение прагматиков. Однако прагматики требуют массового принятия технологии, поэтому эта группа хочет видеть других прагматиков, которые используют технологию, до того, как эта группа сама возьмется за технологию. Это ловушка-22. Вы не можете получить прагматиков без других прагматиков. Поэтому вы часто можете видеть тенденции снижения рыночного интереса к продукту после того, как появились первопроходцы, но до появления прагматиков.
E>...Предложенное Муром решение состоит в пошаговом преодолении этой пропасти (crossing the chasm in stages). Обычно в не можете преодолеть пропасть одним большим прыжком. Вы должны иметь свою рыночную нишу. Java сделала это нацеливаясь на Internet-клиентов сначала через апплеты, а затем перешла в servier-side вычисления, мобильные телефоны и другие ниши, такие как мобильные вычисления и enterprise сектор...
Не очень уверен, что Мур этого не знал, а читать его книжку на английском влом.
Приведённая классификация просто отражает количественный состав людей пользующихся данной технологией.
График использования/распространённости технологии приведённый на http://en.wikipedia.org/wiki/Technology_adoption_lifecycle получается очень просто из линейного роста качества технологии. Более подробно (с примерами из биологии, социодинамики и технологии) я об этом написал на http://ariom.ru/forum/p213039.html (хотя и по другому поводу).
Пошагово преодолевать пропасть — это нонсенс. Есть даже такое выражение "перепрыгнуть пропасть в два прыжка", как символ глупости.
Система/технология формируется в маргинальных областях (где она может существовать за счёт своих преимуществ, которых нет у старой технологии), и затем, после достижения определённой степени качества (превышения качества над старой технологией) она распространяется вширь, до тех пор, пока не заполнит всё возможное пространство. Это объективный процесс, грамотный менеджмент может только помочь в этом процессе, но не он его определяет.
Что до Руби — то сложные вещи нельзя сделать простыми. Историю Руби мы проходили уже на примере Perl, Python, PHP и прочих, которые начинались как "вот как просто мы можем сделать", и заканчивались полноценной сложностью языка, тормозами реализации, борьбой со своей простотой (например, в виде невозможности написать сколько-нибудь сложный проект без контроля за типами со стороны компилятора). Руби закончит там-же, где сейчас находятся вышеупомянутые "простые" языки.
ЗЫ Как сказал мне мой брат, которого на фирме специально подрядили исследовать возможность использования Руби на Рельсах — да, если рельсы из точки А в точку Б проложены, то очень удобно и быстро. Но если нужно сделать хоть шаг в сторону — то лучше сразу вешаться.
Здравствуйте, mkizub, Вы писали:
M>Не очень уверен, что Мур этого не знал, а читать его книжку на английском влом. M>Приведённая классификация просто отражает количественный состав людей пользующихся данной технологией. M>График использования/распространённости технологии приведённый на http://en.wikipedia.org/wiki/Technology_adoption_lifecycle получается очень просто из линейного роста качества технологии. Более подробно (с примерами из биологии, социодинамики и технологии) я об этом написал на http://ariom.ru/forum/p213039.html (хотя и по другому поводу).
То, что вы написали в упомянутой вами статье содержит 0.0 информации о том, почему из зародившихся в один момент времени технологий A, B и C выживает только технология B. Полезность же статьи, на которую я привел ссылку, и, как я полагаю, книги Мура, заключается в том, что в ней описываются причины подобных эффектов.
Более того, что более важно, делается акцент на том, что нужно предпринять, чтобы продвигаемая технология выжила (привлекать прагматиков) и как определить, что технология устарела (серьезный оверхед по сравнению с современными аналогами).
M>Пошагово преодолевать пропасть — это нонсенс. Есть даже такое выражение "перепрыгнуть пропасть в два прыжка", как символ глупости.
Ну значит Мур дает глупые советы, которые по каким-то причинам находят подтверждения в истории.
M>Что до Руби — то сложные вещи нельзя сделать простыми. Историю Руби мы проходили уже на примере Perl, Python, PHP и прочих, которые начинались как "вот как просто мы можем сделать", и заканчивались полноценной сложностью языка, тормозами реализации, борьбой со своей простотой (например, в виде невозможности написать сколько-нибудь сложный проект без контроля за типами со стороны компилятора). Руби закончит там-же, где сейчас находятся вышеупомянутые "простые" языки.
По вашим словам складывается впечатление, что вы вообще не знаете Ruby.
M>ЗЫ Как сказал мне мой брат, которого на фирме специально подрядили исследовать возможность использования Руби на Рельсах — да, если рельсы из точки А в точку Б проложены, то очень удобно и быстро. Но если нужно сделать хоть шаг в сторону — то лучше сразу вешаться.
Угу, очень удобно обвинять продукт в том, что он хорошо делает то, на что расчитан. И что не умеет делать то, на что не расчитан.
RoR явился для Ruby тем самым вторым прыжком через пропасть, который вывел Ruby в мейнстрим. Не более того.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>То, что вы написали в упомянутой вами статье содержит 0.0 информации о том, почему из зародившихся в один момент времени технологий A, B и C выживает только технология B. Полезность же статьи, на которую я привел ссылку, и, как я полагаю, книги Мура, заключается в том, что в ней описываются причины подобных эффектов.
Да, там 0 этой информации, потому как она не об этом. Она об объективных причинах роста распространённости сложных систем. А выживание только одной из нескольких подобных технологий — это дело случая. Наглядный пример — доминирование плацентарных млекопитающих в Евразии, и сумчатых в Австралии и Южной Америке.
E>Более того, что более важно, делается акцент на том, что нужно предпринять, чтобы продвигаемая технология выжила (привлекать прагматиков) и как определить, что технология устарела (серьезный оверхед по сравнению с современными аналогами).
Определение "старости" технологии можно легко сделать на основе анализа, сделанного в предположении "линейного роста качества". Как только новая технология переходит в стадию экспоненциального роста — так старая и устаревает.
Привлечение "прагматиков" не есть способ выживания новой технологии, но способ грамотной тактической борьбы. "Прагматики" вообще не переходят с одной технологии на другую, они вымирают, и замещаются новыми прагматиками — иначе это не прагматики. Кто переходит на новую технологию — так это люди, не имеющие никакого представления ни о старой, ни о новой технологии — те, на кого и ориентирован hype.
M>>Пошагово преодолевать пропасть — это нонсенс. Есть даже такое выражение "перепрыгнуть пропасть в два прыжка", как символ глупости. E>Ну значит Мур дает глупые советы, которые по каким-то причинам находят подтверждения в истории.
Скажем так — не до конца осмысленные.
Разумеется, перепрыгнуть пропасть можно только в один прыжок. Кто-то перепрыгивает, и там, на той стороне, создаёт плацдарм. Далее там технология и выращивается, а не пополняется новыми перепрыгивателями. Дело в том, что остальные новые технологии — они тоже там, за пропастью. Поэтому при их актуальном появлении эти пространства и осваиваются перепрыгнувшим новым, а не старым. Примеров демонстрирующих это можно привести массу, а из области программирования — это практически все языки программирования. Почти ни один язык не сдал своих позиций, физики как считали на Фортране, так и считают. Как были написаны программы на Коболе — так они до сих пор и работают. Просто фокус IT индустрии сместился с расчёта формул и экономических расчётов на что-то новое. Сейчас — web. Завтра может быть распознавание образов (звука, изображения) и зачатков ИИ. И так далее.
E>По вашим словам складывается впечатление, что вы вообще не знаете Ruby.
Ну как. Читать я о нём читал. Давно уже читал, много лет назад — я ж компилятор писал, супер-пупер. Интересовался другими языками. Руби меня поразил отсутствием новых идей. С тех пор что-то изменилось? Прочитал сейчас ещё раз википедию про Руби — нет, всё по прежнему...
M>>ЗЫ Как сказал мне мой брат, которого на фирме специально подрядили исследовать возможность использования Руби на Рельсах — да, если рельсы из точки А в точку Б проложены, то очень удобно и быстро. Но если нужно сделать хоть шаг в сторону — то лучше сразу вешаться.
E>Угу, очень удобно обвинять продукт в том, что он хорошо делает то, на что расчитан. И что не умеет делать то, на что не расчитан.
Для езды по рельсам не нужен целый язык программирования. Достаточно хорошей библиотеки с конфигурируемостью.
E>RoR явился для Ruby тем самым вторым прыжком через пропасть, который вывел Ruby в мейнстрим. Не более того.
Ну может и мэйнстрим. Однако ж я старый пердун, много повидал на своём веку, и читал ну совершенно подобные статьи, в которых слово Ruby замещалось на Python, PHP и прочие жутко простые в освоении языки. И их тоже прочили в мэйнстрим, и они туда как-бы даже попали. Вот, объявлений о работе для PHP программистов просто море. Только я одного не могу понять — нафиг нужны PHP программисты, если это такой простой язык. И если он не такой простой и нужны программисты — они что, чего-то более качественного и мощного не могут выучить? (Это я шучу — конечно я понимаю в чём дело, в тех самых прагматиках, которые никуда не прыгают, а их угараздило появится с соской PHP в зубах).
M>Да, там 0 этой информации, потому как она не об этом. Она об объективных причинах роста распространённости сложных систем. А выживание только одной из нескольких подобных технологий — это дело случая. Наглядный пример — доминирование плацентарных млекопитающих в Евразии, и сумчатых в Австралии и Южной Америке.
а можно привести примеры сумчатых в южной америке? имхо они доминировали в австралии по одной простой причине — ничего свежеее на остров не попало после того, как он 50 млн. лет назад от нас отделился. как только туда плацентарных привезли — они всех местных доодяг и съели
> Почти ни один язык не сдал своих позиций, физики как считали на Фортране, так и считают. Как были написаны программы на Коболе — так они до сих пор и работают.
и SAP — маленькая конторка неудачников
E>>По вашим словам складывается впечатление, что вы вообще не знаете Ruby.
M>Ну как. Читать я о нём читал. Давно уже читал, много лет назад — я ж компилятор писал, супер-пупер. Интересовался другими языками. Руби меня поразил отсутствием новых идей. С тех пор что-то изменилось? Прочитал сейчас ещё раз википедию про Руби — нет, всё по прежнему...
в этом и есть его сила руби — прекрасная подборка идей из всех остальных языков, а я их знаю немало. к примеру, такой развитый оператор case есть только в двух яхыках — trac (ну, кто пор него слышал?) и ruby. а как там удобно сделано использование клозур — это взято из смолтока. синтаксис — из эйфеля. и т.д. при всём при этом раби цельный язык, не сборная солянка. он просто сделан со вкусом
M>>>ЗЫ Как сказал мне мой брат, которого на фирме специально подрядили исследовать возможность использования Руби на Рельсах — да, если рельсы из точки А в точку Б проложены, то очень удобно и быстро. Но если нужно сделать хоть шаг в сторону — то лучше сразу вешаться.
E>>Угу, очень удобно обвинять продукт в том, что он хорошо делает то, на что расчитан. И что не умеет делать то, на что не расчитан.
M>Для езды по рельсам не нужен целый язык программирования. Достаточно хорошей библиотеки с конфигурируемостью.
странный какой-то вывод. а перл чем-то лучше в этом плане? или php, питон, jscript? может, для веб-программирования именно такие языки и нужны, вам не приходило в голову?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а можно привести примеры сумчатых в южной америке? имхо они доминировали в австралии по одной простой причине — ничего свежеее на остров не попало после того, как он 50 млн. лет назад от нас отделился. как только туда плацентарных привезли — они всех местных доодяг и съели
В той книже Еськова были примеры (кажется гигантские ленивцы в качестве главных травоядных и т.п.) — вымерли после объединения америк.
>> Почти ни один язык не сдал своих позиций, физики как считали на Фортране, так и считают. Как были написаны программы на Коболе — так они до сих пор и работают. BZ>и SAP — маленькая конторка неудачников
Это уже новое поколение "прагматиков". Выросшее не зная Кобола. И всё равно, главный спрос был на Коболистов при решении проблемы тысячелетия.
BZ>в этом и есть его сила руби — прекрасная подборка идей из всех остальных языков, а я их знаю немало. к примеру, такой развитый оператор case есть только в двух яхыках — trac (ну, кто пор него слышал?) и ruby. а как там удобно сделано использование клозур — это взято из смолтока. синтаксис — из эйфеля. и т.д. при всём при этом раби цельный язык, не сборная солянка. он просто сделан со вкусом
И вкус этот совпадает не у всех. Но надо признать, вкус у Руби более усреднённо-совпадающий, чем, скажем у меня. Мой компилятор вообще никому не понадобился. Так и получается — Руби остался там, где начал, а я решил проблему кардинально — пусть каждый сможет собрать солянку по своему вкусу (или воспользоваться уже имеющейся и добавить чего надо). По дороге выяснилось, что вкус не только от человека зависит, но и от задачи — под разные задачи можно собирать соответствующие солянки. В общем, если уж прыгать через пропасть — то до конца.
M>>Для езды по рельсам не нужен целый язык программирования. Достаточно хорошей библиотеки с конфигурируемостью.
BZ>странный какой-то вывод. а перл чем-то лучше в этом плане? или php, питон, jscript? может, для веб-программирования именно такие языки и нужны, вам не приходило в голову?
Эти языки хороши для написания простых и мелких программок, где производительность совершенно не играет роли. Что и делают на них. А потом задача развивается, и наступает абзац. Тогда придумывают servlet/JSP или аналогичную библиотеку, и радуются, что сложные и эффективные веб-программы на них хорошо решать. А потом на hype слетаются мотыльки, и у них нифига не выходит — слишком сложно. И начинают выдумаывать новый PHP (потому как старый уже тоже развился и стал шибко сложным), называют его Brilliant и цикл повторяется.
У тебя есть идеи, почему не выстрелил тот-же JPython или другой динамический язык интегрированный со статическим, ведь там можно было-бы плавно (по мере усложнения задачи) переходить на более сложные библиотеки? Есть же Groovy, зачем тот-же JRuby — почему цикл опять повторится? Странно всё это. Есть ещё какая-то закономерность в развитии, которую я ещё не уловил...
Здравствуйте, mkizub, Вы писали:
M>Эти языки хороши для написания простых и мелких программок, где производительность совершенно не играет роли. Что и делают на них. А потом задача развивается, и наступает абзац. Тогда придумывают servlet/JSP или аналогичную библиотеку, и радуются, что сложные и эффективные веб-программы на них хорошо решать. А потом на hype слетаются мотыльки, и у них нифига не выходит — слишком сложно. И начинают выдумаывать новый PHP (потому как старый уже тоже развился и стал шибко сложным), называют его Brilliant и цикл повторяется.
PHP, как и perl слишком узко специализированные языки, именно поэтому с ними проблемы в достаточно больших проектах. Те же руби или питон языки общего назначения и таких проблем у них нет.
M>У тебя есть идеи, почему не выстрелил тот-же JPython или другой динамический язык интегрированный со статическим, ведь там можно было-бы плавно (по мере усложнения задачи) переходить на более сложные библиотеки? Есть же Groovy, зачем тот-же JRuby — почему цикл опять повторится? Странно всё это. Есть ещё какая-то закономерность в развитии, которую я ещё не уловил...
Jython во всем кроме доступа к java библиотекам уступает CPython, а учитывая что CPython тоже весьма не беден на библиотеки, то оказыватся что Jython никому и не нужен, ну и плюс сильно неторопливое развитие Jython (до сих пор версия 2.2 в бете, тогда как у CPython 2.5 в релизе) тоже не идет в его пользу.
CPython и есть динамический язык интегрированный со статическим.
Здравствуйте, FR, Вы писали:
FR>Jython во всем кроме доступа к java библиотекам уступает CPython, а учитывая что CPython тоже весьма не беден на библиотеки, то оказыватся что Jython никому и не нужен, ну и плюс сильно неторопливое развитие Jython (до сих пор версия 2.2 в бете, тогда как у CPython 2.5 в релизе) тоже не идет в его пользу.
Так потому и неторопливое, что никто не присматривал и денег разработчикам не подкидывал.
FR>CPython и есть динамический язык интегрированный со статическим.
Интересно. А где там задаются статические типы? Или ты в смысле — с С интегрированный?
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, FR, Вы писали:
FR>>Jython во всем кроме доступа к java библиотекам уступает CPython, а учитывая что CPython тоже весьма не беден на библиотеки, то оказыватся что Jython никому и не нужен, ну и плюс сильно неторопливое развитие Jython (до сих пор версия 2.2 в бете, тогда как у CPython 2.5 в релизе) тоже не идет в его пользу.
M>Так потому и неторопливое, что никто не присматривал и денег разработчикам не подкидывал.
Так и разработчикам CPython тоже мало что подкидывали.
FR>>CPython и есть динамический язык интегрированный со статическим.
M>Интересно. А где там задаются статические типы? Или ты в смысле — с С интегрированный?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, mkizub, Вы писали:
M>>У тебя есть идеи, почему не выстрелил тот-же JPython
FR>А вообще на Java платформе хоть один язык кроме Java "выстрелил"?
Ну так чтоб "серьёзно" то можно сказать нет.
Но есть претенденты — груви, скала, руби с питоном, ещё пхп пот кверкусом запускают
А да, ещё есть CFML, но это узкая ниша, думаю.
Здравствуйте, FR, Вы писали:
M>>У тебя есть идеи, почему не выстрелил тот-же JPython
FR>А вообще на Java платформе хоть один язык кроме Java "выстрелил"?
Больших усилий, однако, стоит продолжение разговора. Поскольку я напряженно пытаюсь найти логику и смысл в ваших словах, но не всегда это удается.
E>>То, что вы написали в упомянутой вами статье содержит 0.0 информации о том, почему из зародившихся в один момент времени технологий A, B и C выживает только технология B. Полезность же статьи, на которую я привел ссылку, и, как я полагаю, книги Мура, заключается в том, что в ней описываются причины подобных эффектов.
M>Да, там 0 этой информации, потому как она не об этом.
Тогда к чему была ссылка на нее?
M>Она об объективных причинах роста распространённости сложных систем.
Я не нашел в вашей статье причин. Там, скорее, написаны глобальные обобщения из каких-то общих наблюдений.
Это как объявление объективным законом восход Солнца не Востоке просто на основании того, что Солнце все время там всходит и эту часть света люди соответственно и назвали Востоком. В то же время настоящие причины (как-то вращение Земли вокруг своей оси) даже не будут упомянуты. Вот так же и ваши попытки объяснения развития и экспансии чего-либо "линейным ростом качества".
M>Привлечение "прагматиков" не есть способ выживания новой технологии, но способ грамотной тактической борьбы.
Так ведь борьба-то идет за выживание. Посему ключем к выживанию как раз таки и оказывается привлечение прагматиков.
M>"Прагматики" вообще не переходят с одной технологии на другую, они вымирают, и замещаются новыми прагматиками — иначе это не прагматики.
Один перл с данного форума я уже поместил в рамочку и расположил на своем рабочем столе. Этот пассаж стал очень сильным претендентом на то, чтобы разместиться рядом с первым.
На самом деле данная фраза находится так далеко за гранью моего мировосприятия, что любая попытка ее анализа/критики испортит ее уникальное очарование.
M>Кто переходит на новую технологию — так это люди, не имеющие никакого представления ни о старой, ни о новой технологии — те, на кого и ориентирован hype.
Как бы это так цензурно прокомментировать. Ну не подтвержается это моим жизненым опытом. Ну никак. Ни в области программирования, ни, скажем, в области зравохранения. Думаю, что любой программист, отработавший в ИТ индустрии лет десять и сменивший несколько предметных областей/мест работы обязательно сталкивался с осознанной неоходимостью смены технологий на более совершенные.
Так же как очень многим хорошо знакомы ощущения от старых бормашин в советский зубных поликлинниках и гораздо более совершенных аналогов в современных платных стоматологических кабинетах. Или, к примеру, переход от ЭКГ к УЗИ в кардиологии или же от простых рентгеновских снимков к компьютерной томографии.
M>>>Пошагово преодолевать пропасть — это нонсенс. Есть даже такое выражение "перепрыгнуть пропасть в два прыжка", как символ глупости. E>>Ну значит Мур дает глупые советы, которые по каким-то причинам находят подтверждения в истории.
M>Скажем так — не до конца осмысленные. M>Разумеется, перепрыгнуть пропасть можно только в один прыжок. Кто-то перепрыгивает, и там, на той стороне, создаёт плацдарм. Далее там технология и выращивается, а не пополняется новыми перепрыгивателями.
Ну так в этом и суть. С одной стороны пропасти молодая и амбициозная технология, со своими достоинствами и недостатками. Самый главный из которых -- о ней не знают или ее просто игнорируют. На другой стороне -- она же, с теми же достоинствами и недостатками. Но уже без самого главного -- ее знают и ее невозможно просто так проигнорировать. В этом и смысл прыжка -- известность.
M>Почти ни один язык не сдал своих позиций, физики как считали на Фортране, так и считают. Как были написаны программы на Коболе — так они до сих пор и работают.
Ну вот, опять. Да посмотрите вы вокруг -- хотя бы на объявления о приеме на работу, или на прилавки книжных магазинов. Языки сдают свои позиции и очень сильно временами. Попробуйте найти сейчас работу для Clipper или Cobol программиста. И это не смотря на то, что программы на этих языках до сих пор работают.
Просто нужно различать жизненый цикл технологии и готовых продуктов, сделанных на основе этих технологий.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, z00n, Вы писали:
FR>>А вообще на Java платформе хоть один язык кроме Java "выстрелил"?
Z>Pizza(GJ) — выстрелил в том смысле, что генерики вошли в Java.
Не выстрелил. Именно что не выстрелил, так как "перепрыгнул пропасть", и за ними никто прыгать не стал.
Generics — да, Мартин Одерски таки пробил в яву. Но добавили в javac, а не стали использовать pizza.
Z>Kawa (scheme на JVM) — достаточно широко применяется для разработки коммерческого софта.
Не слышал, чтоб её использовали.
Z>AspectJ
Это опять-же расширение явы, приделанное к яве "извне", не меняющее даже синтаксиса основной программы.
И не столько выстрелило как компилятор, сколько как модификатор уже скомпилированного байткода.
Как самостоятельное расширение врядли получит дальнейшее распространение — более эффективным, IMHO,
будут JSRы ориентированные на модификацию и верификацию кода на основе аннотаций — в виде плагинов
к javac, использующие javac-овский AST. Сейчас как раз серия таких JSR-ов готовится.
о невозможности "влезть" в уже готовый биоценоз программных продуктов (т.е. технологии в целом), и такие технологии развиваются изнутри, отвергая "пришельцев". Или в русле статьи с которой данный топик начался — Pizza, AspectJ это disruptive изменения, которые не могут войти в состав существующей технологии, потому как они по другую сторону пропасти.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, mkizub
E>Больших усилий, однако, стоит продолжение разговора. Поскольку я напряженно пытаюсь найти логику и смысл в ваших словах, но не всегда это удается.
и у меня такое бывает, особенно вечерком в пятницу
, к тому же, у него есть рельсы. 
руби — прекрасная подборка идей из всех остальных языков, а я их знаю немало. к примеру, такой развитый оператор case есть только в двух яхыках — trac (ну, кто пор него слышал?) и ruby. а как там удобно сделано использование клозур — это взято из смолтока. синтаксис — из эйфеля. и т.д. при всём при этом раби цельный язык, не сборная солянка. он просто сделан со вкусом
