| Serguey Zefirov ( @ 2008-02-24 21:30:00 |
Всякое разное.
Шел по улице, увидал рекламу Хонды, "Эволюция лидера." Изображена какая-то Хонда, а вокруг нее такие красные, желтые и белые полосы, как обычно бывает на ночных снимках автодорог. С одной стороны, это вызывает ощущение движения, с другой (после некоторого раздумья, однако) понимаешь, что Хонда стоит, а ее обгоняют все, кому не лень. Куда, спрашивается, эволюционировал лидер?
Случилась тут небольшая рубиловка в
ru_lambda насчет применения Scrap Your Boilerplate.
Я хочу подробней изложить причины моего скептицизма по отношению к использованию сложных конструкций языков программирования и SYB в том числе.
Для решения задач из предметной области необходимо реализовать ее модель. Очень часто предметная область просто совсем неизвестна или отличается от известной в какую-то неожиданную сторону. "Все легкие проблемы уже решены," так сказать. Поэтому работа программиста обязательно включает в себя работу исследователя, он поднимает такие вопросы, которые эксперты считают, допустим, само собой разумеющимися и в которых и находится корень проблем.
Такие вопросы надо вскрыть быстро, для этого надо быстро разобраться в предметной области. А для этого язык программирования не должен стоять на пути. В нем должна быть возможность адекватного задаче уровня абстракции. И "адекватный" здесь означает "не слишком высокий" тоже. Грешно использовать слишком абстрактные инструменты там, где можно обойтись более специфичными.
Например, для разбора файлов типа SREC монадические комбинаторы будут слишком сложны. А построчное сравнение с образцом - например, ('S':'0':'5':a:b:c:d:nibbles), - в самый раз.
Хаскель предлагает достаточно удобный для большинства задач уровень абстракции - алгебраические типы, сравнение с образцом, классы типов. Забираясь выше, легко попасть в ловушку не решения проблемы предметной области, не достижения цели, а решения проблемы отображения решения проблемы предметной области на фиксированный уровень абстракции и ни ангстремом ниже.
Неинтересно.
Это все равно, как изучать Дим Мак без изучения тактики поединка.
Абстракции, кстати, я люблю, но как-то "большими шагами." То есть, специально изучать тот же SYB или GADT ради улучшения знания Хаскеля я, пожалуй, не буду, а вот разобраться с зависимыми типами - очень хочется. В них как-то все очень по-новому. Ну, и GADT придется изучить, за компанию.
Последний аргумент, который я бы хотел привести, это совсем уж воздушный аргумент про "поток." Чем меньше мы отвлекаемся, тем легче удерживать состояние "потока," в котором все удается. Его невозможно поймать при использовании непривычных инструментов, значит, чтобы поймать поток, придется оттренировать применение SYB, например. Но это время я могу потратить на решение задач предметной области, что я, обычно, и делаю. Здесь получается замкнутый круг, который, наверное, надо бы разомкнуть путем увеличения размера типичных проектов, но пока не очень хочется. Уж больно все вокруг интересное. ;)
А дальше посмотрим. ;)
Шел по улице, увидал рекламу Хонды, "Эволюция лидера." Изображена какая-то Хонда, а вокруг нее такие красные, желтые и белые полосы, как обычно бывает на ночных снимках автодорог. С одной стороны, это вызывает ощущение движения, с другой (после некоторого раздумья, однако) понимаешь, что Хонда стоит, а ее обгоняют все, кому не лень. Куда, спрашивается, эволюционировал лидер?
Случилась тут небольшая рубиловка в
Я хочу подробней изложить причины моего скептицизма по отношению к использованию сложных конструкций языков программирования и SYB в том числе.
Для решения задач из предметной области необходимо реализовать ее модель. Очень часто предметная область просто совсем неизвестна или отличается от известной в какую-то неожиданную сторону. "Все легкие проблемы уже решены," так сказать. Поэтому работа программиста обязательно включает в себя работу исследователя, он поднимает такие вопросы, которые эксперты считают, допустим, само собой разумеющимися и в которых и находится корень проблем.
Такие вопросы надо вскрыть быстро, для этого надо быстро разобраться в предметной области. А для этого язык программирования не должен стоять на пути. В нем должна быть возможность адекватного задаче уровня абстракции. И "адекватный" здесь означает "не слишком высокий" тоже. Грешно использовать слишком абстрактные инструменты там, где можно обойтись более специфичными.
Например, для разбора файлов типа SREC монадические комбинаторы будут слишком сложны. А построчное сравнение с образцом - например, ('S':'0':'5':a:b:c:d:nibbles), - в самый раз.
Хаскель предлагает достаточно удобный для большинства задач уровень абстракции - алгебраические типы, сравнение с образцом, классы типов. Забираясь выше, легко попасть в ловушку не решения проблемы предметной области, не достижения цели, а решения проблемы отображения решения проблемы предметной области на фиксированный уровень абстракции и ни ангстремом ниже.
Неинтересно.
Это все равно, как изучать Дим Мак без изучения тактики поединка.
Абстракции, кстати, я люблю, но как-то "большими шагами." То есть, специально изучать тот же SYB или GADT ради улучшения знания Хаскеля я, пожалуй, не буду, а вот разобраться с зависимыми типами - очень хочется. В них как-то все очень по-новому. Ну, и GADT придется изучить, за компанию.
Последний аргумент, который я бы хотел привести, это совсем уж воздушный аргумент про "поток." Чем меньше мы отвлекаемся, тем легче удерживать состояние "потока," в котором все удается. Его невозможно поймать при использовании непривычных инструментов, значит, чтобы поймать поток, придется оттренировать применение SYB, например. Но это время я могу потратить на решение задач предметной области, что я, обычно, и делаю. Здесь получается замкнутый круг, который, наверное, надо бы разомкнуть путем увеличения размера типичных проектов, но пока не очень хочется. Уж больно все вокруг интересное. ;)
А дальше посмотрим. ;)