Ну вы обобщаете, про идиотов, сроки и дебаг, я вот тоже обобщаю. Я говорил про конкретную касту "отрицальщиков типов", с которыми я лично работал. Они обычно гордятся своим незнанием, любят делать запутанные штуки, используют динамические возможности JS во зло, скажем так. При этом есть огромная куча хороших проектов на чистом JS, которые понятны и хорошо работают.
я прекрасно вижу какой ценой достигается это "удобство" и "понятность". Код пишется дольше, читается дольше и работает хуже по всем метрикам .
Конечно можно верить во всемирный заговор Microsoft по созданию TS, как инструмента для затягивания сроков и увеличения бюджетов. А можно задуматься, а почему с TS у вас код даже работает хуже, хотя по-факту это надмножество языка. TS создавался с целью помочь программистам. Если же вы с ним боретесь, то вероятно надо повысить экспертизу в команде, например. Know your instrument, как говорится. Причем, в отличие от других языков, тут можно задавать уровень точности компилятора, и в случае затруднений точечно избегать типизации. Можно обходиться только простыми интерфейсами, без дженериков и всяких advaced types, чисто для дополнительной помощи в IDE. А можно проинвестировать в знания и фигачить всё на максималках, с большим трудом, но и с большими гарантиями и большим профитом по итогу.
В конце концов, я предпочту, чтобы за меня всякой рутиной по проверке корректности данных занимались проклятые роботы, а я уж логику буду писать и тестировать именно её, а не писать тесты на то чтобы в функцию какую-то фигню не передали.
Я просто боюсь, что так сильно распущусь, что тоже начну в конструкторе методы объявлять. Это вы свободный человек, а меня за такой код из всех моих галер выкинут(
Я тоже знавал таких разрабов, ярых противников TS. Очень горды тем, что пишут на том самом js. Очень горды тем, что им типы нафиг не нужны. И обычно они работают одни, пилят прототипы, которые не будут поддерживать никто, либо пилят свои проекты в одиночку, потому что уровень велосипедства там такой, что никто больше не разберётся. Не все, конечно, но большинство такие.
Самое смешное, они реально думают, что тайпскриптеры целыми днями сидят и типы свои пишут, вместо работы. Напоминают пожилых людей, которые не разбираются в компухтерах и ругают айтишников в духе "кнопки свои нажимает, штаны просиживает, лучше бы делом занялся".
идиотами которые не могут отдебажить элементарные вещи
Ну я тоже) Я отвечал мистеру @flancer, который как бы доверяет себе и партнёру, но типы всё-равно везде ставит, просто в менее удобном и менее мощном виде.
Вот вам пример кода от адепта типов в JsDoc. В тайпскрипте строчек будет поменьше, если вас так пугает количество букв. Как минимум,/** @type { заменяется на : .
TS не даст скомпилироваться некорректному коду. Когда вся кодовая база на нём надо очень постараться, чтобы скомпилировать код с ошибками. На этом шаге надо призадуматься, а точно ли оно надо? Что нужно сделать, чтобы запустить ломаный код с JSDoc? node index.js и всё.
JSDoc'и лишь помогают IDE помогать вам ориентироваться в вашем коде
А TS позволяет описывать контракты и всякие иварианты. Что позволяет сузить количество проблемных мест.
после проверки на наличие ключа TS должен бы вывести A & { y: unknown }
В этом месте не будет выведения типа, а только сужение из уже имеющегося множества. Изначально у нас тип param равен A | B , так что в дальнейшем он не может вывести в другой тип
Там нежданчик не в месте проверки и вывода типа param , а в месте вызова функции. Странно то, что можно в функцию передать obj, потому что он не соответствует типу A | B, который принимает функция. Тип у obj выводится компилятором как { x: number, y: null }, но функция принимает либо { x: number }, либо { x: number, y: number } . Там на месте y может быть любой тип, и функция всё-равно его схавает. А ты вроде как ждёшь только A или B, в котором y будет number.
Всё-таки важно. Она должна быть удобной (чтобы ты ей пользовался, а не избегал) и обязательной (иначе в один момент просто забудешь запускать проверки).
Создавать модуль, создавать типы с которыми он работает
Так я рефакторю typescript-проект, у меня типы уже есть.
создавать новые интерфейсы для методов, если параметры поменяются
Это не так работает. Меняются параметры функции -> тайпскрипт выводит сигнатуру этой функции -> автоматом проверяет, все ли использования этой функции корректны. Если я где-то забыл перейти на новую сигнатуру у меня просто выскочит ошибка с указанием места.
Теперь перейдём в мир js. Что там будет, если поменять сигнатуру функции? Да ничего, если вы забудете где-то поменять параметры, то об этом узнаете только в рантайме. Повезёт, если сразу станет понятно проблемное место.
Если же меняется структура данных, которыми манипулирует функция, т.е. интерфейсы, то их поправить занимает не так много времени. При этом опять же, тс сразу покажет, где эти типы используются и
Где тут ускорение рефакторинга ?
Рефакторинг - это не только изменение кода, но и проверка на корректность. Изменение кода обычно быстрее, так как я сразу вижу всё что нужно исправить. Проверка тоже быстрее, потому что часть глупых ошибок, типа "забыл изменить имя поля, забыл добавить второй параметр в функцию, опечатался в названии" просто исчезают навсегда. Пример я приводил - поменять поле name в одной структуре, не трогая другую. Простым поиском и заменой тут дело не решишь. Могу ещё примеров накидать
Противники типизации никак не могут понять, что они тоже в конечном итоге работают с типами, потому что данные, которыми манипулируют не рандомные, а имеют какую-то структуру. Только вот типы у них "вылазят" в самый последний момент, когда их уже используют. Но из-за динамичности языка где-то на пути от, условно получения из апи до вывода на экран, какие-то типы могут быть неправильно преобразованы или использованы. Тайпскрипт просто позволяет выявить это раньше, до запуска.
Это как писать программу по ТЗ. JS - это устные договорённости, которые все забывают или искажают, неверно интерпретируют (потому что описано размыто). Поэтому нужный результат долго получается - слишком много доделок. TS - это нормальное ТЗ записанное в условном конфлюенсе, где всё оговорено, где пограничные случаи описаны, так что ты просто читаешь и пишешь. Мне вот по второму способу удобнее и быстрее работать.
Как минимум имз за того что раза в три больше кода писать надо.
Берите больше, в 10 раз!
Я вот код больше читаю/исправляю, чем пишу. Писать мне всякие AI-ассистенты и IDE помогают. А вот время на поиск глупых ошибок, вроде опечаток имени полей в рантайме, почему-то противники тайпскрипта не учитывают. Видимо они реально только пишут код, но не сопровождают его.
Не видел еще проектов, крооме блокчейнов где type sacript был бы прямо неоьходим.
Ну ничто не необходимо, так-то можно и на бэке всё на ассемблере писать или сразу в машкодах. Типизация это просто вопрос удобства разработки и уменьшения проблем до запуска программы.
Попробуйте порефакторить любой большой js проект. Например, есть 2 эндпоинта /api/user и /api/item. Они возвращают схожие объекты с полем name: `{ id: 1, name: 'name', ... }`. Далее, эти данные разлетаются по всему приложению на сотню различных страниц. Теперь мы хотим переименовать name в fullName для юзера, но оставить name у item нетронутым. Typescript позволит сразу увидеть, где мы используем старое поле и где нужно его сменить (Ну и чем больше описано типов, тем проще что-то добавлять или изменять). Для js же обычно всё вылезет в рантайме.
Ответ вам дали. Риск потерять деньги есть везде, любой банк может заблочить счета если сильно захочет (или его вынудят). У меня у друга блочили счета просто потому что где-то в другом городе был должник, который был его полный тёзка с той же датой рождения. Т.е. за чужой долг блочили счёт моего друга. А ещё вас могут внезапно для всех объявить экстремистом, например, если когда-то кому-то что-то переводили.
Хочется меньше рисков - переводите мелкими партиями из разных источников, переводите с карты, на которой мало денег и т.д.
А что будет, когда отключится интернет? Notion уже может в офлайне работать?
Можно структурировать, больше визуала, больше возможности разметки, можно ссылаться на что-то. Сам веду заметки в Obsidian.
Ну вы обобщаете, про идиотов, сроки и дебаг, я вот тоже обобщаю. Я говорил про конкретную касту "отрицальщиков типов", с которыми я лично работал. Они обычно гордятся своим незнанием, любят делать запутанные штуки, используют динамические возможности JS во зло, скажем так. При этом есть огромная куча хороших проектов на чистом JS, которые понятны и хорошо работают.
Конечно можно верить во всемирный заговор Microsoft по созданию TS, как инструмента для затягивания сроков и увеличения бюджетов. А можно задуматься, а почему с TS у вас код даже работает хуже, хотя по-факту это надмножество языка. TS создавался с целью помочь программистам. Если же вы с ним боретесь, то вероятно надо повысить экспертизу в команде, например. Know your instrument, как говорится. Причем, в отличие от других языков, тут можно задавать уровень точности компилятора, и в случае затруднений точечно избегать типизации. Можно обходиться только простыми интерфейсами, без дженериков и всяких advaced types, чисто для дополнительной помощи в IDE. А можно проинвестировать в знания и фигачить всё на максималках, с большим трудом, но и с большими гарантиями и большим профитом по итогу.
В конце концов, я предпочту, чтобы за меня всякой рутиной по проверке корректности данных занимались проклятые роботы, а я уж логику буду писать и тестировать именно её, а не писать тесты на то чтобы в функцию какую-то фигню не передали.
Я просто боюсь, что так сильно распущусь, что тоже начну в конструкторе методы объявлять. Это вы свободный человек, а меня за такой код из всех моих галер выкинут(
Я тоже знавал таких разрабов, ярых противников TS. Очень горды тем, что пишут на том самом js. Очень горды тем, что им типы нафиг не нужны. И обычно они работают одни, пилят прототипы, которые не будут поддерживать никто, либо пилят свои проекты в одиночку, потому что уровень велосипедства там такой, что никто больше не разберётся. Не все, конечно, но большинство такие.
Самое смешное, они реально думают, что тайпскриптеры целыми днями сидят и типы свои пишут, вместо работы. Напоминают пожилых людей, которые не разбираются в компухтерах и ругают айтишников в духе "кнопки свои нажимает, штаны просиживает, лучше бы делом занялся".
Высокомерный мем внутри
Ну я тоже) Я отвечал мистеру @flancer, который как бы доверяет себе и партнёру, но типы всё-равно везде ставит, просто в менее удобном и менее мощном виде.
Я понял, вы просто сразу пишете программы без ошибок. Всем бы так
Вот вам пример кода от адепта типов в JsDoc. В тайпскрипте строчек будет поменьше, если вас так пугает количество букв. Как минимум,
/** @type {заменяется на:.TS не даст скомпилироваться некорректному коду. Когда вся кодовая база на нём надо очень постараться, чтобы скомпилировать код с ошибками. На этом шаге надо призадуматься, а точно ли оно надо? Что нужно сделать, чтобы запустить ломаный код с JSDoc?
node index.jsи всё.А TS позволяет описывать контракты и всякие иварианты. Что позволяет сузить количество проблемных мест.
В этом месте не будет выведения типа, а только сужение из уже имеющегося множества. Изначально у нас тип
paramравенA | B, так что в дальнейшем он не может вывести в другой типТам нежданчик не в месте проверки и вывода типа
param, а в месте вызова функции. Странно то, что можно в функцию передатьobj, потому что он не соответствует типуA | B, который принимает функция. Тип у obj выводится компилятором как{ x: number, y: null }, но функция принимает либо{ x: number }, либо{ x: number, y: number }. Там на местеyможет быть любой тип, и функция всё-равно его схавает. А ты вроде как ждёшь только A или B, в которомyбудетnumber.Всё-таки важно. Она должна быть удобной (чтобы ты ей пользовался, а не избегал) и обязательной (иначе в один момент просто забудешь запускать проверки).
Так я рефакторю typescript-проект, у меня типы уже есть.
Это не так работает. Меняются параметры функции -> тайпскрипт выводит сигнатуру этой функции -> автоматом проверяет, все ли использования этой функции корректны. Если я где-то забыл перейти на новую сигнатуру у меня просто выскочит ошибка с указанием места.
Теперь перейдём в мир js. Что там будет, если поменять сигнатуру функции? Да ничего, если вы забудете где-то поменять параметры, то об этом узнаете только в рантайме. Повезёт, если сразу станет понятно проблемное место.
Если же меняется структура данных, которыми манипулирует функция, т.е. интерфейсы, то их поправить занимает не так много времени. При этом опять же, тс сразу покажет, где эти типы используются и
Рефакторинг - это не только изменение кода, но и проверка на корректность. Изменение кода обычно быстрее, так как я сразу вижу всё что нужно исправить. Проверка тоже быстрее, потому что часть глупых ошибок, типа "забыл изменить имя поля, забыл добавить второй параметр в функцию, опечатался в названии" просто исчезают навсегда. Пример я приводил - поменять поле name в одной структуре, не трогая другую. Простым поиском и заменой тут дело не решишь. Могу ещё примеров накидать
Противники типизации никак не могут понять, что они тоже в конечном итоге работают с типами, потому что данные, которыми манипулируют не рандомные, а имеют какую-то структуру. Только вот типы у них "вылазят" в самый последний момент, когда их уже используют. Но из-за динамичности языка где-то на пути от, условно получения из апи до вывода на экран, какие-то типы могут быть неправильно преобразованы или использованы. Тайпскрипт просто позволяет выявить это раньше, до запуска.
Это как писать программу по ТЗ. JS - это устные договорённости, которые все забывают или искажают, неверно интерпретируют (потому что описано размыто). Поэтому нужный результат долго получается - слишком много доделок. TS - это нормальное ТЗ записанное в условном конфлюенсе, где всё оговорено, где пограничные случаи описаны, так что ты просто читаешь и пишешь. Мне вот по второму способу удобнее и быстрее работать.
То есть фактически без проверок на ошибки, потому что ломаный код всё равно можно запустить.
Можно пример?
Сочувствую. В моём тайпскрипте по-другому.
Берите больше, в 10 раз!
Я вот код больше читаю/исправляю, чем пишу. Писать мне всякие AI-ассистенты и IDE помогают. А вот время на поиск глупых ошибок, вроде опечаток имени полей в рантайме, почему-то противники тайпскрипта не учитывают. Видимо они реально только пишут код, но не сопровождают его.
Зачем? Уже есть typescript. Система типов там ощутимо лучше C#. Некоторых языковых фич C# может и не хватает, но не так чтобы прям критично.
Ну ничто не необходимо, так-то можно и на бэке всё на ассемблере писать или сразу в машкодах. Типизация это просто вопрос удобства разработки и уменьшения проблем до запуска программы.
Попробуйте порефакторить любой большой js проект. Например, есть 2 эндпоинта
/api/userи/api/item. Они возвращают схожие объекты с полем name: `{ id: 1, name: 'name', ... }`. Далее, эти данные разлетаются по всему приложению на сотню различных страниц. Теперь мы хотим переименоватьnameвfullNameдля юзера, но оставитьnameу item нетронутым. Typescript позволит сразу увидеть, где мы используем старое поле и где нужно его сменить (Ну и чем больше описано типов, тем проще что-то добавлять или изменять). Для js же обычно всё вылезет в рантайме.Ответ вам дали. Риск потерять деньги есть везде, любой банк может заблочить счета если сильно захочет (или его вынудят). У меня у друга блочили счета просто потому что где-то в другом городе был должник, который был его полный тёзка с той же датой рождения. Т.е. за чужой долг блочили счёт моего друга. А ещё вас могут внезапно для всех объявить экстремистом, например, если когда-то кому-то что-то переводили.
Хочется меньше рисков - переводите мелкими партиями из разных источников, переводите с карты, на которой мало денег и т.д.
Кстати, в чем проблемы с законом?
Вот пополнение.
Пополнение
Банковские карты принимает https://neocrypto.net/ . Ну и всегда можно p2p переводить. Как тут хз, но есть всякие https://www.bestchange.com, где есть продавцы с рейтингом.
Дальше надо ввести номер и вроде ФИО, чтобы получить базовую верификацию. С ней доступны вот такие лимиты
Лимиты