Если в итоге должно получиться что-то рабочее, то надо разобраться не только с синтаксисом/семантикой, но и с best practicies, философией вообще, тенденциями, особыми/крайними местами и так далее. Чтобы, например, после полугода разработки не обнаружить, что требования по performance при выбранной архитектуре удовлетворить не выйдет, ибо язык такой (ну или подставь любой другой пример, когда незнание матчасти приводит к локальному фэйлу).
А багфикс - это багфикс. Архитектуру уже выбрали и закодили, структуры данных тоже не поменяешь и так далее и тому подобное. Нужно просто понять код, а затем пофиксить. Соответственно, открываешь код, и разбираешься только с тем, что непонятно (а очень многое интуитивно понятно, ибо ты же знаешь, что оно как-то работает и что-то делает).
btw, судя по моему опыту, в плане "пофиксить код на неизвестном тебе языке" больше всего рулит питон. Самый понятный язык для чтения из всех, что я видел.
>Если в итоге должно получиться что-то рабочее, то надо разобраться не только с синтаксисом/семантикой, но и с best practicies, философией вообще, тенденциями, особыми/крайними местами и так далее.
У тебя произошёл неверный переход, если уж на то пошло. В одном месте (про Лисп) ты говоришь, что за 20 минут начал что-то писать, в другом месте ты говоришь, что чтобы что-то писать, надо изучить лучшие подходы и тп и что надо разбираться. Это другое место очень интересно "Роман: я поправил баг в хаскельной программе, но это просто, особо разбираться не надо. Я: так и чтобы начать что-то писать тоже особо разбираться не надо. Роман: э, нет, разбираться надо."
>На хаскеле за 20 минут я таки начать не могу писать, ибо я за 20 минут не могу выучить синтаксис в мере, достаточной для понимания примеров и чужого кода.
Повторяю - чтобы пофиксить баг, не надо придумывать дизайн. Он уже придуман, просто делай так же, как уже написано. Если пишешь сам, то дизайнить будешь сам. А дизайнить сложнее, чем просто код писать.
Насчёт "позволь не поверить" - а зачем мне врать-то? :) Я реально не могу читать код на хаскеле, потому что не могу запомнить его синтаксис. Нет, я наверняка СПОСОБЕН выучить синтаксис, но тем не менее имею право считать его сложным, если уж ПО ФАКТУ я его не могу выучить за пару часов.
>Повторяю - чтобы пофиксить баг, не надо придумывать дизайн. Он уже придуман, просто делай так же, как уже написано. Если пишешь сам, то дизайнить будешь сам. А дизайнить сложнее, чем просто код писать.
Типы позволяют быстро менять дизайн. Поэтому можно писать быстро, а потом переделать, как правильно, не сделав больших ошибок.
Я теперь этим даже на Си пользуюсь.
>Насчёт "позволь не поверить" - а зачем мне врать-то? :)
Для красного словца, например. Или чтобы остаться при своём мнении.
>Я реально не могу читать код на хаскеле, потому что не могу запомнить его синтаксис. Нет, я наверняка СПОСОБЕН выучить синтаксис, но тем не менее имею право считать его сложным, если уж ПО ФАКТУ я его не могу выучить за пару часов.
Тогда, как я понимаю, ты имеешь право высказываться в стиле "я считаю синтаксис Хаскеля сложным", а не "синтаксис Хаскеля сложен". Хотя бы "синтаксис Хаскеля сложен для меня".
По-моему я имею право говорить, что "штанга в 200 кг - тяжёлая". То, что для тебя она не тяжёлая, не делает её лёгкой. По хаскелю всё ровно то же самое.
А теперь про дизайн. Вот есть у меня задача. Я её декомпозировал, получил три структуры данных со связями один-к-одному и пять функций для работы со структурами (функции реализуют некую валидацию данных плюс некую BL, например, в одной из структур записаны права на изменение других структур). Написал всё. И тут оказалось, что удобнее будет пять структур со связями один-ко-многим и многие-ко-многим, ну и действий над ними поменьше (update делается как каскад remove, add), то есть функций теперь надо всего четыре.
>И тут оказалось, что удобнее будет пять структур со связями один-ко-многим и многие-ко-многим, ну и действий над ними поменьше (update делается как каскад remove, add), то есть функций теперь надо всего четыре. >Как мне помогают типы в этом случае?
Как минимум, меньше писать тестов. Не забудешь, где надо заменить update на remove+add.
Однако, ты описываешь вырожденный случай.
Подсистема, дизайн которой ты поменял, взаимодействует с другими системами, в которых тебе надо поменять по минимуму. Вот здесь тебе типы помогут в полной мере. Они протаскивают требования по программе.
>Про инженерные языки. Ты предлагаешь хаскель в качестве такового? Он не годится.
Почему?
>Вообще, я имел в виду вот это: a + b, но при этом div a b, но можно и a `div` b, ну и + a b тоже можно (но я уже забыл как так сделать) - ну что это такое? Где консистентность?
(+) a b, а также (a +) b и (+ b) a. Это всё удобные сокращения, чтобы не плодить безымянные функции, где можно без них обойтись.
>То, что в лиспе (common lisp) есть спецформы - это просто нюанс. Любому человеку можно сказать, что на первом месте в sexp-е находится имя функции, а остальное - это аргументы. Остальные детали не мешают понимать код.
Ох ты. И вдруг получается, что не всякую функцию можно передать аргументом. zipWith3 if conditions trues falses не работает. Действительно, нюанс.
>Про амперсанды - Сергей, ну вы что же меня в выходной заставляете искать всякое, да ещё и во флудерском споре? :) Имейте совесть.
(The comment has been removed)
Если в итоге должно получиться что-то рабочее, то надо разобраться не только с синтаксисом/семантикой, но и с 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
Reply
Почему?
>Вообще, я имел в виду вот это: a + b, но при этом div a b, но можно и a `div` b, ну и + a b тоже можно (но я уже забыл как так сделать) - ну что это такое? Где консистентность?
(+) a b, а также (a +) b и (+ b) a. Это всё удобные сокращения, чтобы не плодить безымянные функции, где можно без них обойтись.
>То, что в лиспе (common lisp) есть спецформы - это просто нюанс. Любому человеку можно сказать, что на первом месте в sexp-е находится имя функции, а остальное - это аргументы. Остальные детали не мешают понимать код.
Ох ты. И вдруг получается, что не всякую функцию можно передать аргументом. zipWith3 if conditions trues falses не работает. Действительно, нюанс.
>Про амперсанды - Сергей, ну вы что же меня в выходной заставляете искать всякое, да ещё и во флудерском споре? :) Имейте совесть.
А когда ещё? Сейчас самое время.
Reply
Leave a comment