Программирование виртуальных предметов

[ermouth]

Прочитал недавно интерактив Алана Кея на HN и наткнулся там на такой вопрос/ответ:

– Do you think we'll ever have a programming language that isn't fully text based and gets closer to a direct mapping of our own thoughts than current systems? If so any ideas what properties this language would have?

–A few years ago I asked another visionary, Marvin Minsky, if he thought that, in the future, we'd do our programming in something other than plain text. He said, "If it's good enough for Aristotle and Plato, it's good enough for me." RIP, Professor.

Я неделю в картинках размышлял, так ли enough это good. Мне кажется, не так уж он и good, можно придумать и получше.

Размышлял я примерно таким образом: коль скоро сам по себе texting, то-есть концепция письменного языка, является ограничителем, надо просто попробовать выбросить эту концепцию.

Звучит диковато – но только на первый взгляд. В самом деле очень многие артефакты реальности либо плохо помещаются в язык, либо вовсе им невыразимы в таком виде, чтобы человек (Homo sapiens) смог адекватно воспринять.

Попробуйте языком – каким угодно – описать движения тай-цзы, например. Физические аспекты ещё можно как-то попытаться, а вот что при этом в голове происходит – вообще в человеческий язык не помещается. Дальше, под катом, суровый гон.

Завязывание шнурков

Тай-цзы (или, там, наркотический приход, или религиозное озарение) – это метафизика, есть и попроще примеры. Попробуйте языком описать, как именно вы завязываете шнурки или распутываете клубок проводов. Эти простейшие и естественные действия помещаются в язык с огромнейшим трудом.

Размышление над этими двумя примерами привело меня к мысли, что при попытке описать (запрограммировать) такого рода действия над реальностью, нужна специальная форма выражения мысли, которая позволяет накладывать термы один на другой.

Язык, а особенно texting, почти не располагает механикой, позволяющей проделывать трюки с суперпозицией термов. Вы не можете говорить хором, вы даже слушать одновременно нескольких людей не можете.

В лучшем случае вторым потоком информации к тексту будет интонирование, а третьим – мимика и жесты, но они пригодны для расстановки акцентов, а не для передачи смыслов вообще (кроме самых простых). Закон Ома одним интонированием не объяснить (или, если угодно, на скрипке не сыграть). И не воспринять.

Хоровое восприятие и инструментальный рефлекс

Зато мы прекрасно воспринимаем “хором” мир предметов, а если быть точным – мир их взаимного расположения и свойств. После недавней истории с перчатками я склонен думать, что инструментальный рефлекс в нас – штука весьма низкоуровневая.

В самом деле, наверняка у вас есть знакомые механики, у которых чрезвычайно бедная и малосвязная речь, но которые разбираются в любых железяках и вообще комбинациях предметов с умопомрачительной скоростью и точностью.

Им речь низачем вообще не нужна для этого, они словами не думают. Они строят в голове модель кусочка реальности, там же в голове его трансформируют, и воспроизводят трансформации обратно в реальности. К таким ментальным моделям слова не просто не нужны, они противопоказаны – фокус теряется.

Hacky code

Между прочим, короткий непонятно как работающий код (hacky) – это вот очень близкое явление. Это артефакты, которые находятся на границах возможностей языка. Нередко объяснение к действительно hacky-коду (или даже тот-же код в не-hacky стиле) занимает многократно больше места и всё равно с большим трудом воспринимается.

Тут дело не в сложности конструкции, а в самом языке, он в этой истории лишний. Зато hacky-код нередко весьма компактно объясняется на простой аналогии из предметного мира, если вы, конечно, в состоянии её представить в необходимой полноте.

Виртуальные предметы

Я полагаю, что действительно новые подходы к инжинирингу ИТ-систем появятся, когда разработка выйдет в виртуальную реальность, составленную из сущностей, которые ведут себя примерно как предметы околореального мира.

2Д и зрения/пальцев для этого очевидно мало. Плоского экрана, даже большого, едва хватает на разработку только texting-ом и немножко деревьями. Именно поэтому все попытки сделать программирование из графических схем не прижились – простынь линий охватывать нисколько не легче, чем stream текста.

С виртуальным пространством другое дело. На нём доступны быстрый шифт, зум, огрубление и снятие оболочек (“углубление” в предмет), тактильное восприятие, температура и тп.

