Ну вот, хотел посмотреть о не-довоенных методах тренировок, а теперь и единственный упомянутый источник оказался не таким уж и надежным. Может вы посоветуете что?
Проблема безопасной навигации (или композиции функций) в том, что есть некое супер-значение, которое населяет все типы и ведет себя отлично от других граждан этого типа отказываясь отвечать на ожидаемые сообщения (если вы не в Objective-C или SmallTalk, где nil принимает любое сообщение и возвращает себя же). Поговаривают, что индустрия разработки программного обеспечения из-за этого потеряла как минимум миллиард долларов.
Наряду с тем, что добавили в Ruby, иной популярный способ избавиться от злополучного гражданина — явно указывать, что значение может отсутствовать. Обычно такой тип называет Option, или Maybe. На мой взгляд, это решение лучше потому, что программист точно знает, что в этом месте может ничего не быть и остаток цепочки не выполнится. К сожалению, добавить Option в язык ретроспективно не очень просто, а в язык с динамической типизацией вообще не представляется возможным.
Недостаток второго метода в том, что теперь возвращаемое значение предыдущей функции не совпадает с принимаемым значением (или self в OO языках) последующей и их нельзя просто так взять и связать точкой. Но эта проблема решена с помощью композиции в некой категории Клейсли, при чем, она предлагает более общее решение, которое помогает не только при вероятном отсутствии значения, но и в других ситуациях. Например, неопределенности, которая часто встречается при parsing'е того же программного кода. Интересная концепция, кстати, рекомендую почитать на досуге.
Мне кажется, это не стоит упоминания. Они стремятся быть суперсетом ES6, а это часть стандарта. Кстати, подробнее список изменений 1.5 можно посмотреть в roadmap, а все, что уже поддерживается в Kangax ES6.
Нет, я так не считаю. Есть разные классы ошибок. Переполнение stack'a — отдельный класс, который, есть и в динамических языках. Он вообще никак не связан с типизацией. Так же, как не связаны с типизацией утечки памяти. Я считаю, что статическая типизация позволяет отсеять все ошибки типизации, особенно если в вашем языке нет ошибки на миллиард долларов.
Проблема с тестами в том, что невозможно проверить все возможные варианты входных данных.
Хорошо, давайте разберем.
1. Устранить ошибку на ранних этапах разработки дешевле, согласны? Чтобы починить в production'e нужно исправить, пройти code review, тесты, и задеплоить (возможно у вас есть еще этапы). А чтобы исправить падающую программу нужен только первый этап.
2. Ошибка исправленная на раннем этапе не вредит пользователям.
3. Все люди ошибаются. Компиляторы внимательны. Статическая типизация позволяет избежать этого класса ошибок раз и насовсем. Я согласен, что это проблема людей, но, мне кажется, лучше использовать компилятор, чем вживлять себе ген слона, чтобы все помнить.
Я думаю, автор имел ввиду, что у него не получается держать в памяти (которая в голове) всю необходимую информацию, чтобы хорошо писать на динамически типизированных языках.
Научите? Правда, очень хочется. Я на работе пишу на Ruby, и сильно страдаю от динамической типизации. Немного помогают аннотации, хорошо помогают тесты, но все равно случаются ошибки в production'е. Автор, кстати, тоже не умеет.
… динамическая типизация мне не интересна. Это все для людей с большим модулем памяти в башке.
Еще вы никогда не получите такого количества ошибок типизации. Проекты среднего и больше размера лучше писать на статически типизированных языках, иначе рефакторинг превращается в ад и Израиль.
Я не говорю, что проблема с скобках. Я сам согласился, что к C такой же вопрос.
Конечно, можно написать макрос. Но как говорят, «in Rome, do as Romans do», «со своим уставом в чужой монастырь не ходят». Это как в каком-то Ruby возвращать два значения, где второе — ошибка, как принято в Go.
Все пишут справа налево, так здесь принято. Но удобно ли читать такой код?
Наряду с тем, что добавили в Ruby, иной популярный способ избавиться от злополучного гражданина — явно указывать, что значение может отсутствовать. Обычно такой тип называет Option, или Maybe. На мой взгляд, это решение лучше потому, что программист точно знает, что в этом месте может ничего не быть и остаток цепочки не выполнится. К сожалению, добавить Option в язык ретроспективно не очень просто, а в язык с динамической типизацией вообще не представляется возможным.
Недостаток второго метода в том, что теперь возвращаемое значение предыдущей функции не совпадает с принимаемым значением (или self в OO языках) последующей и их нельзя просто так взять и связать точкой. Но эта проблема решена с помощью композиции в некой категории Клейсли, при чем, она предлагает более общее решение, которое помогает не только при вероятном отсутствии значения, но и в других ситуациях. Например, неопределенности, которая часто встречается при parsing'е того же программного кода. Интересная концепция, кстати, рекомендую почитать на досуге.
То, что раньше нужно было писать так:
теперь можно так:
github.com/rails/rails/issues/4565
github.com/rails/rails/issues/19891
Homebrew
github.com/Homebrew/homebrew/issues/7940
Angular
github.com/angular/angular.js/issues/11330
React
github.com/facebook/react/issues/2828
Похоже, я в хорошей компании новичков.
Проблема с тестами в том, что невозможно проверить все возможные варианты входных данных.
1. Устранить ошибку на ранних этапах разработки дешевле, согласны? Чтобы починить в production'e нужно исправить, пройти code review, тесты, и задеплоить (возможно у вас есть еще этапы). А чтобы исправить падающую программу нужен только первый этап.
2. Ошибка исправленная на раннем этапе не вредит пользователям.
3. Все люди ошибаются. Компиляторы внимательны. Статическая типизация позволяет избежать этого класса ошибок раз и насовсем. Я согласен, что это проблема людей, но, мне кажется, лучше использовать компилятор, чем вживлять себе ген слона, чтобы все помнить.
Я думаю, автор имел ввиду, что у него не получается держать в памяти (которая в голове) всю необходимую информацию, чтобы хорошо писать на динамически типизированных языках.
Fork: github.com/goldfirere/ghc/tree/nokinds
Wiki: ghc.haskell.org/trac/ghc/wiki/DependentHaskell
Конечно, можно написать макрос. Но как говорят, «in Rome, do as Romans do», «со своим уставом в чужой монастырь не ходят». Это как в каком-то Ruby возвращать два значения, где второе — ошибка, как принято в Go.
Все пишут справа налево, так здесь принято. Но удобно ли читать такой код?
Здесь точно так же как в LISP'e, только последний аргумент, а не первый, считается функцией.
В Scala очень даже используют функции без точек
Anyways, вопрос в том, удобно ли читать справа налево.