Ты демагогизируешь. Стандарт схемы гораздо меньше, а это тоже лисп. Описание синтаксиса лиспа занимает страницу, а у хаскеля постоянно "а вот есть специальные функции типа +, которые безо всяких амперсандов можно юзать как ". Плюс в стандарт лиспа входит стандартная библиотека, очень очень и очень толстая.
То, что лисп проще, показывается простым фактом, о котором я уже упоминал - я (и не только я) начал что-то писать на лиспе после 20 минут. На Хаскеле такого не получается.
Зачем ты наезжаешь на такой прекрасный инженерный язык, как лисп, я не понимаю :)
С другой стороны, когда мне надо было поправить баги в хаскельной программе, я это сделал довольно быстро. Но для правки багов зачастую не нужно особо разбираться.
Если в итоге должно получиться что-то рабочее, то надо разобраться не только с синтаксисом/семантикой, но и с best practicies, философией вообще, тенденциями, особыми/крайними местами и так далее. Чтобы, например, после полугода разработки не обнаружить, что требования по performance при выбранной архитектуре удовлетворить не выйдет, ибо язык такой (ну или подставь любой другой пример, когда незнание матчасти приводит к локальному фэйлу).
А багфикс - это багфикс. Архитектуру уже выбрали и закодили, структуры данных тоже не поменяешь и так далее и тому подобное. Нужно просто понять код, а затем пофиксить. Соответственно, открываешь код, и разбираешься только с тем, что непонятно (а очень многое интуитивно понятно, ибо ты же знаешь, что оно как-то работает и что-то делает).
btw, судя по моему опыту, в плане "пофиксить код на неизвестном тебе языке" больше всего рулит питон. Самый понятный язык для чтения из всех, что я видел.
>Если в итоге должно получиться что-то рабочее, то надо разобраться не только с синтаксисом/семантикой, но и с best practicies, философией вообще, тенденциями, особыми/крайними местами и так далее.
У тебя произошёл неверный переход, если уж на то пошло. В одном месте (про Лисп) ты говоришь, что за 20 минут начал что-то писать, в другом месте ты говоришь, что чтобы что-то писать, надо изучить лучшие подходы и тп и что надо разбираться. Это другое место очень интересно "Роман: я поправил баг в хаскельной программе, но это просто, особо разбираться не надо. Я: так и чтобы начать что-то писать тоже особо разбираться не надо. Роман: э, нет, разбираться надо."
>На хаскеле за 20 минут я таки начать не могу писать, ибо я за 20 минут не могу выучить синтаксис в мере, достаточной для понимания примеров и чужого кода.
Повторяю - чтобы пофиксить баг, не надо придумывать дизайн. Он уже придуман, просто делай так же, как уже написано. Если пишешь сам, то дизайнить будешь сам. А дизайнить сложнее, чем просто код писать.
Насчёт "позволь не поверить" - а зачем мне врать-то? :) Я реально не могу читать код на хаскеле, потому что не могу запомнить его синтаксис. Нет, я наверняка СПОСОБЕН выучить синтаксис, но тем не менее имею право считать его сложным, если уж ПО ФАКТУ я его не могу выучить за пару часов.
>Повторяю - чтобы пофиксить баг, не надо придумывать дизайн. Он уже придуман, просто делай так же, как уже написано. Если пишешь сам, то дизайнить будешь сам. А дизайнить сложнее, чем просто код писать.
Типы позволяют быстро менять дизайн. Поэтому можно писать быстро, а потом переделать, как правильно, не сделав больших ошибок.
Я теперь этим даже на Си пользуюсь.
>Насчёт "позволь не поверить" - а зачем мне врать-то? :)
Для красного словца, например. Или чтобы остаться при своём мнении.
>Я реально не могу читать код на хаскеле, потому что не могу запомнить его синтаксис. Нет, я наверняка СПОСОБЕН выучить синтаксис, но тем не менее имею право считать его сложным, если уж ПО ФАКТУ я его не могу выучить за пару часов.
Тогда, как я понимаю, ты имеешь право высказываться в стиле "я считаю синтаксис Хаскеля сложным", а не "синтаксис Хаскеля сложен". Хотя бы "синтаксис Хаскеля сложен для меня".
По-моему я имею право говорить, что "штанга в 200 кг - тяжёлая". То, что для тебя она не тяжёлая, не делает её лёгкой. По хаскелю всё ровно то же самое.
А теперь про дизайн. Вот есть у меня задача. Я её декомпозировал, получил три структуры данных со связями один-к-одному и пять функций для работы со структурами (функции реализуют некую валидацию данных плюс некую BL, например, в одной из структур записаны права на изменение других структур). Написал всё. И тут оказалось, что удобнее будет пять структур со связями один-ко-многим и многие-ко-многим, ну и действий над ними поменьше (update делается как каскад remove, add), то есть функций теперь надо всего четыре.
>И тут оказалось, что удобнее будет пять структур со связями один-ко-многим и многие-ко-многим, ну и действий над ними поменьше (update делается как каскад remove, add), то есть функций теперь надо всего четыре. >Как мне помогают типы в этом случае?
Как минимум, меньше писать тестов. Не забудешь, где надо заменить update на remove+add.
Однако, ты описываешь вырожденный случай.
Подсистема, дизайн которой ты поменял, взаимодействует с другими системами, в которых тебе надо поменять по минимуму. Вот здесь тебе типы помогут в полной мере. Они протаскивают требования по программе.
То, что лисп проще, показывается простым фактом, о котором я уже упоминал - я (и не только я) начал что-то писать на лиспе после 20 минут. На Хаскеле такого не получается.
Зачем ты наезжаешь на такой прекрасный инженерный язык, как лисп, я не понимаю :)
Reply
Reply
Reply
Если в итоге должно получиться что-то рабочее, то надо разобраться не только с синтаксисом/семантикой, но и с best practicies, философией вообще, тенденциями, особыми/крайними местами и так далее. Чтобы, например, после полугода разработки не обнаружить, что требования по performance при выбранной архитектуре удовлетворить не выйдет, ибо язык такой (ну или подставь любой другой пример, когда незнание матчасти приводит к локальному фэйлу).
А багфикс - это багфикс. Архитектуру уже выбрали и закодили, структуры данных тоже не поменяешь и так далее и тому подобное. Нужно просто понять код, а затем пофиксить. Соответственно, открываешь код, и разбираешься только с тем, что непонятно (а очень многое интуитивно понятно, ибо ты же знаешь, что оно как-то работает и что-то делает).
btw, судя по моему опыту, в плане "пофиксить код на неизвестном тебе языке" больше всего рулит питон. Самый понятный язык для чтения из всех, что я видел.
Reply
Какого лешего!
Слушай, за те 20 минут, что ты "начал писать хоть что-то", ты что, со всем этим разобрался?
Reply
Reply
У тебя произошёл неверный переход, если уж на то пошло. В одном месте (про Лисп) ты говоришь, что за 20 минут начал что-то писать, в другом месте ты говоришь, что чтобы что-то писать, надо изучить лучшие подходы и тп и что надо разбираться. Это другое место очень интересно "Роман: я поправил баг в хаскельной программе, но это просто, особо разбираться не надо. Я: так и чтобы начать что-то писать тоже особо разбираться не надо. Роман: э, нет, разбираться надо."
>На хаскеле за 20 минут я таки начать не могу писать, ибо я за 20 минут не могу выучить синтаксис в мере, достаточной для понимания примеров и чужого кода.
Позволь мне не поверить. Ну не может этого быть.
Reply
Насчёт "позволь не поверить" - а зачем мне врать-то? :)
Я реально не могу читать код на хаскеле, потому что не могу запомнить его синтаксис. Нет, я наверняка СПОСОБЕН выучить синтаксис, но тем не менее имею право считать его сложным, если уж ПО ФАКТУ я его не могу выучить за пару часов.
PS: я Руслан ;)
Reply
Типы позволяют быстро менять дизайн. Поэтому можно писать быстро, а потом переделать, как правильно, не сделав больших ошибок.
Я теперь этим даже на Си пользуюсь.
>Насчёт "позволь не поверить" - а зачем мне врать-то? :)
Для красного словца, например. Или чтобы остаться при своём мнении.
>Я реально не могу читать код на хаскеле, потому что не могу запомнить его синтаксис. Нет, я наверняка СПОСОБЕН выучить синтаксис, но тем не менее имею право считать его сложным, если уж ПО ФАКТУ я его не могу выучить за пару часов.
Тогда, как я понимаю, ты имеешь право высказываться в стиле "я считаю синтаксис Хаскеля сложным", а не "синтаксис Хаскеля сложен". Хотя бы "синтаксис Хаскеля сложен для меня".
>PS: я Руслан ;)
Прошу прощения, я поторопился.
Reply
По-моему я имею право говорить, что "штанга в 200 кг - тяжёлая". То, что для тебя она не тяжёлая, не делает её лёгкой. По хаскелю всё ровно то же самое.
А теперь про дизайн. Вот есть у меня задача. Я её декомпозировал, получил три структуры данных со связями один-к-одному и пять функций для работы со структурами (функции реализуют некую валидацию данных плюс некую BL, например, в одной из структур записаны права на изменение других структур). Написал всё. И тут оказалось, что удобнее будет пять структур со связями один-ко-многим и многие-ко-многим, ну и действий над ними поменьше (update делается как каскад remove, add), то есть функций теперь надо всего четыре.
Как мне помогают типы в этом случае?
Reply
>Как мне помогают типы в этом случае?
Как минимум, меньше писать тестов. Не забудешь, где надо заменить update на remove+add.
Однако, ты описываешь вырожденный случай.
Подсистема, дизайн которой ты поменял, взаимодействует с другими системами, в которых тебе надо поменять по минимуму. Вот здесь тебе типы помогут в полной мере. Они протаскивают требования по программе.
Reply
Это если у меня дизайн такой, что оно так :) Ну хотя на таком уровне в принципе пофигу на технологию, да.
Reply
Reply
Reply
Reply
Reply
Leave a comment