В недавних обсуждениях появилось несколько комментариев, которые достойны того, чтобы поговорить о них отдельно. Особенно в свете появления новостей о языке Go от Google (документацию о котором я изучаю, чтобы затем высказать свои впечатления).
Думаю, что языкам программирования уделяют слишком много внимания. С ужасом наблюдаю, как на форумах/в блогах и т.д. начинаются священные войны/многостраничные срачи и т.д. в попытках найти несуществующий идеал. Еще более смешным выглядит объявление о создании еще одного нового и никому не нужного языка программирования (последний пример - Zimbu от Брана Мулинара). Проблема в том, что в языках программирования всё уже придумано. Изобрести что-то действительно новое и полезное крайне трудно. Меня всегда интересовал и интересует вопрос: какими соображениями руководствуются очередные велосипедисты при создании своих поделок?
Я считаю, что в языках программирования гораздо важнее даже не сам язык, а большое количество готовых библиотек, кроссплатформенность, полноценная IDE с графическим интерфейсом, интеграцией с CVS/SVN и т.д. В общем, вспомогательные вещи, не имеющие к синтаксису языка прямого отношения.
Оба комментария, на мой взгляд, затрагивают один важный вопрос: “Поскольку сами по себе фичи языка и его синтаксис не столь уж и важны, но почему же появляется такое количество новых языков программирования?” Но интересен не только этот вопрос, но и его логическое продолжение: “Что ждет новые языки?” или, в более интересной для программиста формулировке, “Какой из них станет Next Big Language?” Однако, пойдем по порядку.
Насколько я понимаю, новые языки программирования делятся на две категории. Первая категория – это экспериментальные языки, которые создаются своими авторами для проверки каких-то идей. Например, таковыми языками были Pizza и Funnel, на которых обкатывались идеи, впоследствии реализованные в Java и Scala. Вторая категория – это языки, которые создаются своими авторами как рабочие инструменты. Например, языки C, C++, Eiffel, Perl, Java, Python, Ruby, C#.
Полезность языков из первой категории, по-моему, очевидна. Это прототипы для обкатки новых идей или новых сочетаний ранее известных вещей. Такие языки не претендуют на переход в разряд “рабочих лошадок”, их авторы не заботятся разработкой большой стандартной библиотеки, необходимых разработчику инструментов (редакторов, отладчиков, профайлеров и пр.), им не важен размер сообщества пользователей языка.
Единственная опасность, связанная с экспериментальными языками – это горячие головы, которые решают продвигать экспериментальный инструмент в качестве рабочего. Собственно, это не проблема языка. Это проблема тех, кто попадается на такую удочку.
Полезность языков из второй категории должна была быть очевидной. По идее должна быть. Ведь рабочий язык предназначен для того, чтобы было легче, дешевле и быстрее решать какие-то практические задачи, стоящие перед обычными программистами. Понадобился эффективный язык, уровнем повыше ассемблера – появился C. Понадобился еще чуть более высокоуровневый язык, чем C – появился C++. Потребовался безопасный C++ – появился язык Java. Потребовалась заточенный под Windows вариант Java – появился C#. И т.д.
Казалось бы, все здорово, больше языков – хороших и разных! Однако, если появление новых экспериментальных языков – это действительно хорошо, то появление новых рабочих языков, особенно универсальных языков общего назначения – это штука неоднозначная.
С одной стороны, существующие рабочие языки не идеальны. В каждом из них есть изъяны, которые хотелось бы устранить, но нельзя этого сделать, т.к. нельзя терять совместимость. А вот новый рабочий язык мог бы взять лучшие качества из уже существующих, но оказаться лишенным их недостатков. Вот тот же Zimbu – когда читаешь мотивацию принятия тех или иных решений, то все получается складно. Zimbu мог бы стать вполне хорошей заменой C, C++ и D. Мог бы, если бы не одно но.
Очень большое “но”, которое является обратной стороной новых рабочих языков программирования. Рабочему языку нужны инструменты (начиная от библиотек, заканчивая различными анализаторами и “украшателями” исходного кода), нужны информационные ресурсы, нужно большое и живое сообщество. Все это не возникает просто так. На создание библиотек и инструментов нужны огромные ресурсы и время. На создание сообщества нужно время и еще что-то. И все это при том, что в языке будет что-то, что зацепит пользователей (что бывает очень далеко не всегда).
В современных условиях создание нового рабочего языка, для которого стандартная библиотека будет разрабатываться с нуля, для которого будут писаться новые IDE, новые отладчики, новые профайлеры и т.п. – это утопия. Слишком много всего нужно иметь современному разработчику “здесь и сейчас”. Не будет никакого толку от языка, защищающего от обращения по нулевым указателям и гарантирующим не выход индексов за пределы массивов, если для этого языка нет Regexp-ов или средств построения GUI.
Такой язык может стать флагом какой-то группки энтузиастов, для которых целью является использование именного этого языка, а не какого-то другого. Или же язык может занять какую-то узкую нишу, где его качества будут решающим преимуществом, а маленькая стандартная библиотека не будет проблемой (как сейчас происходит с Modula-2, Ada и Eiffel). Но мейнстримом он не станет. А посему, лично для меня такой язык представляет чисто академический интерес – пролистать документацию и посмотреть примеры интересно, но использовать я его не буду.
Совсем другое дело, когда новый рабочий язык позволяет бескровно и бесплатно использовать уже существующие библиотеки и средства разработки для других языков. Например, как C++ в свое время позволил использовать C-шные библиотеки. Как Scala сейчас позволяет использовать JVM, как Nemerle позволяет использовать .NET Framework. Тогда для нового языка все не так плохо. Тогда разработчик действительно может получить выгоды и от тщательно отобранных языковых возможностей, и от унаследованного кода.
Но! Такой новый рабочий язык должен дать разработчику что-то такое, что действительно оправдает переход на него с мейнстримового языка. Например, был интересный язык Nice, который предоставил возможности обобщенного программирования и мультиметоды для JVM еще до того, как в Java появились generic-и. Но Nice не выстрелил. Даже не смотря на очень простую интеграцию с Java. Видимо, преимущества языка не оправдывали отказа от Java. Тогда как Scala потихонечку набирает популярность. Поскольку функциональные возможности Scala, имхо, оправдывают переход на Scala.
Еще один фактор: новые рабочие языки не могут появляться слишком часто. Существует мнение, что мейнстримовый язык меняется раз в десять лет. Поэтому, если новый рабочий язык для какой-то платформы (JVM или .NET) появляется, когда основной язык этой платформы “на коне”, то шансов привлечь к себе внимание и пользователей у него не много. Ведь основной язык пока справляется со своими задачами, его недостатки пока не набили оскомину, у многих пользователей еще не прошло восхищение неофитов. Тем более, что в это время сам язык еще активно развивается и пополняется новыми возможностями. Опять можно вспомнить Nice, который появился в начале 2000-х, как раз когда Java был близок к своему пику. И вскоре после рождения Nice в Java были добавлены generic-и. Совсем другая ситуация сейчас для Scala.
Так вот, пора подводить итог. На мой взгляд, у новых рабочих языков, которые не привязаны к какой-то платформе, нет шансов стать хоть сколько-нибудь заметными игроками. Если только какая-нибудь мегакорпорация не захочет вбухать N сотен миллионов долларов в создание большой стандартной библиотеки и инструментов для разработки (что маловероятно).
Значит, новые рабочие языки должны появляться для распространенных сейчас платформ. К коим можно отнести, в первую очередь JVM и .NET. Но не только. Не следует списывать со счетов C/C++ наследие – т.е. потенциально возможно(?) создать “улучшеный С++”, который сможет использовать мегатонны уже существующего С/C++ кода (что-то типа D или Vala). Так же, наверное, не исключено создание новых языков и для Erlang VM (например, Reia). А может быть, и для Ruby или Python (хотя смысла в этом я не вижу), или даже для OCaml с Haskell-ем :)
Итого: языки типа Zimbu и Go обречены оставаться экзотикой. Языки типа Scala или Fan, или Cobra – вполне могут стать широковостребованными рабочими лошадками (может и не вытеснят основные языки Java/C#, но свое место под солнцем отвоевать смогут). Другой вопрос – нужно ли использовать их? Scala вместо Java я бы рискнул попробовать. Но тут уж каждому предстоит решать самому.
17 комментариев:
Мне вот что еще на ум приходит - не становится ли тенденцией у айтикорпораций брендиться с помощью создания своего ЯП? (Novell тоже засветилась - платными инструментами для разработки на Mono в VS)
Если это тенденция, то IBM'у или Oracl'ю пора бы пригреть Scala (чтобы раз и в "дамки" среди владельцев новых ЯП). Думаю Одерски и Ко будут рады избавится от груза рутинного развития - и уйти в эскперементы. То что планируется в 2.8 - уже вполне можно заморозить, и с интервалом в годик-два добавлять наработанное Одерски.
Как по мне, так пока не похоже. За последние годы было всего два успешных языка от корпораций -- Java и C#. Что получила Sun от Java -- мне не понятно (а судя по их плачевным финансовым делам, ничего и не получила), с MS ситуация понятнее -- они делают для разработчиков привлекательной свою платформу Windows.
Крупные корпорации конкурировали и сейчас соревнуются в разработке языка для больших вычислений (Fortress, Chapel, X10). Но там, имхо, борьба идет за доминирование в "большом железе". К тому же это "нишевые" языки. Go так же выглядит нишевым. Для целей Google он, судя по их C++ Coding Gudelines, это самое то вместо C++. Но нужен ли кому-нибудь Go вне Google, да еще без родной поддержки Windows -- ХЗ.
Так что если какой-то брендинг есть, то он нишевый.
Огромное спасибо за такой подробный комментарий. Единственное, что хочу отметить, что даже если создать “улучшеный С++”, который сможет использовать мегатонны уже существующего С/C++ кода , то думаю все равно успех языку не гарантирован. Сейчас многие рабочие языки содержат средства для обеспечения совместимости с C/C++ (как правило, с чистым C совместимость полная, для C++ вводятся ограничения). Но популярность у этих языков разная.
Я думаю, для востребованности языка в настоящее время, помимо интересных идей в самом языке, нужна та самая мегакорпорация с N сотнями миллионов долларов на продвижение. Ну и разумеется, это должен быть не только язык, а желательно серия интегрированных друг с другом продуктов. Например, Microsoft: ОС - Windows, СУБД - SQL Server, средства разработки - Visual Studio. То есть эти продукты должны образовывать замкнутую систему (платформу). Обязательно нужны перспективные исследования (посмотрите сколько людей работают для MS: http://research.microsoft.com/c/1044, а также интересные программы на http://channel9.msdn.com/shows/Going+Deep/). Безусловно, не нужно забывать и о хорошей документации продуктов и книгах.
p.s. На самом деле эти два комментария мои, только почему-то под разными именами (ссылки на профиль одинаковы).
2Quaker: имхо, мегакорпорация и мегабаксы могут продвинуть перспективный язык за короткое время (лет за 5-6). Без мегабаксов язык так же имеет шансы продвинуться, но в разы медленее. Например, Ruby потребовалось больше 10 лет, чтобы выйти в мейнстрим.
По поводу C++ -- лично я не верю, что можно сделать его улучшенный вариант, который бы имел тесную интеграцию с C++библиотеками (пусть даже не Boost, но хотя бы с ACE). Но и отрицать такую возможность не могу -- мало ли что. По-моему, был какой-то язык, который транслировался в C++, но вот не помню его названия (что-то типа XLR).
Далее к каждому предложению приписывается столь ёмкое "слово" ИМХО.
То, что в ЯП уже придумано всё, что можно, это правда... почти. Ну можно подождать лет 20-40 и посмотреть, может я окажусь неправ.
Кстати, есть еретическая идея, что в ближайшем будущем мы будем писать код правя не прямо сам файл кода, а некую нужную "формочку", которую нам будет подсовывать IDE.
Зачем такое безобразие? А потому что нужные проверки всего и вся ради достижения великой цели корректности кода сваливаются в функции. Да, проверки нужны. И с точки зрения логики и с точки зрения корректности.
Буду гнать примеры, показухи ради возьмём Си++, так сказать худший случай (А-то в Яве вроде можно схитрить).
Значит, на вход методу/функции. Полдесятка параметров, указатели разные, числа какие-нибудь.
Прежде, чем радостно кидаться сохранять параметры и/или считать что-нибудь, надо проверить их корректность. Так-с, указатели проверяем (довольно часто приходится) на NULL, остальные параметры на ограничения, дёргая какие-нибудь специальные для этого методы.
Ну, наконец, всё хорошо, все входные корректны, в противном случае мы же правильно записали об этом в лог и/или показали окошко с ошибкой, а потом вернуть что-то такое, показывающее, что мы ничего не сделали.
Потом мы как-то меняем внутреннее состояние, Тут ещё нужно заассертить, вдруг, некоторые из полей "случайно" перестали удовлетворять ограничениям (Тут меня уже начинает заносить, но ведь на всякий случай), мы опять дёргаем методы, опять куда-нибудь записываем или падаем, наконец :). Всё, наконец, мы всё сделали и возвращаем результат.
Как-бы всё... Но нет, теперь представьте тот if (ну или специальный "ассерт", который не про ошибки в логике), что обрабатывает эту функцию.
Проблему ведь я из пальца высосал, да?
------
Я хочу вернуться к тому, что всё уже придумано. Да всё уже придумано. Просто то, что хочется в одном языке есть в другом, и наоборот. Поэтому начинаются всякие комбинации, а давайте сделаем так и так.
Я как-то много времени потратил на мысли о новом ЯП, да вот логически всё приходило либо к С++, либо к managed Java/C#. Не полностью, но очень похоже. То есть совпадали некие основополагающие принципы, ну просто как пример, есть сборщик мусора или нет, есть исключения или нет :)). Всякие "детали" вроде синтаксиса языка, кажутся вообще какой-то мелочью (которую, конечно, тоже нужно продумывать) по сравнению с глобальным вектором, состоящим из некоторых вопросов :).
Кстати, стремление объединять особенности разных языков оно часто (у меня, конечно) выходит плачевное. То есть либо это попытки скрестить нескрещиваемое... либо это просто плохие попытки :). Например, одна из таких: без сборщика мусора в синтаксисе оставить только ссылки, ну и базовые типы (вроде целочисленные) это сами типы, а не ссылки.
К чему я? К по большей части бесплодности попыток. Я не гуру в проектировании и в программировании, конечно, тоже. Но просто логически пытаясь соединить всё то, что хочется иметь в языке - постепенно закрадывается подозрение, что не сходится. Начинаю одумываться.
Ну, наконец, всё хорошо, все входные корректны
Контрактное программирование, Eiffel?
Поэтому начинаются всякие комбинации, а давайте сделаем так и так.
Эпоха стремления к концептуальной чистоте и минимализму (Lisp, C, Smalltalk, Oberon) прошла.
От анализа - к синтезу?
Всё это очень хорошо, но как в эту схему укладываются, например, сами Питон и Руби, их успех?
>Всё это очень хорошо, но как в эту схему укладываются, например, сами Питон и Руби, их успех?
Имхо, один в один укладываются. Главным образом из-за того, что на момент их возникновения объемы стандартных библиотек были совсем другими. Сейчас же ситуация сильно изменилась. Еще важно, что у них в своей нише было мало конкурентов. Ну и плюс к тому, этим языкам потребовалось почти по 10 лет, чтобы стать мейнстримом (Ruby так и больше).
2Alexander P.: >Значит, на вход методу/функции. Полдесятка параметров, указатели разные, числа какие-нибудь.
Прежде, чем радостно кидаться сохранять параметры и/или считать что-нибудь, надо проверить их корректность.
Имхо, история развивается следующим образом: сначала в функции можно было передавать все, что угодно. Потом стали добавлять средства проверки переданных аргументов (assert, design by contract). Теперь усилия направлены на то, чтобы неправильные аргументы вообще нельзя было передать и/или использовать.
Думаю, что новые языки могут появляться и сейчас. И для этого не нужны мегавложения.
Откуда, например, ПОПУЛЯРНОСТЬ python. Информационная поддержка и имидж Гугла. Не думаю, что они серьезно вложились деньгами. Основная идея такая, что языками программирования пользуются по двум причинам (основным): деньги и Just for Fun. На php, Java, C# пишут чтобы заработать. Ruby, напрмер, больше for Fun (причем гораздо больше, чем Python, например, но когда будучи студентом выбираешь, какой язык изучать, то информация о том, кого "крышует" Гугл и размышления про полезность языка на новом месте работы существенно влияют на выбор). C и C++ совмещают то и другое (в этом и причина их популярности). Языки чисто для зарабатывания бабла (Java, C#) содержат, обычно, в себе столько ограничений (которые на них накладывают их создатели для достижения собственных целей), что там Фаном и не пахнет.
Как вариант появления нового языка: Гугл начинает использовать его (и предлагает другим) в каком-нибудь проекте типа AppEngine. Язык должен быть достаточно удобным в своей нише. Энтузиасты найдутся, далее если гугл не станет его ограничивать, он разойдется шире (Just for fun, если я студент и хочу написать что-то для этой модной гугловой новинки - я его выучу, к тому же, глядишь при устройстве на работу это поможет). Для профессионалов он тоже должен быть чем-то интересен. Если при этом коммерческие заказы появятся под эту новую AppEngine (как, например, постоянно появляются заказы написать приложение для vkontakte.ru), то будет повод и профессионалам начать использовать его и писать и продвигать какие-то библиотеки под него.
Подход, что нужно много бабла, готовых библиотек, декументации и вообще без целостной системы из оси, базы и среды разработки ни жить - неверный (крупным конторам очень выгодно, чтобы так думали :-) ). Точнее это один из вариантов, но не единственный. Нужен язык без дибильных ограничений со стороны коммерческой конторы со своими целями и ценностями, достаточно удобный для решения широкого круга задач, легко расширяемый хотя бы сишними библиотеками. В нем должен быть Fun для энтузиастов (чтобы в нем захотели копаться и писать библиотеки) и для него должно быть какое-то коммерческое использование (хотя бы веб фреймворк, который можно поставить работать через fastCGI в виртуалке и который будет решать какие-то задачи, плохорешаемые тем же php). Т.е. новый язык, с новыми возможностями, созданный для решения текущиих прикладных задач, без дибильных ограничений и возможностью его коммерческого использования вполне может появиться и войти в мейнстрим.
>Откуда, например, ПОПУЛЯРНОСТЬ python. Информационная поддержка и имидж Гугла.
Питон завоевал свою популярность еще до того, как Гвидо пришел в Google работать.
ps. Остальное прокомментирую чуть позже.
>Основная идея такая, что языками программирования пользуются по двум причинам (основным): деньги и Just for Fun.
Fun-ом можно привлечь технологистов и, может быть, early adopter-ов. Но для прагматиков и, уж тем более, скептиков, Fun заключается совсем в другом.
К тому же не понятно, о каком Fun-е в языке может идти речь? Например, в C++ есть возможность обратиться по битому указателю или выйти за пределы массива и тратить массу времени на поиски проблемы. А в Java это вылавливается на раз. Это будет Fun-ом? Или в C++ сейчас нет замыканий и итерация по коллекции -- это цикл (или подключение буста), а в Ruby -- вызов метода each с передачей замыкания. Получается короче и проще. Это Fun?
Или Fun заключается в возможности решения каких-то задач, которые раньше не решались вообще? Скажем, с помощью блоков кода Ruby я сделал Mxx_ru. С помощью Java раньше делали Java-апплеты. С помощью .NET-а сейчас спокойно объединяют код на VB, C# и F# в одном приложении -- без траха и пыли. Все это Fun?
>Т.е. новый язык, с новыми возможностями, созданный для решения текущиих прикладных задач, без дибильных ограничений и возможностью его коммерческого использования вполне может появиться и войти в мейнстрим.
Мой поинт в том, что на данный момент этого сильно недостаточно. С появлением Java правила игры изменились.
Мой поинт в том, что на данный момент этого сильно недостаточно. С появлением Java правила игры изменились.
Просто нужна платформа для нативных языков, LLVM вполне может ею стать.
>Просто нужна платформа для нативных языков, LLVM вполне может ею стать.
Если какая-нибудь мегакорпорация (яблочная, скажем), вбухает в нее N миллионов долларов ;)
Тык вроде уже вбухивает, кроме яблока еще и Adobe.
>Тык вроде уже вбухивает, кроме яблока еще и Adobe.
Интересно. А Adobe-то это зачем? Или они какое-то свое расширение для C/C++ хотят сделать (как Apple с блоками кода для GCD)?
Вроде хотят JIT для ActionScript сделать на базе LLVM.
Ну и наверно им LLVM интересна как платформа, у них же там сплошь хардкорный C++.
Отправить комментарий