Плюс на этом пространстве работают наши естественные рефлексы. Плюс можно менять геометрию пространства – 3Д-пространства разной кривизны чрезвычайно любопытно выглядят, изменяется восприятие локальности и расстояния.

Можно даже метрику менять – превращать время в пространство для облегчения восприятия больших групповых взаимодействий, например, или вводить вторую ось времени.

Итого

В общем, полагаю, что будущее программироваия не за языком, а за появлением всамделишней среды разработки. Пока в ИТ нет ничего нет даже отдалённо похожего, в лучшем случае в виртуальных мирах производят манипуляции с данными, насколько я знаю.

Что интересно, вот в обычном инжиниринге (мира атомов) системы конструирования, построенные на виртуальных мирах, вполне себе есть. Стало быть, должны и в ИТ появиться.

Что думаете?

Comments

[morfizm.livejournal.com]

Дима, ты попал в тему, о которой я думаю уже лет 20, в лениво-мечтательном ключе, и с удовольствием подумаю над этим больше обычного, если хочешь думать вместе :)

Несколько разрозненных мыслей, к которым я пришёл so far:

1. Язык первичен, мышление вторично (!).

Ты идеализируешь человеческий мыслительный процесс и рассматриваешь язык как ограничение выражения, поэтому ищешь другой язык, способный описать то, что мы уже имеем.

Я считаю, что то, что мы уже имеем, что мы умеем делать в голове - это РЕЗУЛЬТАТ языка, который мы уже освоили (если включать естественные языки - напр., русский, формальные языки, напр., C++, языки жестов, всевозможные контекстно-зависимые таксономии терминов и т.п.). Там в голове есть какое-то низкоуровневое "железо", но мыслительный процесс - это следствие языка. Просто есть некоторый gap между языком как таковым и средствами его выражения (куда более узкое подмножество).

У нас с тобой одинаковый вывод - чтобы поднять ограничение, нужен язык получше. Но ты этот язык ищешь как более лучшее выражение существующих мыслительных процессов, я же считаю, что этот язык нужно искать глубже/шире, независимо от мыслительных процессов, а уже мыслительные процессы под него подстроятся, если язык будет УДАЧНЫМ.

2. Средства разработки это значительный ограничитель.

(Тут мы сходимся).
Может быть даже искать новый язык нужно через поиск нового концепта для IDE (3D, whatever).

* * *

Есть ещё куча мелочей, о которых я думал, но я сейчас не готов связно изложить. Да и многое устарело, нужно подумать обо всём заново. Есть разные приложения и промежуточные решения, о которых я думал. Некоторые из них могут превратиться в standalone startup project, если бы были силы и время делать (или какая-то обозримая коммерциализация, чтобы дали баблосик на пропитание, пока разрабатываешь).

[morfizm.livejournal.com]

Кстати, завязывание шнурков, очевидно, куда проще было бы описать в терминах топологии. Но переносимость топологии на существующие более конкретные языки (и на естественные, и на языки программирования) очень низкая :) Скорее, топология близка к алгебраическим абстракциям, чем к конкретике (PutPixel...).

[ermouth.livejournal.com]

> очевидно, куда проще было бы описать в терминах топологии

😝 Oh really? Что есть «проще»?

Вот тебе начало таблички атласа узлов http://katlas.org/wiki/The_Rolfsen_Knot_Table, воспринимай каждое вхождение как символ алфавита. Теория узлов – это дичайший ад.

Так тебе её и не хватит ещё, потому что когда ты шнурок завязываешь, есть не только шнурок (одномерный объект) вложенный в R3, а ещё и ботинок, который топологически – поверхность, обычно чётного рода, в том же R3, и есть ты, который топологически 2-сфера, и есть непрерывно изменяющаяся конфигурация объединений.

И даже этого будет мало – потому что тебя представлять как 2-сферу в этом случае будет не совсем корректно, потому что смыкая пальцы ты образуешь тор или крендель. Да и шнурок – не совсем одномерный объект, когда ты его держишь хотя бы за один конец, а если ты его держишь в нескольких местах, у него вообще, кажется, нецелая размерность о_О

[ermouth.livejournal.com]

Вот ещё хорошая картинка, почему топология не очень подходит )

[kavnik.livejournal.com]

Идея виртуальных предметов и пространства была интересно показана в фильме "Теорема Зеро". Правда там, насколько я помню, не программировали в таком пространстве, а доказывали что-то из математики.

[ermouth.livejournal.com]

