![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
fprog 5
Вышел пятый номер журнала Практика функционального программирования.
Я пока прочел только начало, про конкурс. Особо мне понравилось про полярные мнения экспертов, потому что это подтверждает мои идеи насчет полного отсутствия мейнстрима в программировании и насчет того, что работа "очень хороших" программистов плохо совместима с промышленной разработкой софта.
Т.е. мейнстрим и промышленная разработка существуют. Но существуют они исключительно в случае работы большими командами с низкой эффективностью и с минимальными инновациями, т.е. садят, условно говоря "один студент-одна неделя-один объект предметной области", а потом за ним тестеры ошибки ищут.
А теперь представьте, что всех их заменить на одного computer-science гуру с кодогенератором. Ошибок, которые делают студенты, гарантированно не будет, а те, которые будут - находятся гораздо раньше. Но результат работы плохо предсказуем, потому что кодогенераторы, по моему опыту, очень хреново обобщаются и поэтому их нужно делать под каждый класс задач и внутри конторы, для себя. При попытке их обобщения они (да и вообще все заумное, типа DSL и прочего) резко становятся настолько же неудобными в работе, как и обычные языки, только еще в гамаке и стоя.
И получается, что мы имеем вместо 10000 студентов, которые в лоб пишут одно и тоже на одних и тех же инструментов, 100 гурей, которые каждый "любовно полирует" кто хаскель, кто лисп, кто окамл, кто F# и среди которых нет никакого согласия.
И сроки работы этих гуру, хоть и в среднем сильно меньше, чем у студентов, но очень херово предсказуемые. Потому что одна удачно прочитанная книга или примененная идея может потребовать выкинуть всю работу за предыдущий срок, но сократит будущий срок в два раза.
Я пока прочел только начало, про конкурс. Особо мне понравилось про полярные мнения экспертов, потому что это подтверждает мои идеи насчет полного отсутствия мейнстрима в программировании и насчет того, что работа "очень хороших" программистов плохо совместима с промышленной разработкой софта.
Т.е. мейнстрим и промышленная разработка существуют. Но существуют они исключительно в случае работы большими командами с низкой эффективностью и с минимальными инновациями, т.е. садят, условно говоря "один студент-одна неделя-один объект предметной области", а потом за ним тестеры ошибки ищут.
А теперь представьте, что всех их заменить на одного computer-science гуру с кодогенератором. Ошибок, которые делают студенты, гарантированно не будет, а те, которые будут - находятся гораздо раньше. Но результат работы плохо предсказуем, потому что кодогенераторы, по моему опыту, очень хреново обобщаются и поэтому их нужно делать под каждый класс задач и внутри конторы, для себя. При попытке их обобщения они (да и вообще все заумное, типа DSL и прочего) резко становятся настолько же неудобными в работе, как и обычные языки, только еще в гамаке и стоя.
И получается, что мы имеем вместо 10000 студентов, которые в лоб пишут одно и тоже на одних и тех же инструментов, 100 гурей, которые каждый "любовно полирует" кто хаскель, кто лисп, кто окамл, кто F# и среди которых нет никакого согласия.
И сроки работы этих гуру, хоть и в среднем сильно меньше, чем у студентов, но очень херово предсказуемые. Потому что одна удачно прочитанная книга или примененная идея может потребовать выкинуть всю работу за предыдущий срок, но сократит будущий срок в два раза.
no subject
вчера заказчику отослал код на AWK, по CSV описанию генерирующий Си-ный хидер с данными. Срок разработки с обвязками - 4 дня. По этим данным можно даже кустарный reflection и OOP устраивать с ликующими шлюхами.
Это уже второй мой подобный проект за 5 лет, и что характерно - в обоих случаях сроки выполнения и отдачи результата - неделя или менее.
no subject
Fixed.
no subject
в этой версии нет динамического выделения памяти. Вообще.
Мемори-ликующие могут отдыхать.