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

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



RSS


RSS новости


Советы по программированию на всех уровнях (университет, курсы, учебники) сегодня в основном только сбивают с толку. По абсолютно любым рекомендациям, которые вы встретите в ИТ, вы легко найдёте тех, кто будет доказывать вам прямо противоположное. Так можно ли найти тут какую-то сермягу? Мета-сермяга в том, что по каждому вопросу всегда надо идти вглубь, а не скакать по верхам.

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

— "Изучайте абстракции, чтобы сделать ваш код компактнее".

Пол Грэм, основатель Y Combinator и фанат Лиспа

Вы: Ок, буду делать код более абстрактным и минималистичным.

— "Нет, у вас получились неправильные абстракции. Даже копипаста лучше, чем неправильная абстракция".

Sandi Metz (автор книг "99 Bottles of OOP" и "Practical Object-Oriented Design in Ruby")

Её правила для разработчика:

https://habr.com/ru/post/181434/

Вы: Но позвольте! А как мне понять, хорошая ли у меня получилась абстракция для архитектуры моего проекта?

— "Хороший архитектурный дизайн ведёт к простоте".

Max Kanat-Alexander (Technical Lead for Code Health at Google, автор "Code Simplicity: The Fundamentals of Software")

Вы: Ok, я упростил серверный API.

"Нет, вы разломали ваш API, а когда вы разделяете ваш API на кусочки, вы создаёте дополнительную сложность для других программистов".

Max Kanat-Alexander

и так по кругу до бесконечности...

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

=

Сильные идеи приходят в мэйнстрим обычно со стороны – из различных пока академических и малоизвестных областей информатики. Группа ребят из Массачусетского технологического института, ведущая приватные курсы по повышению квалификации разработчиков, по своему основному профилю занимается одной такой довольно специфичной (но реально потрясающей) темой, как синтез программ. Имеется в виду именно автоматический синтез программ с помощью AI, который сможет совершенствовать свой собственный код и сыграет ключевую роль в технологической сингулярности (сериал NeXT 2020 про это). Вроде бы связь с сегодняшней повседневной рутинной работой обычного программиста на первый взгляд совсем непонятна?

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

На практике, на входе вы подаёте спецификации + примеры + структуру...

затем происходит магия синтеза...

(ну, как магия... всегда можно поизучать логи вывода, как переписывание термов происходило... (почитайте "Функциональное программирование" Филда и Харрисона например))

вуаля — получаете корректный работающий исходный код.

=

Если спросить любого программиста, как именно получить корректный код решения, показав ему "спецификации + примеры + структуру", ответ будет очень туманным :) Люди в мало-мальски сложных задачках действуют методом проб и ошибок + страхуются тестированием, полностью готовое правильное решение с ходу в голове практически никогда не появляется, мозгу это не под силу в принципе. Ну и то, что получается, формально корректным тоже назвать нельзя, ошибки вполне вероятны. У разработчика в голове могут формироваться миллионы вариантов, и какой из них верный, никому неведомо... Находится в итоге обычно только какой-то локальный максимум в этом пространстве.

Поэтому так важно умение находить хорошие абстракции и думать "ими", а не кодом, но сейчас речь о другом.

Основных школ синтеза программ три. Есть индуктивный синтез: классическая логика, доказательство теорем, когда формируется набор гипотез, полностью объясняющий все положительные примеры (есть наблюдаемые факты, подгоняем под них теорию :).

Есть поисковая школа — системы, очень умно ищущие в больших пространствах программ. Так ваша СУБД, кстати, оптимизирует SQL-запросы.

А ещё есть подходы, основанные на ограничениях (интеллектуальные решатели вроде Z3, у меня есть небольшой курс по нему).

=

И есть отдельная, очень важная четвёртая школа синтеза. Это люди :)

Вы же пишете программы. И хотя вы работаете немного иначе, чем эти алгоритмы, вы работаете скорее всего по принципу дедуктивного синтеза кода (этой темой в computer science занимаются с 1970-х годов). Общая схема, что на вход поступает некоторая спецификация высокого уровня, которая через ряд механических преобразований делается всё более и более утончённой, точной — до тех пор, пока вы не получите сперва высокоуровневую (формальные абстракции программирования), а потом и низкоуровневую реализацию (код). Классические программисты увидели бы тут схожесть с "проектированием сверху вниз", ну немного похоже, да.

Информация о решении задачи "хранится" не в коде (который сам по себе никак не объясняет способ, которым он был придуман! что с этим делать, скоро на эту тему в СильныхИдеях будет материал), а в логике, в процессе логического вывода, в доказательстве. Поэтому она и существует только в вашей голове.

Например, вам нужно получить функцию (код), которая находит максимальное из трёх чисел, и при этом она гарантированно корректна. Вы готовите формальное определение, записываете логическую формулу (что это "максимальное из трёх" значит вообще), указываете типы аргументов, какие-то предусловия, правила вычислимости... И просите синтезатор сгенерировать код например на Java такой, что это формальное определение будет для него истинно.

Внутри синтезатор может быть тоже по-разному реализован. Например, он может механически выполнять поиск результата, просто комбинируя if, присваивание, return, и довольно быстро получит правильный код (с такой задачкой Z3 легко справится).

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

Кому тема синтеза программ интересна, порекомендую прежде всего курс Нади Поликарповой

https://github.com/nadia-polikarpova/cse291-program-synthesis

которая постдоком работала в MIT, а PhD получала у Бертрана Мейера (по книгам и статьям которого кстати я делал курсы по ООАП, т.к. ACM назвала его лучшим специалистом по ООП).

=

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

Старайтесь рассматривать вашу работу по программированию через призму дедуктивного синтеза, и в итоге этот путь обязательно приведёт вас к гораздо более глубокому пониманию практики программирования в целом.


Источник: github.com

Комментарии: