Oleg
Верная картинка
Oleg
Ещё вон и лезть через люк какой-то каждый раз приходится чтобы аргументы передать
Oleg
Соответствовать интерфейсу же надо
Дима
Ещё вон и лезть через люк какой-то каждый раз приходится чтобы аргументы передать
Стоит уточнить что речь про тупую олдскульную версию, а то же подумают, что у всех так
Oleg
Это не истинно ибо уже есть автоматика
Дима
Где автоматика?) Это просто объявление типа в виде полиморфной строки
Дима
Плюс type inference - в флоу можно писать вообще один входной аргумент на всю страницу
Дима
А всё остальное выведется самостоятельно и будет статически типизированным
Oleg
Джава не отпускает, да
Oleg
А если серьезно то это очень не простой вопрос и с 1958 года на него так и не дали ответ
Oleg
Так и существуют языки со статической и с динамической типизацией, со сторогой и не строгой
Oleg
И на столко всё противоречиво что невозможно вот так с ходу сказать а что на самом деле то лучше
Oleg
К примеру есть философия что нужно говорить компьютеру что ему нужно делать, а не как это делать
Oleg
И тд и тп
Дима
Ну вот js неожиданно стал проводником уникальной конепции - ты можешь работать сколь угодно строго, ну как в обычной джаве, но если тебя это начинает угнетать - ты можешь положиться на type inference и не писать типы, либо переключиться целиком на динамическую типизацию. И все эти кульбиты можно уместить в рамках даже одной функции
Oleg
А на 47 шаге мы пишем html
Oleg
Это я про бабелы и тд
Oleg
Так конечно да, утилиты что поверх языка есть теперь - дают больше плюшек
Дима
А никто не говорил, что современная разработка должна быть простой)
Дима
Но как бы там ни было, flow вполне нормально работает без транспиляции, просто в комментах
Oleg
Есть конечно проблема уровня системы, язык то дальше точно будет, а вот некоторые инструменты иногда помирают
Oleg
Комменты это да
Дима
Ну вот js неожиданно стал проводником уникальной конепции - ты можешь работать сколь угодно строго, ну как в обычной джаве, но если тебя это начинает угнетать - ты можешь положиться на type inference и не писать типы, либо переключиться целиком на динамическую типизацию. И все эти кульбиты можно уместить в рамках даже одной функции
То есть, можно варьировать строгость типизации в зависимости от ситуации и твоих планов. Делаешь сложную трансформацию данных, которая будет ядром всего проекта? Привет Java-style. Горят сроки и вооще в этой функции всё очевидно? Пишем динамически. Это большой плюс, на саммо деле)
Oleg
Я ещё на ExtJS получал подсказки типов в методах через вебшторм
Oleg
И подсветки мол что-то не то
Дима
Шторм не сделает type inference, это совершенно другой уровень
Oleg
Я не копал так глубоко на сколько он делает интерфейсы, но меня устраивали подсказки
Vitaly
type inference using RegEx'es
Дима
Такая типизация как в флоу - это отдельное направление computer science, поэтому с бухты-барахты её не сделать. В шторме мощная типизация, но в рамках её концепции
Oleg
Если билд-папки и вспомогательные файлы убрать - очень даже
Oleg
Ну то есть заигнорить их, там просто повторяющееся идет в комплекте, несколько штук билдов скриптов по 90к строк кода и тп
Oleg
Хеллоу всякие
Oleg
Вот если их пометить как эксклюде - всё отлично
Oleg
С ними - бывает проблема с индексацией потому что ну серьезно, слишком много кода, да ещё повторяющийся, да ещё чуточку, но разный
Oleg
Работал через вебшторм и через идею где ещё было приложение на яве
Oleg
Да, из-за папки с дистрами и билдами, такое может быть
Oleg
Правда не было 15 секунд
Oleg
Но было секунд по 5
Oleg
Когда выгружаешь 100500 файлов, кеш ещё чист и оно пытается распарсить всё это
Oleg
Вебшторм, кстати, под экст оптимизирован, добавлены именно под фреймворк плюшки
Oleg
Типа там имена обработчиков в виде строк понимает, умеет ходить по xtype и тд
Oleg
Как и идея, тоже понимает
Oleg
В общем под экст, если там не в десяток файлов приложение, надо немного подтюнивать и скрывать от индекса то что не нужно
Дима
Ну да
Oleg
Есть даже некоторое удовольствие перечислить типы вот прям каждой переменной
Дима
Вот за что можно ненавидеть ts так это за то как он привил целой индустрии представление о статической типизации как о чём-то нудном, с обязательными тыщами типов аргументов в каждой функции
Дима
Когда это его и исключительно его, я подчёркиваю это, косяк
Дима
То есть такого в принципе быть не должно и на flow этого например нет. Реально порой достаточно одного-единственного типа на весь модуль чтобы вывелось и корректно тайпчекнулось сразу вообще всё
Богдан
И на столко всё противоречиво что невозможно вот так с ходу сказать а что на самом деле то лучше
Я в своих взглядах пришел к однозначному мнению, без всяких противоречий. В споре между статической и динамической типизацией есть один объективный и неоспоримый аргумент про который мало кто вспоминает - язык с динамической типизацией сложнее реализовать чем язык со статической. Все потому что динамически-типизируемые языки медленные - для того чтобы они былы быстрыми надо строить сложные jit-компиляторы.
Богдан
Посмотрите на v8 - у него куча костылей для того чтобы сделать жс быстрым - спекуляция на типах, скрытые классы, тонны проверок с уходом в деоптимизацию и все для того для того чтобы можно было получить свойства у объекта по смещению одной инструкцией ассемблера (не считая конечно проверок), и это все выливается в миллион строк кода, когда же в статически типизированном языке когда мы объявляем типы, компилятору достаточно построить таблицу типов и полей и дальше может просто заменить все доступы к полям на смещения в функции и не нужны никакие рантайм-проверки и реализация такого компилятора очень простая и ее можно может понять любой программист.
Богдан
Так что тут выбор однозначно за статически типизируемым языком, но только с явно объявляемыми типами, потому что если взять функциональные языки которые статически типизируемые, но типы как-то хитро выводятся то реализация вывода этих типов значительно усложнит компилятор и увеличит количество строк кода компилятора и хрен там обычный программист разберется как он работает. А в результате закона дырявых абстракций джаваскрипт-программистам приходятся теперь разбираться во всех тех тоннах костылях оптимизации v8 только для того чтобы писать оптимальный код в итоге от динамического js плохо не только разработчиками v8 а и обычным пользователям которые должны все это учить (вот взгляните на этот чудовищный костыль https://github.com/sindresorhus/to-fast-properties а он ведь применяется в популярной библиотеке промисов bluebird ) А минус у явно объявляемых типов только один - больше приходится печатать но это же сколько коммитов надо создавать в день чтобы на 20 процентов больше количества кода которого надо печатать из-за объявляемых типов хоть как-то повлияла на продуктивность программиста
Дима
Так что тут выбор однозначно за статически типизируемым языком, но только с явно объявляемыми типами, потому что если взять функциональные языки которые статически типизируемые, но типы как-то хитро выводятся то реализация вывода этих типов значительно усложнит компилятор и увеличит количество строк кода компилятора и хрен там обычный программист разберется как он работает. А в результате закона дырявых абстракций джаваскрипт-программистам приходятся теперь разбираться во всех тех тоннах костылях оптимизации v8 только для того чтобы писать оптимальный код в итоге от динамического js плохо не только разработчиками v8 а и обычным пользователям которые должны все это учить (вот взгляните на этот чудовищный костыль https://github.com/sindresorhus/to-fast-properties а он ведь применяется в популярной библиотеке промисов bluebird ) А минус у явно объявляемых типов только один - больше приходится печатать но это же сколько коммитов надо создавать в день чтобы на 20 процентов больше количества кода которого надо печатать из-за объявляемых типов хоть как-то повлияла на продуктивность программиста
Проблема не в том, что печатать много
Дима
Проблема в том, что это отвлекает от цели, от решения задачи. Ты переключаешься на описание типов и выпадаешь из workflow
Дима
По поводу этой либы — это не аргумент. Эта либа требуется для таких низкоуровневых библиотек, что их авторы в любом языке будут задумываться над проблемами эзотерической оптимизации, просто из-за невероятной интенсивности используемого кода
Дима
Сейчас ситуация такаяже с ts ?
Эта ситуация сохранится до версии 3.0 когда бы она не была, потому что им придётся разрушить всю систему типов до самого основания
Никита
Посаны есть кто в node js шарит?
Максим
Посаны есть кто в node js шарит?
Ты сразу вопросы задавай
Никита
У меня тот иногда тренды не отправляет
Никита
Бот *
Никита
И статистику вообще не какую не показывает
Никита
Даже в логах пусто
Smooth Operator
Проблема в том, что это отвлекает от цели, от решения задачи. Ты переключаешься на описание типов и выпадаешь из workflow
Проблема в том что динамический вывод типов позволяет лениться разработчикам
Smooth Operator
Позволяет лениться
Андрей
*facepalm*
Андрей
Ужос, заставь разрабов картошку копать, чтобы не ленились.
Vlad
/A(\d)*A/g.exec('A356A’) < ["A356A", "6", index: 0, input: "A356A»] А как можно сделать чтоб оно находило все цифры между буквами A в строке, то есть чтоб вывод был < ["A356A", «3», «5» "6", ndex: 0, input: "A356A»]
Алексей
'ой-ой-ой'.match( /ой/ig ); (3) ["ой", "ой", "ой"]
Peter
А никто не говорил, что современная разработка должна быть простой)
да все мастодонты об этом уже устали кричать =(
Vlad
я уточню лучше свой вопрос. Можно ли чтоб группа не перезаписывалась следующим найденным совпадением. Тут по сути группа одна получается, а мне нужно чтоб их было столько сколько совпадений, это реально?
CherryTea
Так что тут выбор однозначно за статически типизируемым языком, но только с явно объявляемыми типами, потому что если взять функциональные языки которые статически типизируемые, но типы как-то хитро выводятся то реализация вывода этих типов значительно усложнит компилятор и увеличит количество строк кода компилятора и хрен там обычный программист разберется как он работает. А в результате закона дырявых абстракций джаваскрипт-программистам приходятся теперь разбираться во всех тех тоннах костылях оптимизации v8 только для того чтобы писать оптимальный код в итоге от динамического js плохо не только разработчиками v8 а и обычным пользователям которые должны все это учить (вот взгляните на этот чудовищный костыль https://github.com/sindresorhus/to-fast-properties а он ведь применяется в популярной библиотеке промисов bluebird ) А минус у явно объявляемых типов только один - больше приходится печатать но это же сколько коммитов надо создавать в день чтобы на 20 процентов больше количества кода которого надо печатать из-за объявляемых типов хоть как-то повлияла на продуктивность программиста
ну зачем ты мне это показал, я же любил js
Vlad
Решил не с помощью регулярок. Захватил все цифры, а потом просто split`нул их
CherryTea
Так что тут выбор однозначно за статически типизируемым языком, но только с явно объявляемыми типами, потому что если взять функциональные языки которые статически типизируемые, но типы как-то хитро выводятся то реализация вывода этих типов значительно усложнит компилятор и увеличит количество строк кода компилятора и хрен там обычный программист разберется как он работает. А в результате закона дырявых абстракций джаваскрипт-программистам приходятся теперь разбираться во всех тех тоннах костылях оптимизации v8 только для того чтобы писать оптимальный код в итоге от динамического js плохо не только разработчиками v8 а и обычным пользователям которые должны все это учить (вот взгляните на этот чудовищный костыль https://github.com/sindresorhus/to-fast-properties а он ведь применяется в популярной библиотеке промисов bluebird ) А минус у явно объявляемых типов только один - больше приходится печатать но это же сколько коммитов надо создавать в день чтобы на 20 процентов больше количества кода которого надо печатать из-за объявляемых типов хоть как-то повлияла на продуктивность программиста
впрочем этот костыль не актуален слава богу после 60 версии хрома
CherryTea
https://jsperf.com/test-dictionary-mode