Ага, такой смешной панк и всё решилось молотком в конце концов )

Есть ещё старый-престарый The Lawnmower Man. Там в конце разум, запертый в мэйнфрейме, сканирует порты в цилиндрическом пространстве, замощёном шестиугольниками. Я когда пересматривал, даже на паузу поставил, чтобы подумать, а что потенциально может дать такая организация данных.

[morfizm.livejournal.com]

omfg! :) Ладно, I take back RE "it's much simpler with topology"

[ermouth.livejournal.com]

> если хочешь думать вместе

Хочу )

> Язык первичен, мышление вторично

Решительно не факт, если брать мышление как деятельную тягу к познанию, а результатом мышления – сообщение, которое может быть корректно воспринято предполагаемыми получателями.

Например, с физиологической точки зрения группы нейронов, управляющие кистью руки, находятся рядом с речевым центром, развиваются с ним в тесной взаимосвязи и при этом занимают четверть всей двигательной зоны коры.

Мелкая моторика – сама по себе над-язык с широчайшими возможностями, а texting просто разновидность мелкой моторики. И эта моторика в случае texting-а весьма ограничена носителем, поверх которого моторика действует.

Моторику можно существенно лучше использовать даже саму по себе, а уж со зрением вместе – и подавно.

> этот язык нужно искать глубже/шире, независимо от мыслительных процессов

Это инструмент, их надо делать такими, чтобы под них не надо было подстраиваться. Это они должны подстраиваться, бро )

[morfizm.livejournal.com]

Пост написал для тебя. http://morfizm.livejournal.com/1031820.html

[archaicos.livejournal.com]

Мы думаем следующее... Основная проблема нынче - понять существующий/чужой код чтобы потом можно было его использовать, изменить (и потом использовать) или исправить (и потом использовать). Версию нумер адын всегда писать здорово (нет legacy/compatibility, есть все знания и они свои). Работать с версией сто один уже не так приятно, особенно если ты с предыдущими не работал вовсе. У серьёзных софтин версий аки годовых колец на пне.

Проблема имеет несколько аспектов: сложность/плохая очевидность языковых конструкций (когда мы язык знаем херовенько, с большими пробелами тут и там), прочая йопнутость языка, сложность решаемых задач / объём кода.

С объёмами и сложностью можно бороться только автоматизацией и абстракциями. В голове одного программиста можно уместить много чего, но жонглирование больше чем тремя (или у кого сколько) фиговинами одновременно приводит к ошибкам. Отсюда прямо следует, что нужны инструменты (IDE или что ты там подразумеваешь под «средой разработки»), способные удобно визуализировать код (zoom in/out по абстракциям; отвязать код на экране от его положения в файле относительно другого кода в том же файле) и по нему ходить, способные безошибочно отвечать на вопросы типа где и кем используется или изменяется некий X (а в спорных местах так и говорить, что может использоваться/меняться, но не факт - исследуй сам), способные делать или помогать делать рефакторинг (тупой поиск с заменой не канает), т.е. способные работать не с текстом, а со структурой программы. Тут как-то гугловская презенташка пробегала, где народ делился радостями изменения популярных API в проектах всей компании. Счёт на десятки и сотни тысяч употреблений, кучи проектов/репозиториев, ревью/тесты... Запилили решение на clang.

Йопнутости языка бывают разные. Слишком сложный, неоднородный и т.п. язык плохо усваивается программистом (раскидистые ветви undefined behavior в C++ - сущее зло). Бывают йопнутости, мешающие не человеку, а инструментам. Если IDE должна в себе содержать полный front end компилятора (и даже не только front end, а вообще весь компилятор) только чтобы правильно понять структуру кода и его отобразить, то это ппц (давнишняя и до сих пор насущная бяда C++). А, ещё завязки на build систему сбоку от самого кода. :)

Не думаю, что язык человеческий, какие-то колебания электронов в мозгу или многомерная визуализация (не обязательно визу-; кстати, откуда она возьмётся из груды данных без прямой помощи пользователя, если только он может решить, что ему нужно и в каком виде понятно/удобно?), не думаю, что всё это может как-то помочь, т.к. вносит либо неоднозначности, либо слишком много информации (либо она становится не очень достоверной во время «фильтрации»).

Может, я не о том, но у меня слишком много времени уходит на именно понимание существующего. На алгоритмы и кодирование уходит времени гораздо меньше, чем на понимание и тестирование. Язык - говно, IDE - говно, масштаб - огого. Так выглядит моя жопа сегодня.

