а говна написать каждый сможет в любом стиле (но без типов это сделать проще)

причем тут разбираться, я уже на каком только языке с типами не писал, начиная от си заканчивая свифтом и не уведел того большого профита который обещают)

> дженерики > си

> дженерики > си

эм

причем тут разбираться, я уже на каком только языке с типами не писал, начиная от си заканчивая свифтом и не уведел того большого профита который обещают)

возьми раст)) там вообще типы максимально простые есть типажи и норм)

я честно не пробовал раст, но слышал что там safe писать нереально сложно и многие пишут unsafe код)

а где раст вообще юзают?

я честно не пробовал раст, но слышал что там safe писать нереально сложно и многие пишут unsafe код)

неправда)) safe писать там очень просто

а где раст вообще юзают?

В мозилле

а где раст вообще юзают?

очень часто вижу в криптообменниках

в рашке только в крипте встречал

http://fsharpforfunandprofit.com/posts/ten-reasons-not-to-use-a-functional-programming-language/

?

неправда)) safe писать там очень просто

с clone да )))

Может нахер этот flow?:)

Блин, я специально вбросил, чтобы разобраться плюсы/минусы

Может нахер этот flow?:)

правильно, есть TS

Минусов не нашёл

Если нравится без него - не используй)

Хороший холивар, можно понять зачем что делается и какие у этого плюсы

+1 что хорошая тема, и вывод для меня такой: вот если покрывать все тестами, это не выгодно экономически, с типами я могу писать тесты только там где не хватает типов, где это важно (бизнес логика), а ошибки уровня гетеров/сетеров или параметров функций - тут типы просто не дадут скомпилировать код так чем сильнее система типов тем меньше нужно на самом деле тестов

Просто вы написали единственное приемущество строгой типизации - меньше ошибок

Единственное преимущество строгой типизаци — ты в каждый момент времени понимаешь, какие именно данные тебя сейчас в распоряжение и в какой форме. Покрыв код типами можешь узнать много нового о том, как работает твой код (и о новых проявлениях слова «чудо») Потому что типизатор мыслит совсем не так как человек, и когда ты точно уверен, что у тебя в функцию приходит, допустим number, он может увидеть, что это тебе совсем не гарантируется и где-то в коде тебя string неявно кастуется в number, сколько раз такое было

потому что еще строгая типизация нужна

redux-form положил на flow

чтобы не было "string неявно кастуется в number"

Если юзать redux-form то будет пулять тебе нетипизированные экшены

export type Action = { type: 'favorites/FILL', +payload: FavoriteNormalizePayload } | { type: 'favorites/SELECT', +payload: ?string } | Object ; Вот такой щит приходится делать

чтобы не было "string неявно кастуется в number"

Я просто пример привёл сходу, суть не в динамической типизации самой по себе)

Я просто пример привёл сходу, суть не в динамической типизации самой по себе)

ну да

я понимаю

тоже накипело )

ну например с тем что понятнее программа с типами, тоже не факт, особенно дженерики когда

Программа с типами вообще не обязана становиться более понятной, она становится более определённой и конкретной

Программа с типами вообще не обязана становиться более понятной, она становится более определённой и конкретной

не я придумал про понятность)

Ок, я мимо проходил. не вчитывался)

Программа с типами вообще не обязана становиться более понятной, она становится более определённой и конкретной

неопределенность увеличивает непонятность

типы это дешевый и простой тест вашего кода

его ограничение - малая область покрытия программы

Чет подзаебался я с этими типами:)

Медленно все(

неопределенность увеличивает непонятность

Увеличивает, просто понятность саму по себе никто не гарантирует) Реально слишком абстрактные дженерики как контрпример.

Увеличивает, просто понятность саму по себе никто не гарантирует) Реально слишком абстрактные дженерики как контрпример.

с этим согласен. Но код с типами, по умолчанию, немного понятнее кода без типов

с этим согласен. Но код с типами, по умолчанию, немного понятнее кода без типов

не

а где раст вообще юзают?

Новый двиган Servo пишется на Rust. Servo - огонь по описанию.

не

почему нет? function foo(bar) { return bar.baz } vs function foo(bar: Bar): Baz { return bar.baz } даже знаешь что открыть, какой тип смотреть и знаешь, что сюда другое не прокинуть

Если честно не удобно, когда длинные имена классов

почему нет? function foo(bar) { return bar.baz } vs function foo(bar: Bar): Baz { return bar.baz } даже знаешь что открыть, какой тип смотреть и знаешь, что сюда другое не прокинуть

ну вот как раз хороший пример, где типы ничего хорошего не дали

Если честно не удобно, когда длинные имена классов

это да

ну вот как раз хороший пример, где типы ничего хорошего не дали

лол

Типа MySoLongLengthClass

Типа MySoLongLengthClass

при чем тут типы?

При том, что у тебя длинна строки увеличивается в два раза

ну вот как раз хороший пример, где типы ничего хорошего не дали

