Comments 10
Зачем нужен Dart 2.0, если первый-то не взлетел?
Хороший вопрос, мистер Хейтер, ответить на него можно просто: затем. Затем, что если посмотреть на изначальную задумку, Dart должен был целиком заменить JavaScript, а из этого следовало то, что Dart — «JIT компилируемый браузерный язык с динамической типизацией». Хочешь — типизируешь. Хочешь — нет. Однако времена меняются, и Dart вместе с ними.
Dart должен был целиком заменить JavaScript, но не заменил, но вот вам вторая версия со строгой типизацией, потому что можем.
Как-то так что ли?
Эх, как порой хочется написать что-то типа:
List<int> prices = [«99», «27», «10000», «200000»];
Что, серьезно?!
Мы у себя вкрутили Strong Mode достаточно давно и, надо сказать, что ошибок, связанных с типами, стало гораздо меньше.
Я вот сколько работал над разными проектами и в разных командах, ошибки, вызванные отсутствием строгой типизации вообще не припомню. И да, даже в проекте с JS вместе с Dart :) Тем более при production-build этот самый Strong Mode отключался :)
Strong Mode скорее для девелопмента.
ошибки, вызванные отсутствием строгой типизации вообще не припомню
Но тем не менее они бывают
На мой взгляд, явная и строгая типизация позволяют избегать некоторых ошибок косвенно.
Т.е. представьте себе ситуацию, в смотрите на чужой код, есть метод, у него на вход аргумент, но вы не знаете какого он типа. Чтобы понять, что же вам туда закинуть, нужно посмотреть на логику работы метода: какие методы и свойства у аргумента используются внутри, посмотреть на примеры вызова метода с этим аргументом. Это в случае с «утиной типизацией» js. В случае с Java например вы просто смотрите на тип — все. Можете кликнуть на тип и увидеть его определение. Можете кликнуть на метод и увидеть в каком классе он и как он работает. В js так не получится — кликните на метод — увидите все методы в системе с таким названием.
К чему я это — повышение сложности в понимании приводит к повышению вероятности допустить ошибку, на мой взгляд. А ошибки в очень большом проценте случаев как раз связаны с непониманием или недопониманием того, как работает конкретный код. Все инструменты, которые помогают упростить понимание при чтении кода крайне полезны. И чем больше объемы кода с которыми ты работаешь, тем лучше ты чувствуешь пользу от таких вещей.
Т.е. представьте себе ситуацию, в смотрите на чужой код, есть метод, у него на вход аргумент, но вы не знаете какого он типа. Чтобы понять, что же вам туда закинуть, нужно посмотреть на логику работы метода: какие методы и свойства у аргумента используются внутри, посмотреть на примеры вызова метода с этим аргументом. Это в случае с «утиной типизацией» js. В случае с Java например вы просто смотрите на тип — все. Можете кликнуть на тип и увидеть его определение. Можете кликнуть на метод и увидеть в каком классе он и как он работает. В js так не получится — кликните на метод — увидите все методы в системе с таким названием.
К чему я это — повышение сложности в понимании приводит к повышению вероятности допустить ошибку, на мой взгляд. А ошибки в очень большом проценте случаев как раз связаны с непониманием или недопониманием того, как работает конкретный код. Все инструменты, которые помогают упростить понимание при чтении кода крайне полезны. И чем больше объемы кода с которыми ты работаешь, тем лучше ты чувствуешь пользу от таких вещей.
Как по мне, это больше проблема документации и организации проекта, и типизация помогает в этом хоть как-то. Не всегда ведь хочется писать, скажем, jsdoc, а при типизации хоть что-то приличное получается. Может это как-то и ускоряет процесс разработки в итоге, но я лично не уверен, да и видел никаких исследований на эту тему.
А про ошибки типа «мы вот здесь ждем строку, а ты шлешь число» — в продакшене не встречал, обычно такое в процессе написания кода исправляется. Но, видимо, мне везло просто и с коллегами, и с проектами :)
Ну и я имею в виду разработку именно web-приложений, в других областях — там своя специфика.
А про ошибки типа «мы вот здесь ждем строку, а ты шлешь число» — в продакшене не встречал, обычно такое в процессе написания кода исправляется. Но, видимо, мне везло просто и с коллегами, и с проектами :)
Ну и я имею в виду разработку именно web-приложений, в других областях — там своя специфика.
Dart выглядит приятно, но по-моему Гугл подрубил ему корни, когда сначала хотел научить Crome интерпритировать его, а потом передумал. Ну и на вопрос «Кто использует Dart в реальных проектах?» никого кроме Wrike на ум не приходит. Может они и есть, но не сильно это афишируют. В итоге получается ещё один TypeScript, только менее популярный.
Всё-таки Dart — не TypeScript. Например большая разница в типах (https://www.youtube.com/watch?v=6XCkB9Nr2s8&index=4&list=PLxcvsYzLfaTDQM6PoN-foQ5q0SM9vG9Yt).
Так же есть разница в SDK (у TS его нет), ну и вот сейчас есть Flutter.
Из реальных проектов — https://www.dartlang.org/community/who-uses-dart. В СНГ действительно не очень много компаний. За рубежом — огромная Workiva.
Многие, сравнивая те или иные технологии делают это дискретно, здесь-и-сейчас. И на основании этого ставят крест на всём языке. Но это не совсем правильно, всё таки вектор развития тоже очень важен.
За видео спасибо. Теперь я ещё яснее понял, почему TypeScript популярен, а Dart — нет. На протяжении всего рассказа меня не покидала мысль, которую в конце сказал и сам докладчик. TypeScript не мешает думать на JS, а Dart — это несколько другой язык. Так что для большинства JS-разработчиков поведение TypeScript более очевидно.
Про Flutter не знаю радоваться или грустить. Ну запилили ещё один инструмент разработки под Android и iOS. Ну и что? Сейчас их только ленивый не делает. Понятно что в конечном итоге у кого-нибудь должна получиться супер-штука, которая работает и на мобильниках, и на сервере, и в браузере. Но пока я наблюдаю в среде мобильной разработки довольно чёткую поляризацию на «лишь бы как-нибудь работало» и «нужно сделать хорошо». Первым хватает Cordova (и кучи других инструментов для быстрого клепания), а вторые используют Java/Kotlin и Swift. Куда тут втыкать Dart? Вы правильно говорите что вектор важен, но каких-то больших перспектив у языка я на текущий момент не вижу.
Про Flutter не знаю радоваться или грустить. Ну запилили ещё один инструмент разработки под Android и iOS. Ну и что? Сейчас их только ленивый не делает. Понятно что в конечном итоге у кого-нибудь должна получиться супер-штука, которая работает и на мобильниках, и на сервере, и в браузере. Но пока я наблюдаю в среде мобильной разработки довольно чёткую поляризацию на «лишь бы как-нибудь работало» и «нужно сделать хорошо». Первым хватает Cordova (и кучи других инструментов для быстрого клепания), а вторые используют Java/Kotlin и Swift. Куда тут втыкать Dart? Вы правильно говорите что вектор важен, но каких-то больших перспектив у языка я на текущий момент не вижу.
Sign up to leave a comment.
Dart Summit 2018: основные мысли