(Заранее прошу извинить за некоторую сумбурность изложения. Здесь также использованы фрагменты из моей переписки с Хоботом)Пофилософствуем немного. В свете появления всё новых, устаревания старых, снова появления новых, быстрой смены парка железяк, снова каких-то маркетинговых изысков и новейших всепрогрессивнейших технологий программирования, новых языков, программных интерфейсов (API) уставшему от всего этого программисту хочется немного расслабиться и порассуждать.
Взять, например, очередного кандидата на всемассовость — Android. Он даже на десктопы целится. А являет собой добрую подборку проверенных и очень массовых технологий: ядро Linux, библиотеки libc, OpenGL, zlib, SQLite, языки программирования Java, Си и C++, язык разметки XML. Вобщем, не поспоришь. Но барьер вхождения, как по мне, чрезвычайно высок, потому что для профессиональной разработки нужно владеть всем этим добром на чрезвычайно высоком уровне. Здесь дело не в том, что “профи должен владеть всем этим”, здесь дело в том, что набор “этого” через 10-15 лет окажется совсем другим, и профи-гонщик мэйнстрима будет очень бледно себя чувствовать в попытках за всем этим угнаться.
Всё это происходило и раньше, но в гораздо более скромных масштабах. Отчётливо помню время, когда никто даже не задумывался, что на рынке карманных ПК доминировать будет не PalmOS и не Pocket PC, и даже не Symbian, а какой-то Android. Сегодня вобщем-то тоже сложновато предсказать что будет лет через двадцать, но хочется быть во всеоружии, не растеряв всех сил в попытках угнаться за мэйнстримом. В конце концов, сколько можно делать всё те же старые вещи всё более новыми способами. Мне хотелось бы запрограммировать свой планшет на ТурбоПаскале с чрезвычайно низким, как по мне, барьером вхождения. И не нужны мне шаблоны и алгебраические типы, как-нибудь проживу и без них. Совершенно солидарен с высказыванием
Last_Alien'а: "Красоты типов нужны только любителям этих красот. Практически нужен хороший язык без излишеств, на котором можно писать не задумываясь о том, какие иероглифы применять. Просто буквы. И чем этих букв меньше, тем меньше отвлекаешься от того что собственно хотел написать."
Итак, что в итоге рисуется. Не чрезвычайно сложный процесс разработки, при котором для создания хелоуворлда нужно знать XML, Java, Android, ООП и ещё тучу всего, а это ж багаж! Душа вопит о возможности писать хотя бы простые проги более простыми средствами, но не тут-то было. Android обфичивается с бешеной скоростью, разработчики еле успевают узнавать новые фишки. Как мы дошли до жизни такой? Темпы взяты столь суровые, что мозг закипает. Вспомните строительные технологии. Гвоздь он и есть гвоздь, и триста лет назад. А бедный ТурбоПаскаль, видите ли, устарел, потому что некие дяди изобрели шаблоны, а другие дяди до сих пор пытаются в них разобраться, плодя, кстати, тонны говнокода. Не без этого.
Ситуация мне видится такой. Когда появились микрокомпьютеры поменьше шкафов — для них сразу начали изобретать интерактивные языки, вшиваемые в ПЗУ, что-то вроде вариаций бейсика. Как самостоятельное нечто эти языки совершенно не имеют ценности, они использовались только благодаря доступности — как способ добраться до возможностей машинок и решать свои задачи. Но из концепта этих "вшитых" языков (BASIC, FOCAL) постепенно сформировались такие монстры как Visual Basic, с той же заточкой на платформу (уже MS Windows). Я нащупал другой путь. А конкретно — основываться не на аппаратной платформе и её особенностях, с "вшитыми" языками, которые появляются почти каждый месяц, но чаще всего ничего интересного из себя не представляют, а основаться на компактном высокоуровневом языке, который не вырос из платформенных особенностей, но из вполне конкретных математических и информационных исследований. Этот язык уже представляет собою кое-что вне контекста отдельно взятой конкретной платформы. Уже понятно, что я про Оберон. И Оберон здесь можно сам рассматривать как платформу. Только не железячную, а языковую.
Платформ много, языков много, разрабатывать под платформу X нормально и без извращений можно часто только на языке Y, что кому-то крайне на руку. Окучиваются новые информационные поля, подрастает поколение любителей сишарпа, которое теряет понимание универсальных средств разработки вместо узкоспециализированных. Хочешь, дядя, программить под платформу X? Учи язык Y. Хочешь программить под X2 ? Учи Y2. И т.д. Т.е. дядя программер, учи миллион языков, тонны интерфейсов и кучу платформенных особенностей. И никто, вовсе никто не даст тебе гарантию, что завтра все эти твои знания будут ещё в цене, потому что предсказать, что будет через десяток лет в этом деле, — практически невозможно. Так что надо сыграть в рулетку. Делайте свои ставки, господа. Ставки сделаны, ставок больше нет. Надо учить, господа вечные студенты и тяжеловесы малоподъёмного мэйнстрима. Учите шарпы и надейтесь пристроиться на работу к поклонникам ms. Или учите Java, на кусочек хлеба авось заработаете. Про html5 и Flash не забудьте. А JavaScript просто-таки необходим для интерактивных веб-страниц. Но также важен и css. А ещё сколько всего есть, успевайте только!
Про VM. Да, как видите, наша мэйнстрим-промышленность не придумала ничего более интересного, чем попытку привести различные аппаратные технологии к единому знаменателю программным путём. На ретро-платформах такая технология вообще бы не была востребована, потому что работать было бы невозможно. Да и на современных платформах тоже приводит к серьёзным накладным расходам по памяти и быстродействию.
А ведь альтернатива виртуальным машинам была предложена —
кодогенерирующие загрузчики Франца. Лишены большинства недостатков как виртуальных машин, так и статически сгенерированных (скомпилированных и слинкованных) исполняемых файлов. Недостатки VM и так понятны — искусственный аналог машинного кода, который не исполняется напрямую процессором, а используется что-то вроде интерпретации. А недостатки заранее собранных программ в том, что если прога собрана, например, для i386, а у нас i686, то она не будет использовать возможности, предоставляемые нашим процессором, полностью оставаясь в рамках набора команд i386. Ну а кодогенерирующий загрузчик на лету (при чтении с диска в память) преобразует программу именно к нужному процессору, максимально идеально используя все его фичи и расширенные наборы команд. Подробнее про эту перспективную (и до сих пор не оценённую толком) технологию
писали Богатырёв и Франц.
Но вернёмся к нашим животинкам. Понимаете куда я клоню. Я уже не вьюнош, чтобы с неизменным запалом встречать всё более новые и разные технологии, пора же наконец-то приземлиться, обрести землю. Нечто такое, что будет развиваться с опорой на уже существующие проверенные и гарантированно хорошие решения. А не как грибы после дождя всё более новое и всякоразное, притом в плохом смысле. Некоторые новые языки программирования просто отвратительны!
Возникает огромное желание избавиться от изучения новых платформ и языков под них, а также от всех сопутствующих SDK, NDK, утилит, освоения тяжеловесного Eclipse и прочее-прочее. Хочу набрать программу на знакомом языке, работающую под знакомым API и нажатием одной кнопки получить её бинарник/дистрибутив под выбранную из списка платформу! Думаете, это невозможно? Да ничего подобного, это более чем возможно. Радует безусловно уже то, что программисты начинают осознавать, ухватывать тенденции, что
именно таков путь сред разработки будущего. Это напоминает историческое отношение к кроссплатформенной разработке, которую очень сильно не поощрял ms с одной стороны и любители всяческой халявы линуксоиды с другой (т.е. они поощряли разнопроцессорность и разноархитектурность, но только под никсами, что не намного лучше).
Тем интереснее было мне увидеть проект
Monkey, который разработан для !!!
- Сборки программ, написанных на одном языке (Monkey) для целой кучи платформ (да знаю я про юнити, знаю, ах оставьте вы меня; монстр ещё тот! ).
А именно:
- Apple iOS, MS Windows 8, HTML5, Flash (ActionScript), Android и др.
Бэк-энды можно разрабатывать самостоятельно. Проект Monkey является коммерческим, но исходники частично открыты. Почти все.
Так вот про резон появления XDev. Мне тут говорили, что не знают, что такое XDev. Пожалуйста, узнайте об этом сейчас. XDev — это мы берём язык программирования с потенциально самым низким барьером вхождения, но при этом универсальный и вполне пригодный для решения широчайшего класса задач. Он может соединить веб-разработку и написание приложений для десктопов, облегчить научные расчёты для экспериментов и разработку для планшетов, решение нетривиальных задач (например, разработку для ретроплатформ, что показывает на практике его универсальность и подчёркивает его самостоятельную ценность) и т.п. Закроем глаза на малую популярность Оберона. Потенциально она большая за счёт простоты. Ведь Оберон — самый простой среди универсальных и самый универсальный среди простых языков программирования. Притом, в отличие от простых языков типа brainf*ck, простота Оберона — практична, даже прагматична. А это значит, что у него, быть может, и не слишком массовое, но несомненно очень интересное будущее. Особенно с учётом того, что его ценители — это обычно очень умные и интересные люди. Не знаю в чём тут секрет, но это так.
Значит взяли мы простой, но мультипарадигменный, объектно-ориентированный и модульный язык. Следующий шаг — это универсальное API, и с этим всё далеко не так просто обстоит. Но Monkey показывает нам, что это возможно! И при всех ограничениях подхода его плюсы превалируют. Т.е. не изучайте десять платформ, десять наборов API и десять языков (или диалектов) программирования для них. Изучите один простой язык, одно простое API и радуйтесь жизни. Хотя бы для вхождения в процесс. Потом, если пойдёт и если выбранное средство достаточно гибко для подстройки к вашим задачам и потребностям, а Обероны именно таковы, это будет значить, что выбор сделан верно. Это нужно уже не корпорациям, не фирмам. А вам, чтобы сохранить вкус к жизни и не превратиться в очкарика-гика, которому ночью в страшном кошмаре снится sudo rm -rf
А в недостатки Оберона давайте не будем углубляться. Никто не отрицает, что его тоже нужно совершенствовать и притирать к задачам, которые перед ним ставятся.
С API вопрос стоит непросто, но решать его нужно, особенно с учётом того, что у нас такой замечательный взят язык. Он просто-таки способствует хорошему проектированию интерфейсов, ибо имеет неподдельную модульность. А секрет хороших кроссплатформенных API крайне прост: придерживаться концептуально уверенных понятий. Т.е. буковка на консоли. Точка. Цвет. А не режим вывода графики, цветовая битовость и разрешение. Первые понятия фундаментальны и могут быть объяснены непрофессионалу достаточно легко. Внутренние же потроха ОС это удел гиков, пусть он им и остаётся. Мы понимаем, что потрохов не избежать, но акценты нужно ставить на более фундаментальном, скрывая внутри детали реализации. Нужно получить аппробированием и последовательным уточнением такое API, которое захотели бы поддержать если не разработчики новых ОС, то хотя бы разработчики библиотек и приложений.
Так вот в итоге просто хотелось бы, как я уже сказал, нажать кнопочку и собрать единый код для выбранной платформы. В Monkey этого достичь удалось, но конечно со многими ограничениями. Ничего страшного, главное, суть подхода ухвачена, нужно развивать его дальше. Для ретро-платформ всё будет намного сложнее, но уже как-то получается совместить такие несовместимые платформы как ZX Spectrum и MS Windows. Да, не будем считать всё это дело окончательным, там тоже есть над чем почесать тыковку, много чего ждёт своего уточнения или банальной оптимизации, до которой ещё не дошли руки. Но макет рабочий, вот что ценно. Теперь, уважаемый программер, можно писать на этом код. А когда появится платформа X10 — не нужно будет уже изучать язык Y10, а просто делать по мере необходимости новые бэк-энды. И целесообразность такого шага будет более чем оправдана за счёт большого количества готового кода под эту технологию.
Конечно в идеале хотелось бы заставить всех производителей поддержать единый язык и единое API, но сами понимаете ситуацию. Это просто недостижимая блажь. Это корпоративность. А голова пухнет у девелопера, который сегодня кодит игру на X1 под Y1, завтра на X2 под Y2 и послезавтра на X3 под Y3, потом в конец ему это надоедает, что произошло и со мной. Можете считать, что я сломался, но — хе-хе, посм
отрите на себя в зеркало эдак через десять лет, и может узнаете.
Здесь очень деликатное различие между универсальным подходом к API и подменой настоящей кроссплатформенности одной-единственной платформой. Позже я, быть может, сделаю об этом развёрнутый пост. Пока же скажу так. Видите, я был бы очень не прочь покодить (хотя бы простенькие вещи) для MSX, NES (Nintendo), Агат (аналог Apple и Apple-II с процем-аналогом 5802), да даже и для БК-шки, той, самой первой (0010) с мини-объёмом ОЗУ. Однако же даже до хеллоу ворлда барьер офигенный — освоить все эти платформы, их тонкости построения, ассемблеры и архитектуру команд, какие есть языки на них и какие реализации, какие библиотеки (ага! а ведь никто не ставил целью собрать всё это в кучу!) — превращает такую идею просто в утопию. Заниматься освоением ретро-платформ никто не будет, потому что на носу бог весть какие планшеты с Android и прочие айфоны. И кодинг для них тоже очень непрост. Тоже требуется освоение новых языков, языков разметки, декларативных языков запросов и прочея. Так вот. После долгих лет программинга возникает желание это всё упорядочить и унифицировать, упростить процесс разработки на базе единого языка и единостильного подхода. Тем интереснее увидеть в действии разницу различных архитектур и платформ, чтобы ещё более углубить своё понимание ситуации. Короче говоря, XDev — это по задумке среда с суперлёгким барьером вхождения, в которой (предположительно) новичок может написать злосчастный хелоуворлд на Обероне и собрать его для тучи разных ретро- и ново- платформ и простым нажатием на одну кнопку сразу запустить, не вникая ни в какие более тонкости. Подход безусловно имеет свои проблемы и ограничения, и даже суровые, но зато он позволяет получить некоторый приток новых людей на старые платформы, повторно пробудить интерес к ним и зафиксировать разработку, а также безусловно понизить барьер вхождения в разработку для новых платформ, как бы оставляя проверенные и здравые вещи в работе, не вышвыривая их на помойку как позавчера суперпрогрессивные (тот же Турбо Паскаль), вчера очень приемлемые (Дельфи), а сегодня “устаревшие”. Но у меня в мозгу не помещается: как
самый здравый способ записи алгоритмов можно называть устаревшим?Но растёт новая генерация быдлокодеров, затыкателей дыр и производителей новых, купающихся в мнимом разнообразии программных парадигм, а на деле — во фрагментации и сегментации, порождённой желанием изобретать новые языки и ещё бог знает чем, посему здесь время остановиться и подумать. Ну вот, надеюсь, вам тоже по душе эта идея.
Я об унификации производства для различных платформ и появлении, как следствие, реализации его для целой линейки платформ. А то, что такой подход возможен, и даже на новомодных платформах, подтверждается аналогичными разработками, показавшими на практике всю достижимость того, о чём я сказал. Monkey — аналог XDev, только на базе другого языка и для несколько других платформ, почитайте, если интересно:
http://habrahabr.ru/post/159377/XDev же — это ретроплатформы в первую очередь, потому что я неплохо знаю Спектрум, DOS, да и винду пришлось изучить. Но ничего не имеем и против новых платформ, поддержку которых сделать можно и нужно, притом на базе того же (!) Оберона (и его расширений). Вот так-то. Не более и не менее, но, заметьте, я буду чрезвычайно рад увидеть подобные же проекты, ибо это очень меня интересует. Спасибо за внимание.
P.S. Хотел эту статью на Хабр, но потом передумал. Неприятные воспоминания.
Наслаждайтесь ею здесь на форуме, мои дорогие единомышленники.
Надеюсь, что объяснил доходчиво из каких именно побуждений растут ножки у XDev. И спасибо товарищу
Хоботу за то, что помог сформулировать.