![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Небольшой ответ на ответы на мои "наезды" на хаскель
Сейчас я опишу одну из главных причин по которым я недолюблюваю Ъ ф.п, и люблю CL.
Понимаете, рассуждая о развитии IT-индустрии, можно провести аналогию с классической промышленностью.
В истории классической промышленности были периоды когда всё делали единично и ручками. Я мог бы сравнить такие периоды с ранним развитием IT. Со временами расцвета UNIX или DOS. С языками вроде Си.
Потом были периоды рабовладельческого строя и раннего капитализма, когда любую задачу закидывали необходимым количеством человеков. Я бы сказал, что сейчас в IT-индустрии как раз такой подобный период, со всеми этими Java и PHP.
Но в итоге, во всех развитых странах промышленность пришла к автоматизации. И производит продукты лучше, быстрее и качественнее, чем когда-либо.
И IT-индустрию ждет когда-нибудь то же самое, то есть массовая автоматизация, программы которые пишут программы(понимаете, к чему я клоню, да?), и это неминуемо.
Я смотрю на языки функционального программирования, вроде хаскеля, как на, ну не знаю, алмазные лопаты. Выглядят красиво, конечно, прочностью обладают неслабой, но что они могут сделать против таких детищ автоматизированной промышленности, как отбойные молотки и экскаваторы?
Я не вижу, как ф.п. может помочь с если уж не уменьшением, то хотя бы со сдерживанием растущей сложности софта. Я вижу ф.п. как модный фетиш, и ничего более, и поэтому время от времени на него наезжаю, т.к. бессмысленные фетиши меня раздражают, т.к. бессмысленные фетиши это может быть круто в дизайне шмоток, например, но не в инженерии.
Кстати, скоро напишу на хабр статью о макросах и метапрограммировании в лиспе, как только продумаю её.
Понимаете, рассуждая о развитии IT-индустрии, можно провести аналогию с классической промышленностью.
В истории классической промышленности были периоды когда всё делали единично и ручками. Я мог бы сравнить такие периоды с ранним развитием IT. Со временами расцвета UNIX или DOS. С языками вроде Си.
Потом были периоды рабовладельческого строя и раннего капитализма, когда любую задачу закидывали необходимым количеством человеков. Я бы сказал, что сейчас в IT-индустрии как раз такой подобный период, со всеми этими Java и PHP.
Но в итоге, во всех развитых странах промышленность пришла к автоматизации. И производит продукты лучше, быстрее и качественнее, чем когда-либо.
И IT-индустрию ждет когда-нибудь то же самое, то есть массовая автоматизация, программы которые пишут программы(понимаете, к чему я клоню, да?), и это неминуемо.
Я смотрю на языки функционального программирования, вроде хаскеля, как на, ну не знаю, алмазные лопаты. Выглядят красиво, конечно, прочностью обладают неслабой, но что они могут сделать против таких детищ автоматизированной промышленности, как отбойные молотки и экскаваторы?
Я не вижу, как ф.п. может помочь с если уж не уменьшением, то хотя бы со сдерживанием растущей сложности софта. Я вижу ф.п. как модный фетиш, и ничего более, и поэтому время от времени на него наезжаю, т.к. бессмысленные фетиши меня раздражают, т.к. бессмысленные фетиши это может быть круто в дизайне шмоток, например, но не в инженерии.
Кстати, скоро напишу на хабр статью о макросах и метапрограммировании в лиспе, как только продумаю её.
no subject
>Как стек. Один на другом. Нижний о верхнем ничего не знает.
О!
А параллельной композиции быть не может? Типа, "вот здесь играем, а здесь рыбу заворачиваем". Клиент-сервер, такого рода. Нельзя такого сделать?
>Задача должна быть описана на самом верхнем уровне, самым высокоуровневым DSL, непосредственно описывающим саму задачу в ее терминах. Этот DSL должен компилироваться в нижележащий DSL, работающий, например, с абстракциями доступных программных средств, и так далее. И вот когда мы изменяем спецификацию задачи, на верхнем уровне, изменения автоматически распространяются на нижележащие слои, без непосредственной работы с ними. Верификация происходит на всех уровнях слоях DSL, естественно. Если DSL не принимает какую-либо "форму", он кричит нам об ошибке, при компиляции.
Ну, представьте себе, что у вас изменилась спецификация входов и выходов одной из компонент, но общая структура (спецификация верхнего уровня, просто налаживающая отношения между компонентами) осталась прежней. Кто и где у вас будет ругаться?
>Это не может полностью защитить от ошибок в логике, но в отличие от типизации, это уменьшит шанс возникновения логических ошибок, за счет сужения сущностей, с которыми мы работаем, за счет максимальной специализации кода под задачу.
А.
С GADT (generalized algebraic data types) вы знакомы? Как с их помощью построить типобезопасный интерпретатор знаете?
Доступно ли у вас аналог type erasure? Гарантирован ли он? Можете ли вы привести пример гарантии непустого списка на входе в функцию head?
no subject
(Anonymous) 2011-11-03 02:01 am (UTC)(link)Что значит "типобезопасный"? Как эта "типобезопасность" сможет гарантировать, что интерпретатор работает корректно и без ошибок (ведь в итоге нам нужно именно это, все остальное - лишь средства достижения указанной цели)? Нельзя ли достигнуть такого же результата без этой вашей "типобезопасности"?
> Можете ли вы привести пример гарантии непустого списка на входе в функцию head?
Неразрешимость подобной задачи вас, конечно же, не волнует? Или вас устроит чекер, который может отвергать корректные варианты использования?