Прямо уж взорвал примерами. Три раза написал function g(). Взгляд на типы с позиции менеджера, как на средство QA, это правильно, но чую, что неполно. Как минимум, в типы удается вынести генерацию обобщённого кода, т.е. уменьшить писанину и повысить выразительность. А "мягкая типизация" - это расхожий термин или свежевведённый? Имхо, любой язык с возможностями стирания типа, вплоть до тупо реинтерпреткаста к void*, сюда попадает. Или кое-кто что-то недоговорил и недовзорвал...
Так как я и инженер и менеджер, мне трудно разделять это "позиции". И я не вижу в этом исскуственном и надуманном "разделении" (и на мой взгляд глупой попытке их противопоставления) никакого практического смысла. Это две половинки знания об одном и том же, весь вопрос в том, обладаешь ли ты ими. Или хотя бы даже одной из них. Отсуствие обоих из них ничуть не мешает людям об этом руссуждать.
Кстати, а кто сказал, что тип оператора деления - (any,any):number? Если он перегружен, там вполне может быть (number,number):number|(MySuperFoo,xz):MyDuperBar|(any,any):number=NaN. Т.е., иногда на выходе будет не число и даже не боттом, поэтому придётся обобщить результат до всё того же any. Либо транслятор должен оттрассировать все вхождения функции g()...
Особенности интерпретации оператора деления определяет конкретная ситема типов. Как она скажет - так и будет. В ней, например, может не быть никакого NaN, которое number. В ней могут быть, или не быть перегруженные операции.
Я намеренно упростил. Этот пример - это простейшая иллюстрация некой концепции, которая объясняется. Текст расчитан на человека, который не знает ничего, кроме JavaScript. И аппелирует к нему.
Я думаю, это вполне понятно, не? Концепция понятна? Или у нас проблемы с пониманием примеров?
С местными правилами бана, кстати, ты знаком, дружище? :) Оно называется "о модерировании и мудаках". Крайне рекомендую. Куда более строгое, чем на РСДН :)
Нет то, чтобы я намекал на что-то. Не пойми меня неправильно. Я уверен, что не смотря на некоторые смутные сигналы (это о моих догадках касательно твоего мотива оставлять здесь комментарии), ты сможешь держать себя в руках :)
А тип function const(a, b) { return a; } выведет как any, any -> any? А тип function app(f, x) { return f(x); }?
По поводу g, я не понял, почему именно вывело any: 1. Так как в JS можно любой объект делить на 10 (если не число), и получится NaN, и именно поэтому вывело any 2. В JS в любую функцию можно всегда передать что угодно, поэтому и any
А что понимается под "война окончена"? Если то, что адепты статики скажут, что это очень хороший компромисс, то сомнительно, ибо им dep types подавай.
Да. Выводит как все any. Не смотря на то, что могло бы предположить что f - это function.
Ибо не хочет ломать семантику JS (их установка - корректная JS программа должна скомпилироваться). ТО есть, для более строгой типизации надо намекнуть явной аннотацией.
Это я и имею в виду, когда говорю, что TS - динамический язык. А ведь с опциональными аннотациями типов и выводом типов это и правда хрен разберешь, не так ли?
> А что понимается под "война окончена"? Если то, что адепты статики скажут, что это очень хороший компромисс, то сомнительно, ибо им dep types подавай.
Ну, имеется более примитивный холивор, чем зависимые типы. Такой, совсем брутальный. Вроде "типы - говно!". Примерно треть детей выросших на динамическиз языках так реагирует. Оно есть. Я видел в конфах. Статья написана по мотивам флейма в Israel JavaScript, который меня совершенно изумил.
> 1. Так как в JS можно любой объект делить на 10 (если не число), и получится NaN, и именно поэтому вывело any
Разные системы типов могут делать разные предположения. Мы легко можем навесить на JS более строгую систему типов, например. Которая запрещает NaN. И это будет по своему логично - как правило появление статически выводящегося NaN ничем хорошим не грозит, это явная ошибка.
Но это выбор разработчиков TypeScript. Они сделали такую систему типов, которая трактует этот NaN как норму, так что у нас выводится any. Она динамеческая.
Собственно, я про то, что всякие "статическое vs. динамическое" совершенно бессмысленны, если в качестве статического привлекается убогая система типов.
Они совершенно бессмысленны без всяких "если" :). Потому, что есть такие вещи, как Gradual Typing, стирающие эти границы. Убогость или не убогость системы типов (что, кстати, оценочное суждение - оно не несет технической информации) этому совершенно перпендикулярна.
Генная инженерия, скрестили ужа с ежом и удивляются, почему оно не взлетает. Лучше бы в F# так вкладывались.
По существу хорошей статьи можно сказать, что пока вы не можете доказать математически полного покрытия тестами, любое маленькое движение в сторону строгой типизации будет полезно для качества, в ущерб скорости наброса. Typescript и есть такое аккуратное движение в эту сторону.
TypeScript уже взлетел, и ради интереса просто стоит посмотреть какие библиотеки на нем написаны.
А не могли бы вы пояснить что значит математически полное покрытие тестами, и какой цели оно служит? Потому что если оно только гарантирует корректность использования всех типов, то это бессмысленно, потому что программа может быть некорректной, но все типы совпадают.
То, что это приятнее и качественнее, мне кажется очевидно. Критика была в том, что поскольку люди исходили "из возможного", то и получилось "то, что возможно". Поэтому и приходится "объяснять себя" вот в таких статьях.
Как говорил Дейкстра, отладка программы - это сведение количества ошибок к приемлемому минимуму. Так и живём:)
Comments 30
Взгляд на типы с позиции менеджера, как на средство QA, это правильно, но чую, что неполно. Как минимум, в типы удается вынести генерацию обобщённого кода, т.е. уменьшить писанину и повысить выразительность.
А "мягкая типизация" - это расхожий термин или свежевведённый?
Имхо, любой язык с возможностями стирания типа, вплоть до тупо реинтерпреткаста к void*, сюда попадает. Или кое-кто что-то недоговорил и недовзорвал...
Reply
О. Это очень cтарый термин. Сейчас совсем не в моде. Даже статьи в википедии нет. Погуглите.
Reply
Конечно же нет.
Reply
Так как я и инженер и менеджер, мне трудно разделять это "позиции". И я не вижу в этом исскуственном и надуманном "разделении" (и на мой взгляд глупой попытке их противопоставления) никакого практического смысла. Это две половинки знания об одном и том же, весь вопрос в том, обладаешь ли ты ими. Или хотя бы даже одной из них. Отсуствие обоих из них ничуть не мешает людям об этом руссуждать.
Ты считаешь, что-то "неполно"? Дополни.
Reply
Если он перегружен, там вполне может быть (number,number):number|(MySuperFoo,xz):MyDuperBar|(any,any):number=NaN.
Т.е., иногда на выходе будет не число и даже не боттом, поэтому придётся обобщить результат до всё того же any.
Либо транслятор должен оттрассировать все вхождения функции g()...
Reply
Я намеренно упростил. Этот пример - это простейшая иллюстрация некой концепции, которая объясняется. Текст расчитан на человека, который не знает ничего, кроме JavaScript. И аппелирует к нему.
Я думаю, это вполне понятно, не? Концепция понятна? Или у нас проблемы с пониманием примеров?
Reply
Нет то, чтобы я намекал на что-то. Не пойми меня неправильно. Я уверен, что не смотря на некоторые смутные сигналы (это о моих догадках касательно твоего мотива оставлять здесь комментарии), ты сможешь держать себя в руках :)
http://gaperton.livejournal.com/62888.html
Reply
А тип function app(f, x) { return f(x); }?
По поводу g, я не понял, почему именно вывело any:
1. Так как в JS можно любой объект делить на 10 (если не число), и получится NaN, и именно поэтому вывело any
2. В JS в любую функцию можно всегда передать что угодно, поэтому и any
А что понимается под "война окончена"? Если то, что адепты статики скажут, что это очень хороший компромисс, то сомнительно, ибо им dep types подавай.
Reply
Да. Так и выводит. Вот здесь можно посмотреть. https://www.typescriptlang.org/play/
> А тип function app(f, x) { return f(x); }?
Да. Выводит как все any. Не смотря на то, что могло бы предположить что f - это function.
Ибо не хочет ломать семантику JS (их установка - корректная JS программа должна скомпилироваться). ТО есть, для более строгой типизации надо намекнуть явной аннотацией.
Это я и имею в виду, когда говорю, что TS - динамический язык. А ведь с опциональными аннотациями типов и выводом типов это и правда хрен разберешь, не так ли?
Reply
Ну, имеется более примитивный холивор, чем зависимые типы. Такой, совсем брутальный. Вроде "типы - говно!". Примерно треть детей выросших на динамическиз языках так реагирует. Оно есть. Я видел в конфах. Статья написана по мотивам флейма в Israel JavaScript, который меня совершенно изумил.
Reply
Разные системы типов могут делать разные предположения. Мы легко можем навесить на JS более строгую систему типов, например. Которая запрещает NaN. И это будет по своему логично - как правило появление статически выводящегося NaN ничем хорошим не грозит, это явная ошибка.
Но это выбор разработчиков TypeScript. Они сделали такую систему типов, которая трактует этот NaN как норму, так что у нас выводится any. Она динамеческая.
Reply
Ладно бы PureScript...
Reply
Reply
Reply
Reply
По существу хорошей статьи можно сказать, что пока вы не можете доказать математически полного покрытия тестами, любое маленькое движение в сторону строгой типизации будет полезно для качества, в ущерб скорости наброса. Typescript и есть такое аккуратное движение в эту сторону.
Reply
А не могли бы вы пояснить что значит математически полное покрытие тестами, и какой цели оно служит? Потому что если оно только гарантирует корректность использования всех типов, то это бессмысленно, потому что программа может быть некорректной, но все типы совпадают.
Reply
Как говорил Дейкстра, отладка программы - это сведение количества ошибок к приемлемому минимуму. Так и живём:)
Reply
погуглил, нашел мало. Приведите пример?
Reply
Leave a comment