то есть по твоему, открыв эту функцию без типов ты всё сразу поймешь? или же открыв код функции с типами, тебе ничего понятно не будет?

то есть по твоему, открыв эту функцию без типов ты всё сразу поймешь? или же открыв код функции с типами, тебе ничего понятно не будет?

именно эту - да, она ж в одну строку

более того, если я открыл код функции, значит с ней уже что-то не так)

При том, что у тебя длинна строки увеличивается в два раза

чет не пойму как типы увеличивают длину имени класса

именно эту - да, она ж в одну строку

ты знаешь типы, которые она возвращает и которые принимает ты с ходу знаешь с какими данными она работает

ты знаешь типы, которые она возвращает и которые принимает ты с ходу знаешь с какими данными она работает

для функции в одну строку я это итак знаю, без типов

это весьма утрированный пример есть функции посложнее в разы (что не есть хорошо конечно) но которые сходу понять очень сложно

и нормальный компилятор тож должен это знать

чет не пойму как типы увеличивают длину имени класса

Типы увеличивают длинну строки, в котрой их используют

это весьма утрированный пример есть функции посложнее в разы (что не есть хорошо конечно) но которые сходу понять очень сложно

ну как контрпример - посмотри типизацию compose для 5 аргументов

Привет всем. Подскажите пожалуйста, как можно изменить состояние сразу нескольких компонентов ? по событию в одном компоненте должно быть setState({ключ : true}) , а остальных из этого же массива setState({ключ : false}) ?

Типы увеличивают длинну строки, в котрой их используют

эм, имя класса тут при чем

ERROR: S client not available

ну как контрпример - посмотри типизацию compose для 5 аргументов

видел, знаю а использование этого сложного, как-то ухудшает? когда ты наводишь на аргумент и видишь его тип

видел, знаю а использование этого сложного, как-то ухудшает? когда ты наводишь на аргумент и видишь его тип

твой аргумент был про чтение кода, чтение этого определения ничего хорошего не дает

Привет всем. Подскажите пожалуйста, как можно изменить состояние сразу нескольких компонентов ? по событию в одном компоненте должно быть setState({ключ : true}) , а остальных из этого же массива setState({ключ : false}) ?

ключ одинаковый для компонентов?

да

твой аргумент был про чтение кода, чтение этого определения ничего хорошего не дает

код состоит не только из определений функций

видел, знаю а использование этого сложного, как-то ухудшает? когда ты наводишь на аргумент и видишь его тип

при этом я не говорю, что типы не нужны, очень часто нужны

я думаю это не очень хорошая практика, изменился стейт - обновились компоненты

а, стоп, сам стейт

код состоит не только из определений функций

с этим не спорю)

эм, имя класса тут при чем

Если длинное имя класса, то есть высокая вероятность, что оно не влезет в 100 символов строки, в которой используется flow, подобное я заметил в TypeScript

стараюсь не писать длинные имена классов

Привет всем. Подскажите пожалуйста, как можно изменить состояние сразу нескольких компонентов ? по событию в одном компоненте должно быть setState({ключ : true}) , а остальных из этого же массива setState({ключ : false}) ?

а что если компонентам из контейнера стейт передавать через пропсы?

хм

мне нужно по клику менять значение на true , а остальным ставить false\

Если длинное имя класса, то есть высокая вероятность, что оно не влезет в 100 символов строки, в которой используется flow, подобное я заметил в TypeScript

таааак а если нет ни флоу ни тс, то вероятность будет меньше?

ну ты передаешь одному компоненту true в явном виде, а другим его реверсишь

т.е. на false

а как это сделать ?

в етом и вопрос

setState для нескольких сразу поменять

про типы можно еще в другом ключе поговорить, например корректность программы и ошибки с типами можно быстро отлаживать если ты работает с системой которая дает тебе быстрый фидбек. например в кложуре ты подключился к реплу, который к твоей программе подключен, и пишешь итеративно, написал кусок кода - проверил, и так далее. с типами ты вынужден написать большой кусок кода - потом борьба с компилятором и только потом запуск программы и ее проверка на корректность. в общем просто это разные подходы и у каждого есть свои плюсы и минусы, но я не стал бы говорить что типы это единственный правильный путь ;)

а как это сделать ?

эм !true

да ето понятно

ты меняешь стейт в контейнере, а значения стейта передаешь в компоненты через пропсы

можешь повесить доп. флаг для пропсов

а, не, флаг не нужен

или можно добавить, чтобы потом ориентироваться по нему внутри компонента уже, берешь этот пропс и реверсишь

таааак а если нет ни флоу ни тс, то вероятность будет меньше?

Бля, ты что угораешь? В флоу приходится использовать имена классов для проверки типов, из - за этого длинна строки, в которой используется флоу увеличивается в 1.5 - 2 раза. Всё забей, нравится флоу, используй.

Бля, ты что угораешь? В флоу приходится использовать имена классов для проверки типов, из - за этого длинна строки, в которой используется флоу увеличивается в 1.5 - 2 раза. Всё забей, нравится флоу, используй.

лол)))