Comments 31
Отдельные [аплодисменты] заявлению, что творцам нужно то и они должны иметь это. Между строк ощущается, что вот если иначе, значит возможно и не творец.
Почему наличие ушей вызывает неукротимое желание навешать на них лапшу?
В крупных фирмах есть level-дизайнеры, описанные layout-ы, и все остальное, что б программист не задумывался о том, когда и с какой скоростью будет падать листик. Вот вам пресет-файлик, заполняйте, engine отработает для любой конфигурации.
Им такие фичи в редактор и движок добавлять слишком дорого и слишком мало смысла.
Да, было бы круто, но в большинстве инди механика настолько проста, что тебе не нужно видеть прямо в редакторе, как оно будет.
Как применить эту методику к разработке, скажем, необычного усилителя мощности? Да к любой схеме? А, симулятор. Его возможности тоже не безграничны. К тому же, несмотря на наличие корелляции между уровнем гармоник и качеством звука, примерно равные по измеряемым параметрам схемы могут звучать очень по-разному.
К процессору, проектируемому на языках HDL?
Именно этим таланты и отличаются от посредственностей. Имхо.
Доказательство этому — посмотрите какое количество хитовых видеоигр выпущено на основе готовых движков и конструкторов, типа game maker'а, юнити, RPG maker'а и прочих.
Творец: Смотри как я набросал сортировку этого массива глядя только на результат!
Программист: А будет ли она работать для любых массивов? А какое быстродействие у твоего алгоритма?
Творец: Отстань, занудный человек-компьютер, я — Творец!
В самом начале затянуло оригинально видео. Не заметив, посмотрел до конца. В докладе озвучены две очень мощные идеи, с которыми интересно познакомиться. Главное понять, что речь вообще не о коде.
«Никто не должен быть заложником режима»Отчаянно плюсую. Модальным редактором Vim все же продолжаю пользоваться.
Оттрогает подача материала в типичной коучерской манере: "как стать успешным", "как заработать миллион", "как перестать быть девственником" и т.д. Какие-то портреты культовых людей, которые что-то там изобрели или заявили...
Впринципе идеи автора понятны и приемлимы, если не акцентировать на экстремально столь интерактивном поведении системы разработки. В большинстве случаев чтобы увидеть результат достаточно просто сделать рефреш страницы или перезапустить программу — это не напрягает и реализовано практически везде. И понятно, что делать большую задачу лучше мелкими итерациями, где можно было бы сразу увидеть результат.
Важно отметить, что средства разработки должны быть соответствующими, т.е. компиляция и рестарт должны занимать минимальное время, и когда оно больше пары секунд — это заведомо плохо, т.к. усложняет разработку, мотивирует делать большие итерации, ухудшает тестирование и вообще плохо влияет на ментальное здоровье девелопера. Поэтому выбирайте правильные средства разработки.
Скорее это у вас профдеформация, если вы считаете визуальный входной канал чем-то необычным :-)
В мире есть много ремёсел, где результат виден сразу после начала работы. Так, например, художник видит грубые мазки, которые он нанёс на холст сразу после того как приложил на него кисть.
Скульптор, вырезая из камня Клеобиса и Битона, сразу видит результат, даже если работа над скульптурой только началась.
Клавиши на клавиатуре пианино моментально производят звук при нажатии — музыкант мгновенно получает профит от произведённого действия.
Есть много подобных примеров, где воздействие на что-либо даёт моментальный фидбек в виде звука, изображения, материала и т.д.
Программирование одна из тех вещей, в которой нет визуализации from the box. Её нужно придумывать каждому самостоятельно, чтобы не держать все абстракции в голове. Придумать такую визуализацию, которая повысит вам фидбек и есть та самая мысль, лежащая в основе доклада
Взять те же трассировку и отладку — при нынешних ценах на дисковую память, совершенно ничего не стоит записать хоть состояние всего мира, хоть после каждого оператора (на самом деле хватит и после каждого вызова/ветвления) и потом сделать реплей для разных входных параметров и подсветить разные ветки исполнения, например.
Когда я посмотрел первый раз видео выступления несколько лет назад, у меня был эффект «эврика»! Демонстрации автора очень убедительные, динамика применения изменений поражает любого программиста, который привык ожидать компиляции на каждое изменение. Конечно, всегда были скриптовые языки и байткод (т.к. команды которые интерпритируется на лету), отчасти поддерживающие перезагрузку определённых вещей. Но продемонстрированный подход принципиально более глобальный.
Это было вдохновением, когда я разрабатывал свой игровой движок. В результате игра поставляется вместе с исходным кодом (кроме движка), и движок умеет перезагружать всё на лету — код (C#, XAML (для UI)), шейдеры (HLSL), текстуры, звуки, музыку. Всё это здорово ускорило разработку, и позволило сделать практически безбажную игру (ведь тестировать и отлаживать очень просто и приятно, плюс можно использовать quicksave-quickload для быстрого тестирования определённых случаев после применения изменений), несмотря на традиционно высокую сложность разработки такого рода игр («мини»-ММО).
Движок пока сильно заточен под конкретную игру (и редактор для этой игры), и пока нет возможности его сконвертировать в general purpose game engine для использования в разработке других игр. Надеюсь в будущем появится возможность отрефакторить всё и вывести движок в опенсорс.
Принцип Брета Виктора: «Творцам нужна мгновенная связь с тем, что они создают»