Как вы боретесь со слабой типизацией и зачем ее придумали?

Question

[WebDev]

Я замучался. Пишу проект на vue.js. Постоянно приходится приводить данные к одному типу, т.к. иначе возникают трудноуловимые баги. Как вы пишете код на жс? Он же не должен быть напичкан parseInt() и !== undefined. Как правильно обрабатывать типы?
И самое главное: кто придумал слабую типизацию? Какие плюсы от нее? Единственное что дает слабая типизация - это заставляет постоянно проверять тип.

Comments

[Lynn «Кофеман»]

Ну используй typescript, kotlin и тп

[devalone]

а не надо с ней бороться, это простой другой стиль кодинга. И кстати, речь видимо всё-таки про динамическую типизацию

Answer 1

[Станислав Макаров]

И самое главное: кто придумал слабую типизацию?

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

Динамическую типизацию придумали для того, чтобы было легче писать обобщённые алгоритмы и мета-алгоритмы, в дин. языке для обобщения кода не нужны ухищрения типа дженериков (TypeScript, C# и много чего ещё) или шаблонов/макросов (C++). В ОО-языках часто доступны и другие удобства, например смена интерфейса объекта в зависимости от его состояния (т.к. решение о возможности вызова метода/свойства объект может принимать сам).

Слабую типизацию придумали чтобы заставить людей страдать (да, я не знаю кому такое нужно вообще).

Как вы пишете код на жс?

Мы не пишем код на JS, мы пишем код на TypeScript. Да, такие сейчас странные времена, когда язык со статической типизацией компилится в язык с динамической, т.к. исполнять на клиенте (в браузере) больше нечего пока.

Он же не должен быть напичкан parseInt() и !== undefined.

Не должен. Если писать на голом JS, можно а) использовать JSDoc для аннотаций о типах, и работать с типами на уровне документации и договорённостей; б) писать алгоритмы в максимально обобщенной манере, и требовать по возможности не конкретных типов данных, а значений, над которыми допустимы нужные вам операции; в) покрывать код тестами, что и спасает в динамических языках.

Чем больше проект, тем важнее статическая типизация, это нормально. JS - это язык который популярен по техническим причинам и по стечению обстоятельств, а не потому что он этого заслуживает (имхо). Очень неглупые дяди и тёти не стали бы тратить годы своего времени и кучу денег на разработку TypeScript и Flow, если бы это было ненужно.

Comments

[Kir ---]

Не вижу ничего в вопросе про динамически типизация. Всё про не строгую

Answer 2

[Сергей Горностаев]

Хорошая архитектура снижает необходимость в приведении типов.

А придумали и используют динамическую типизацию потому, что она существенно снижает TTM.

Comments

[Kir ---]

Человек вам про слабую, вы ему про динамическую

[Сергей Горностаев]

Kir ---, если хорошенько вчитаться в его текст, а также почитать комментарии под ответами, станет заметно, что автор имел ввиду скорее динамическую. Но если говорить именно про слабую, то ответ будет: "В этом не было какого-то особого смысла, просто авторы JavaScript оказались недостаточно дальновидны в проектировании языка и недостаточно хороши в разработке первых его реализаций, чтобы сделать строгую типизацию".

[Kir ---]

Сергей Горностаев,

. Как вы пишете код на жс? Он же не должен быть напичкан parseInt() и !== undefined.

Вот человек пишет, что вы везде должны проверять что вам пришло на вход.
Где тут статическая типизация не понятно. Это как раз про строгую.

[Сергей Горностаев]

Kir ---, похоже, что вы глубоко разбираетесь в этой теме. Уверен, автору вопроса и другим пользователям был бы полезен написанный вами ответ.

Answer 3

[Антон Спирин]

Для этого в проектах используют TypeScript или Flow:

const foo = (arg: number) => { /* do something with number type */ };

Сейчас без них большие проекты лучше даже не начинать.

О преимуществах слабой типизации:
1. Удобство использования смешанных выражений (например из целых, вещественных чисел и строк).
2. Абстрагирование от типизации и сосредоточение на задаче.
3. Краткость записи.

Answer 4

[profesor08]

Если ты дергаешь всякие значения из документа, или из форм, то по умолчанию там тип данных - строка, а раз так, то чему тут удивляться, парси строку. Если ты не объявляешь какую-то переменную, или не задаешь какой-то параметр для функции, то снова, почему удивления, js мыслей читать не умеет? Еще есть параметры по умолчанию.

Answer 5

[Алексей Николаев]

Я не борюсь с ней, я ей наслаждаюсь. Во-первых, у меня крайне редко в переменной бывает несколько типов - если переменная, допустим, строковая, то строковой она и будет. Если же в переменной число, то оно и будет числом, плюс я проведу проверку перед использованием на корректность числа. А во-вторых, всего-то нужно знать базовые правила приведения типов, которые очень простые и понятные в JS. Хотите верьте, хотите нет, но у меня последняя ошибка, связанная со слабой типизацией, была года три назад, если не раньше.