[ermouth.livejournal.com]

> способные удобно визуализировать код

Всё что ты дальше пишешь, появится совсем вот-вот, дело пяти лет максимум имхо. Первые ласточки уже есть, корявые.

https://www.youtube.com/watch?v=db-7J5OaSag

http://store.steampowered.com/app/382110

Пока беда с соотношением разрешение/масса у очков, и это единственная проблема, других нет.

[archaicos.livejournal.com]

Корявое существует с испокон веков, и его не хватает. Ждёмс. Никто не хочет потратить мильён-другой, спонсировать работу для приближения светлого дня? :)
Ролики прикольные, но они о другом. И тут, кстати, тоже есть свои проблемы. Куча софта живёт состояниями, в т.ч. распределёнными. Менять что-то в реальном времени, а тем более откатывать в прошлое, - крутая штука, но она не вписывается в такой софт. Либо нельзя сделать (нужно выкинуть и переделать, если возможно в принципе), либо слишком медленно (Компилируецца!), либо нужны хаки вокруг всякого (типа сторонних библиотек).
И я вообще может не хочу глазами работать, они какие-то не железные. :)

[morfizm.livejournal.com]

Мне кажется, это тупиковое направление. У тебя есть код, в котором мегатонна корявости, но там всего лишь одна мегатонна, просто потому что все предыдущие maintenance инженеры с двумя мегатоннами бы уже не справились - оттого система достигла saturation по сложности, потолок. Ты дашь инструменты, упрощающие работу с этим всем говном в 10 раз, и получишь ровно такое же состояние, от которого будет тошнить, только говна в типичном проекте будет не одна мегатонна, а 10. Оно разрастётся ровно до лимитов очередного инструмента.

По-моему, нужно что-то другое, что концептуально меняет процесс разработки. Нужно чтобы корявый код был не нужен или невозможен, или чтобы корявости перестали быть корявостями. Нужно приблизиться к энтропии обычного объяснения у доски. Вот, скажем, сколько надо, чтобы систему в миллион строк кода (15 MB ascii) детальнейшим образом объяснить новичку? Недели-двух хватит с головой. Две недели это (оцениваем сверху!!!) 80 часов, 288000 секунд, слово в секунду (5 символов) = 1 MB. Ну т.е. как минимум в 15 раз должно быть можно уменьшить, сохранив информационную плотность примерно как у обычного разговора (а там дохрена избыточности). Но должно быть ещё лучше. Должна быть возможность проектировать и реализовывать системы таким образом, чтобы даже объяснять их было быстрее, чем за две недели.

[morfizm.livejournal.com]

В эту сторону уже подвижки есть. Писать mutable/stateful код уже не комильфо, и считается хорошим тоном инкапсулировать всё это говно в отдельный кусочек :)

[tonsky.livejournal.com]

Как-то неочевиден переход именно к 3D. В 2D доступно всё то же самое, плюс ориентироваться на плоскости у человека лучше получается. Во всей истории игр, вроде бы, была только одна игра с честным 3D вращением по трем осям (Descent), все остальное так или иначе тяготеет к плоскости (см. интерфейс Homeworld, например).

[grayscaler.livejournal.com]

По-моему мы уже в одном шаге, если даже не половине его, от такого уровня ИИ, при котором программирование как некое внешнее составление инструкций для машины, умрёт полностью.

[ermouth.livejournal.com]

> Как-то неочевиден переход именно к 3D. В 2D доступно всё то же самое

У них, прости, даже название разное. Я почему-то уверен, что тебе не довелось толком попробовать ни очки, ни перчатки – это настолько круче чем любая проекция на 2Д, что я не могу их даже сравнивать.

> все остальное так или иначе тяготеет к плоскости

Ключевое слово «тяготеет». Находясь на Земле, у тебя не получится обмануть вестибулярный аппарат даже будучи в очках, поэтому большинство 3Д миров всё таки с тяготением или вводится какая-то локальная плоскость отсчёта.

[ermouth.livejournal.com]

Думаю, мы от этого далеко – нет даже предпосылок, даже намёков на технологии.

[morfizm.livejournal.com]

Намёки есть. Есть Machine Learning.

