Мне всегда казалось, что художники и инженеры — одни и те же люди. Я художник И инженер, и я действительно не вижу разницы между ними. И художники, и инженеры, как правило, очень креативны, очень умны и несколько замкнуты. Но художники и инженеры тоже склонны разделяться на отдельные группы, и это печально.
Художники знают, что остальной мир считает их занудами, но они также склонны думать, что инженеры еще зануднее, чем они на самом деле. А инженеры склонны думать, что они намного умнее художников.
Таким образом, каждый из них возводит между собой коммуникационные стены. Требуется кто-то, кто свободно владеет обоими мирами, чтобы передать информацию через стены, чтобы художники и инженеры могли работать вместе. Эти стены замедляют наше общество.
Хотя бывают случаи, когда стереотипы могут быть правдой, большинство художников и инженеров — точно такие же люди. Нам всем говорили, что мы сильны с одной стороны нашего мозга, но это ложь:
Обе стороны вашего мозга сильны.
Являетесь ли вы художником или инженером, вы должны строить вещи. Мы строители. Строители придумывают видение того, что могло бы быть, а мы воплощаем его в реальность.
Когда я смотрю на все удивительные вещи, созданные либо художниками, либо инженерами, я вижу у них одни и те же качества:
- способность экстраполировать решение проблемы
- способность создавать что-то из ничего, следуя видению
- способность брать сложную задачу и разбивать ее на более мелкие, более управляемые подзадачи
- усердие и сосредоточенность, чтобы не сдаваться, когда эти подзадачи продолжают размножаться во все больше и больше подзадач
- стремление и жажда увидеть, как их творения воплощаются в жизнь
Строители решают проблемы. Они создатели решений. В информатике мы используем термин алгоритмы. Алгоритм — это не что иное, как решение проблемы, дорожная карта к цели. Художники используют разные слова. Они называют это созданием конвейера. Это то же самое. Художники создают алгоритмы точно так же, как это делают инженеры. Единственная разница в том, что они не записывают их в коде.
Код — это стена между художниками и инженерами. Код заставляет инженеров-программистов чувствовать себя умными, потому что нам приходится выполнять умственную гимнастику, чтобы читать и писать его. Художники смотрят на код и хотят бежать куда подальше.
В конце концов, код — это просто сложный набор инструкций для компьютера. Эти умственные гимнастики на самом деле являются лишь доказательством того, что общение с компьютерами по-прежнему сложно. Написание кода — это не то, чем можно гордиться. Это проблема сама по себе, которую нужно решить.
Наше нынешнее понимание кода не является окончательным методом передачи наших идей компьютеру. Доказательства этому есть в истории информатики. Большинство программистов сегодня пишут свой код на языках, которые мы называем «высокоуровневыми». К ним относятся C#, C++, Java, Objective C и т. д. Подавляющее большинство систем на всех ваших устройствах (и в Интернете) были созданы на этих языках. Но знаете ли вы, почему они называют их высокоуровневыми?
Это потому, что они ближе к человеческой речи, чем языки, которые были раньше. Многие инженеры-программисты, работавшие на заре появления компьютеров, говорят, что языки более высокого уровня — это не что иное, как «псевдокод». Вам нужно выполнять МЕНЬШЕ умственных упражнений, чтобы читать и писать их; поэтому они поощряют лень.
Хотя языки более высокого уровня позволяют молодым специалистам в области информатики писать ленивый код, эти новые языки также устраняют коммуникативные барьеры между людьми и компьютерами. Эта выгода, похоже, победила. Кто до сих пор создает программное обеспечение, используя Basic? Большая большая группа НИКОГО. Вот кто.
Языки более высокого уровня не понимаются компьютерами автоматически. Их необходимо скомпилировать (то есть преобразовать) в единицы и нули, прежде чем компьютеры смогут обработать их инструкции. Мы все равно используем языки более высокого уровня, потому что они более интуитивно понятны для человеческого общения. Более интуитивный означает более быстрый и эффективный. Вы можете подумать, что инженеры всегда стремятся к большей эффективности, но в данном случае вы можете ошибаться.
Мы, инженеры-программисты, тоже люди (сюрприз?), и, как и все остальные, мы придерживаемся своего пути. Мы можем быть самыми технически подкованными людьми на планете, но мы все еще боимся перемен, как и все остальные. Мы поощряем использование языков высокого уровня, даже если они не обязательно являются наиболее эффективным средством общения. Мы делаем это по двум причинам:
- Мы потратили годы на изучение тонкостей наших любимых языков. Мы не хотим, чтобы они пошли по пути динозавров.
- Безопасность работы. Вы могли бы не платить нам такую огромную шестизначную зарплату, если бы какой-нибудь старый школьник мог делать то, что делаем мы.
Тем не менее, в сообществе разработчиков программного обеспечения есть также этот забавный персонаж Джимини Крикет, которого называют открытым исходным кодом. Идеалы открытого исходного кода бросают вызов нашему страху самоуничижения, заставляя нас признать, что вместе мы сильнее. Мы знаем, что устранение любых препятствий для обмена и общения — это самый быстрый и эффективный путь к техническому прогрессу.
Итак, в духе сообщества открытого исходного кода давайте признаем, что языки более высокого уровня неуклюжи, медленны и неэффективны… не по сравнению с тем, что было раньше, а с тем, что будет после. Вы знаете, что во много раз быстрее высокоуровневого кодирования?
Визуальный скриптинг.
Не зря говорят, что картинка стоит тысячи слов. Мы можем обрабатывать на несколько порядков больше информации глазами, чем голосом, и все же мы используем глаза, чтобы смотреть на одну строку кода за раз.
Писать код не так сложно. Как и в любом языке, это вопрос знакомства с синтаксисом. Сложность заключается в том, чтобы удерживать в голове воображаемую конструкцию алгоритма, пока вы это делаете. Оказывается, большинство инженеров-программистов тратят большую часть своего времени на ДУМАНИЕ, а не на написание. Мы должны подключить систему в своем уме, прежде чем мы сможем сделать это на экране.
Почему мы должны держать столько работы в голове? Это все равно, что делать исчисление без графического калькулятора. Это может быть полезное умственное упражнение, но оно МЕДЛЕННОЕ.
Вместо этого мы могли бы смотреть на трехмерное (т.е. интуитивно понятное для реальной жизни) визуальное представление всей системы по мере продвижения, с возможностью детализировать и манипулировать любой ее частью. Где это решение?
Если мы посмотрим на текущее состояние разработки видеоигр, то увидим, что визуальный код наконец-то появился. Это забавно, потому что «визуальные» — это именно то, что мы называли языками более высокого уровня, когда они только начинали появляться. "Visual Basic. Студия «Визуал». Оглядываясь назад, действительно ли они все такие ВИЗУАЛЬНЫЕ?
Visual Studio ссылается на тот факт, что вы можете создавать пользовательский интерфейс синхронно с кодом, который им управляет. Но когда я говорю «визуальный», я имею в виду другое. Я хочу визуальный КОД. Я хочу графическое представление алгоритма.
Есть много систем в зачаточном состоянии, которые могут это сделать. Они называют это скриптами на основе узлов. У нас был KISMET на Unreal Engine, который превратился в Blueprints. Вместо написания кода вы добавляете и удаляете блоки в стиле LEGO и соединяете их вместе. В мире разработчиков игр есть много похожих визуальных систем на основе узлов.
Существуют аналогичные системы на основе узлов, такие как Mecanim, Playmaker и ShaderForge для Unity. У нас есть Substance Engine для процедурного создания текстур. Многие профессиональные инструменты художников движутся в этом направлении.
Apple xCode с Interface Builder и Microsoft Visual Studio являются СТАРЫМИ «визуальными средствами». Они предполагают, что есть внешний пользовательский интерфейс, который должен быть представлен графически, и внутренний интерфейс, который должен быть представлен в коде. Эти новые записи в сообществе разработчиков игр бросают вызов предположению, что код — лучший способ представить серверную часть. Мы МОЖЕМ сделать заднюю часть ВИЗУАЛЬНОЙ.
Есть еще более низкие барьеры для входа в такие системы, как Game Salad, которые пытаются привлечь разработчиков, не имеющих никакого опыта в области компьютерных наук. К сожалению, большинство инженеров считают эти визуальные инструменты написания сценариев забавными игрушками для художников. В конце концов, эти глупые художники ЯВНО недостаточно умны, чтобы обращаться с языком более высокого уровня, поэтому пусть они развлекаются со своими грузовиками Tonka, пока мы водим настоящие машины.
Если мы на мгновение отложим в сторону коврик для быстрых выводов, то увидим, что не хотим торопиться с классификацией этих визуальных скриптовых движков. Это правда, что визуальные сценарии обычно не являются полными по Тьюрингу. Другими словами, они хороши для своей ограниченной функциональности, но они не могут делать то, что может делать полноценный компьютерный язык (то есть ВСЁ, что вы хотите).
Предположение, что системы визуального скриптинга останутся в этой нише, недальновидно. Художники так же способны создавать алгоритмы, как и инженеры, и они так же жаждут достичь своих целей. Когда некоторые из этих визуальных систем сценариев становятся полными по Тьюрингу, инженеры-программисты всего мира остерегаются. Они придут за вашей работой.
Визуальные скрипты — это новый «более высокий уровень», и когда он будет завершен по Тьюрингу, он сократит разрыв между инженерами и художниками. Переход более чем удвоит количество трудоспособных инженеров-программистов в рабочей силе, что, хотите верьте, хотите нет, очень хорошо, когда мы приближаемся к миллиону незанятых вакансий по программному обеспечению. Кодеры старой школы «высокого уровня» займут старшие должности, а визуальные скриптеры займут должности начального уровня.
Языки более высокого уровня — HD, а визуальные сценарии — 4K. Это только вопрос времени, когда он станет де-факто средством построения программных систем. Инженеры, вы можете подумать: «Да, верно, когда летают свиньи». У меня есть что сказать на это. Бьюсь об заклад, есть тысячи бывших программистов на Бейсике, которые думали точно так же о C++.