Comments

[Антон Спирин]

Ну это вы наслаждаетесь до поры до времени, пока не пришли работать в огромное веб-приложение, в команду на 10 фронтендеров, которые еще и могут переодически меняться. В таких проектах, которые помимо того, что написать, надо еще поддерживать и масштабировать, использование сложных типов вроде такого:

type Property = {
  id: string,
  name: string,
  type: number,
  participants: Participant[], 
  isDirect: boolean,
  householdId?: number,
}

необходимость.

[Алексей Николаев]

Антон Спирин, это все равно, как ни крути, вариация защиты от дурака. В целом, совершить ошибку со слабой типизацией не сложнее, чем забыть запятую или поставить "=" вместо "==". Да, можно стать джедаем, но можно быть внимательнее или попросить IDE подсвечивать "==" другим цветом.

Чтобы не было проблем с типизацией, стоит:
- использовать const так часто, как только можно
- одно свойство - одна переменная, избегать переопределения переменных далее по коду (в этом и помогает const)
- все свойства получать через геттеры, в геттерах отдавать корректные значения или null
- это же относится и к свойствам классов, реже использовать this.property, чаще - this.getProperty(), заодно можно заблокировать возможность некорректного случайного изменения this.property соотв. сеттером
- делать функции маленькими, чтобы в них было немного переменных
- давать переменным удобоваримые названия, в комментах помечать, какого они типа, код должен быть самодокументируемым
- в нужных местах проводить проверки, приводить к нужному типу явно: нужно число, используй parseInt и проверь, что parseInt вернула корректное число (в геттере или перед использованием)

В итоге, когда, например в PHP включаю строгую типизацию, для меня процесс разработки не меняется. Ошибок новых не возникает - ведь их и не было. А всего-то надо изначально писать код корректно.

[Антон Спирин]

Алексей Николаев, то что вы перечислили, это простые истины которые являются стандартом в современных проектах, кроме, пожалуй, геттеров и сеттеров, по крайней мере в React разработке, в большинстве кейсов в их использовании нет особого смысла, если вы не пишите библиотеки.
Соблюдение перечисленных вами правил, никак не избавляет от необходимости использовать статическую типизацию в больших коммерческих проектах. Это вам скажет любой инсайдер. И дело тут вовсе не во внимательности.
Вам стоит ощутить скорость входа в проект и скорость разработки в большой команде и большом проекте со статической типизацией. Тогда вы поймете о чем речь.

[Алексей Николаев]

Антон Спирин, да, здесь в целом согласен, со статической проще вкатываться в проект, а новые разработчики с меньшей вероятностью натворят дел, т.к. у них банально будет меньше возможностей их натворить. Я написал все вышенаписанное к тому, что бороться с динамической типизацией вовсе ни к чему, при том, что автор пишет проект в одиночку. Ведь вместо этого ее можно понимать и использовать, или, как минимум, не позволять ей портить себе жизнь. Тем паче, что она дает порой невероятно красивые конструкции, например, const a = b || null или if(!property).

[Антон Спирин]

Алексей Николаев, тут я полностью с вами согласен.

Answer 6

[✭ ☭]

Тебе надо бы подучить матчасть в общей теории.
Это догмат такой, у тех людей кто умеет работать только в рамках готового шаблона...

Алан Кей сказал:

«Пока мы не придумаем, как по-настоящему нужно разрабатывать софт, выходом может быть создание динамических систем с экстремально поздним связыванием во всех его проявлениях».

«Позднее связывание позволяет воплощать идеи на поздних стадиях разработки с экспоненциально меньшими усилиями чем традиционное раннее связывание как в C, С++, Java и прочих похожих языках»

«Если вы используете язык с ранним связыванием, как делает большинство людей, вместо языка с поздним связыванием, вы окажетесь взаперти у проделанной работы. Переформулировать что-то будет уже непросто»

«Я не против типов, но я не знаю ни одной системы с типами, которая бы не вызвала мучений, так что я по-прежнему за динамическую типизацию»

аналогично обычно люди не понимают что такое ООП:

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

Answer 7

[Владимир]

Ктож тебя заставляет ее использовать? Бери вон Dart 2, там "Strong, Sound Typing"
https://medium.com/dartlang/announcing-dart-2-80ba...

А вообще есть хорошая поговорка про зеркало и рожу.

Answer 8

[Егор Мокеев]

Вы как-то однобоко смотрите на язык. Для сайтиков отсутствии типизации прямо сильно хорошо, там нет особо сложной логики, разработка идет быстрее

Для js-приложений, spa итд лучше, конечно, иметь какую-никакую типизацию. Уже посоветовали Flow и TypeScript. Я бы к этому списку добавил Closure Compiler, который в плане типизации и тем более обфускации прям хорош.