Например, ranking functions в поисковиках (Гугл, Амазон) на моих глазах превратились из формул, которые составлял человек (и вручную tweak'ал параметры) в machine-learned ranking, которая тренируется на тех же исходных данных, формирует какое-то внутреннее представление (с на порядки большим количеством степеней свободы, и это представление совершенно невозможно разобрать, осмыслить и как-то перевести на человеческий язык), но при этом perform'ит значительно лучше вручную составленных формул.

[morfizm.livejournal.com]

Мне не очень трудно представить себе будущее (не очень отдалённое), в котором ты даёшь набор end-to-end тестов, пишешь где-то в коде "отправить платёж p на обработку", а система сама разберётся, куда и какой API call нужно вызывать, какие дата конвертеры использовать для преобразования типов, где добавить логгинг и метрики, т.п. Простым сочетанием из service discovery и эвристик, возможно, machine learned.

[morfizm.livejournal.com]

Хинт: набор тестов, целиком и исчерпывающе определяющих все нужные свойства системы и детали взаимодействия между компонентами, обычно не очень большой. И в идеале никакого кода писать не нужно. Ты даёшь тесты + нужен какой-то описательный язык, чтобы тесты достаточно объемлюще и точно сформулировать, и всё остальное подлежит полной автоматизации.

[morfizm.livejournal.com]

Ещё ближе к делу.

Я пишу тесты:
1. f(1) = 1
2. f(2) = 0
3. f(3) = 1
4. f(4) = 0

Если система построена по принципу "ищем простейший solution, удовлетворяющий тестам", то код f(x) = x % 2 может быть написан автоматически. А если вдруг существует что-то ещё более простое, нужно просто добавить тестов, чтобы специфицировать.

[ermouth.livejournal.com]

Понимаю, да. Когда я тебе как-то раз рассказывал про оценку сложности задачи по её «периметру», я имел в виду приблизительно такое описание.

Ты можешь это худо-бедно применять, с огромными костылями, при обработке данных. Но ты вряд ли сможешь выпрыгнуть за границы GADT (индуктивные типы) таким способом. Это значит, ты должен с самого начала, перед тем как задачу ставить, как минимум предполагать, что это за данные – чтобы задать пограничные условия в той или иной форме.

Конечно, чем шире будет «восприятие» твоей системы, способность улавливать закономерности и выводить из них тип, тем выше вероятность ложного срабатывания и пропуска верной закономерности. Твоё x%2 не масштабируется на float – и сможет ли умная система догадаться до этого сама? Что есть «простейший»?

Чтобы дальше не продолжать, вот тебе пруф, что программист всё равно нужен, как раз для задания таких вот «простейших» моментов, иначе задача вывода в общем виде неразрешима как минимум для GADT.

http://research.microsoft.com/en-us/um/people/simonpj/papers/gadt/MS-CIS-05-26.pdf, sections 3.4, 3.5 и самое начало 4. Там страница текста, вполне можно прочесть и уловить, даже не вникая очень глубоко.

В дикой природе, с всамделишними данными, вывод худо-бедно осуществим – не так много примитивных типов данных напридумывано и они неплохо сепарабельны, а для задания границ есть несколько почти всегда работающих методов.

Но я не вижу совсем способа обобщить это на разработку интерфейсов например (что UI, что API, что в реальном мире с IoT) – ты получишь комбинаторный взрыв. «Периметр» получается чрезвычайно прихотливым, «фрактальным» если угодно.

Пример: разложи задачу «Компьютер, сделай мне БД, чтобы API был примерно как у Амазона».

Ещё к одному из предыдущих комментов:
> невозможно разобрать, осмыслить и как-то перевести на человеческий язык

Потому что мешает сам язык.

Если я правильно понимаю масштаб, мне кажется, что найти вне-языковое представление состояния возможно. Более того, я уверен, что для случая с рэнкингом это уже сделано, и не одним способом, потому что как-то же надо понимать, что внутри происходит.

[morfizm.livejournal.com]

Я прочёл, действительно легко улавливается идея. На самом деле, я прямо сейчас сталкиваюсь с этим в Scala. Она сравнима с Хаскеллом в том плане, что там естественным образом возникают совершенно ёбнутые вложенные типы, но style guide диктует стараться писать так, чтобы был максимальный type inference. На практике, на каждые 30 строк моего кода мне приходится давать хотя бы один type hint, иначе Scala угадывает неправильно и кричит на syntax error, или не может угадать вовсе.

По-моему, тут мы видим неразрешимость в общем виде несколько другой проблемы: у тебя есть корректный код, а ты хочешь *ТОЧНО* расставить типы. Я же подошёл с чуть другой стороны: у тебя есть какое-то описание нужных тебе эффектов, результата (скажем, в форме тестов), напиши-ка мне код. Любой, чтобы проходили все тесты. Или скажи мне, что это невозможно - с доказательством или каким-нибудь хинтами (например, подумай, какие тесты нужно выкинуть, чтобы было возможно, и покажи их мне, я перепроверю).

Обе проблемы выглядят экспоненциоально сложными, и для обеих могут найтись неплохие (в практике) эвристики. Кстати, с type inference эвристики работают хорошо. Мне нужно всего 1 хинт на 30 строк, а не указывать везде (что было бы пару сотен хинтов). Делать 1% работы вместо 100% это неплохой результат.

С вариантом "напиши мне любой код (один вариант кода), лишь бы работали тесты" лучше в том плане, что у компилятора много свобод, и есть очевидный "крайний случай". В крайнем случае, если не получилось ничего лучше, он легко сгенерит супер-громоздкую hacky функцию, которая будет напрямую проверять соответствие входа ожидаемому выходу, т.е. будет:
f(x) = {
case 1 => 1
case 2 => 0
case 3 => 1
case 4 => 0
}
Этот код, очевидно, hacky. Насколько код "hacky" можно оценить автоматически (колво проверок, стейтментов, глубина волженности, колво hard-coded констант) - некоторый эквивалент сложности, и, соответственно, у тебя есть оценочная функция для многомерной оптимизации. А тут тебе и оптимизированный перебор, и эвристики, и machine learning - множно применить разные вещи.

Понятно, что нужно как-то не допустить разрастания кода пропорционально кол-ву тестов (ибо тогда этот код не будет работать с новыми тестами), поэтому можно придумать мета-язык для тестов, тестировать сразу шаблоны, или использовать генератор случайных тестов. Да это будет сложнее, это уже как бы программирование, а не просто тупо статический тест, но это таки более простое программирование, чем изобретать, собственно, решение.

Твоё x%2 не масштабируется на float – и сможет ли умная система догадаться до этого сама? Что есть «простейший»?

Простейшесть это вот эта оценочная функция. Её можно трениоровать и твикать, так же как ты тренируешь студента, когда он учит computer science.

Почему не масштабируется на float?
Наименьший тип, в который входят входы и выходы теста, это инт, значит, пишем решение для интов. Если потом нужно скормить куда-то float, закастим, т.к. оно кастится. Это просто. Чтобы этого избежать и искать решение на флоатах, нужно дать тесты получше.

Вот, например, вариант:
1. f(1) = 1
2. f(2) = 0
3. f(3) = 1
4. f(4) = 0
5. f(4.5) = 0.5

Тут можно придумать f(x) = x-int(x), соответственно, будет f(4.2) = 0.2
Если ты имел в виду что-то другое, посложнее, то добавляешь тестов.
Но другие тесты (integration tests) будут добавлять свои constraints. Например, если где-то предполагается, что выход этой функции должен быть непрерывной функцией, то система может поискать более подходящее решение. Будет что-то вроде f(x) = 0.5 + sin((2*x-1)*pi/2)/2

[morfizm.livejournal.com]

Note: я просто размышляю. Идея свести всё к тестам и хорошему языку для их выражения это лишь одна из идей, вполне может оказаться тупиковой. Но нет каких-то очевидных принципиальных неразрешимостей. Хорошая практичная эвристика должна работать не хуже, чем хороший практичный type inference, которому да, нужно иногда специально подсказывать, и да, нужен человек, чтобы смотреть на ошибки. По мере прогресса с AI / machine learning, этот процент ошибок будет всё меньше, кроме того, если язык выражения тестов будет *удачным*, то он разовьёт такую культуру программинга, чтобы легко писался сразу хороший набор тестов - не очень большой, но и достаточный, чтобы задать все необходимые constraints, для того, чтобы минимально простое решение было тем, что ты хочешь, а не читерством. Например, если у тебя есть всего лишь один тест, f(1) = 0, то, очевидно, f(x) = 0 проще, чем f(x) = 0.5 + sin((2*x-1)*pi/2)/2. Хочешь непрерывную функцию, которая альтернирует между 1 и 0, пиши больше тестов, чтобы показать эти характеристики.