Pull to refresh
3
0
Ткачук Илья Михайлович @Strain

Пользователь

Send message
Написано же — JavaScript, ES6
Мне понравилась статья, спасибо автору. Плюсанул бы, но кармы мало, так что только так. В первой статье текст был чересчур эмоционален потому что я находился под воздействием свежего погружения в React-Native проект от чего был нестройный слог плюс я забыл пару важных вещей ( в дополнение к тем что там упомянуты )

— кривая реализация integer в JS ( для многих задач крайне критично )
— в стрелочных функциях можно не писать return ( казалось бы ура ), но если там больше одной строки — без написания return спокойно возвращается undefined без всяких предупреждений
— неявные преобразования очень коварны — никогда на 100% нет уверенности какой же тип возвращает данный колбэк из DOM элемента / React компонента ( onChange, onSubmit etc ) и непонятно можно ли с ним безопасно проводить арифметические действия

В общем этот RN проект на ES6 был оставлен на совесть других разработчиков, никакого желания продолжать на этом писать нет. Похоже сработала естественная иммунная реакция организма на JS-мыслевирус, и болезнь не пошла дальше средних стадий. Так что теперь продолжаю писать на любимых языках и наслаждаюсь жизнью.
аргумент про type inference в динамическом языке выглядит довольно странно

Пожалуйста, пример
Мои поздравления, console.log(«hello, world»)
И где же эта волшебная кнопка включения? Пример? Большинство кодовой базы js / lua / python просто перестанет работать правильно в многопоточном рантайме.
Кстати данный бугурт возник в процессе написания RN приложения. Заказчик хочет самые новые технологии — и чтобы сразу под андроид и под ios. И пофиг что RN в бете — мы хотим это, ведь Facebook же! Я согласился по глупости, больше такой ошибки не повторю. Не буду описывать всех найденных косяков RN, проблемы с GL шейдерами которые сходят каждый раз с ума при обновлении RN, и то что на android вообще половина фич не работает. Приведу простой пример. Навигация по скринам приложения. Вещь не специфичная и нужная буквально в каждом мобильном приложении. В ! официальной! доке от Facebook есть ссылка на npm пакет react-navigation. Это недоделка, одна из худших и запутанных библиотек для навигации. Приходится костылять и напильником допиливать официально рекомендованный facebook-ом пакет. Да в нём issue блин больше чем коммитов. И это один из примеров, в самом ядре React Native проблем не меньше.
Да, неявные преобразования усугубляют такой тип ошибки ( впрочем как и почти все типы ошибок ). Касаемо return, циклов и прочих statements — тут дело в парадигме. Видимо вы хорошо владеете императивными языками в которых есть эти statements, поэтому всё и привычно. Но в функциональных языках как правило этих statements нет, да и вообще количество statements минимально потому что всё является expression. JavaScript — не настоящий мульти-парадигменный язык как это утверждается, впрочем как и не настоящий ООП язык ( привет классы JS ). Вот например Scala является и настоящим мультипарадигменным языком и настоящим ООП языком — там можно ( и как говорят многие даже нужно ) писать без этих statements. А в JavaScript слова мультипарадигменность и ООП были добавлены только ради красного словца и зачастую вводят людей из ФП в заблуждение.
Это моё субъективное мнение, без очевидных объективных причин, я так и написал :)
Касаемо меня — return делает код функции более запутанным, а ещё я постоянно его забываю писать. Потому что всю жизнь писал на Erlang, Elixir, Haskell и Lisp. И от забытых return — ов много проблем, потому что функция возвращает undefined без всяких предупреждений и программа потом падает в самом неожиданном месте по какой-нибудь совсем другой причине, отловить трудно. В общем получается много бессмысленной работы.
LuaJIT — один из лучших однопоточных компиляторов, смотрите пример. Но это не меняет того факта что однопоточный рантайм для высоконагруженного серверного приложения — это просто не серьёзно.
TS — всё-таки это другой язык, не JavaScript. Да и Flow предполагает написания нотации типов для функций — необходимо их явно указывать. Это лучше чем ничего, согласен. Но есть реально классные компиляторы которые позволяют выводить типы для всех функций в программе без единой нотации типа. Вот пример простой программы на PureScript ( диалект Haskell компилируемый в JavaScript ), вот этот же код в работе. Код полностью типизированный и безопасный. Ни единой нотации типа в коде нет. Вот такая магия. В 2017 году многие компиляторы так умеют. Ещё раз спасибо за совет!
Однопоточность не решает проблемы race condition. Вот один из самых известных исторических фактов по этому вопросу.
Тут тоже не обошлось без корпораций конечно. Язык был создан компанией Ericsson в 1986 году, фирма продолжает и до сих пор вливать в него евро, недавно был релиз 20й версии. Изначально Erlang был создан под одну единственную задачу — написание ПО для маршрутизаторов ( этого же самого Ericsson ), в связи с этим там изначально отсутствовали некоторые казалось бы необходимые типы данных такие как например строки или maps, не было нормальных кастомных типов данных. Но со временем Erlang стал языком общего назначения на котором пишется почти всё что угодно. Используется по-прежнему в основном в телекоммуникациях / телефонии, очень хорош для высоконагруженных систем из-за простых и надёжных средств параллелизации ( которые кстати были ещё в первых версиях OTP середины 80х ). С приходом Elixir, платформа стала действительно популярной и на ней пишется буквально всё. Особый вклад в популяризацию Erlang / Elixir внёс фреймворк Phoenix — это новая рельса, без преувеличений.
А Автор Топика например делал soap клиент на java?(Про сервер-soap я вообще молчу)


Справедливости ради нужно сказать что мой главный промышленный язык это Erlang, с 2013 года Elixir. Формально это языки со слабыми типами, как и JS ( правда без неявных преобразований ) поэтому формально ответ — нет. На Erlang / Elixir код будет тоже более компактный по сравнению с Java. Но опять возвращаясь к слабым типам — в экосистеме Erlang / Elixir есть чудесные инструменты для статического анализа такие как Dialyzer и Xref. При правильном стиле написания кода ( тут ничего сложного нет ) эти инструменты выводят алгебраические типы для 100% функций и выражений в исходниках, буквально для каждой строчки и каждой буквы кода. То есть потенциальные проблемы с типами и просто опечатки видны ещё до запуска программы ( эти утилиты анализируют скомпилированный байткод ). В отсутствии подобных инструментов заключается один из главных минусов JS экосистемы.
Благодарю! В современном мире увы каждый разработчик соприкасается с JS хочет он того или нет — больше или меньше, но это явление есть. Порой когда обсуждаю с друзьями-разработчиками какую-нибудь современную технологию кажется что находишься в клубе анонимных алкоголиков — то есть все знают что такое JS, почему он плох, но по разным причинам каждый становится замешан в этой экосистеме, иногда так и кажется что кто-то скажет

— Привет, меня зовут Олег, и я иногда пишу на JS. Нет, вы не подумайте в основном я Scala разработчик, но вот иногда приходится и в npm полазить и для grunt с webpack скрипты написать. Кстати, я не писал на JS уже 2 недели
— Давайте похлопаем Олегу

:)
Могу предположить что использование JS фреймворков от фейсбука внутри самого фейсбука выглядит не так уж и страшно — из за высокого уровня культуры разработки, 100% покрытие юнит-тестами от и до. То есть они пишут инструмент для себя. Также возможно дело в средней цене за единицу времени js разработки / низком пороге входа — дешевле взять js джуна которых много, при необходимости обучить написанию тестов и дать ему таск чтобы он писал тесты и облазил в дебаггере код вдоль и поперёк пока всё не заработает как надо чем искать Scala / Java / Erlang / Elixir / Haskell / какого-то ещё разработчика.
Не истерика а набор фактов и вопрос «почему всё так?» к обсуждению
Mac mini чтоли скопировали? Ну только пластмассовый и без mac os x.
На рабочем компьютере Windows 10

Дальше можно было не продолжать :)
Компоненты React Native написаны на ObjC / Swift / Java, C++ тут ни при чём.
Уважаемый, React Native это не гибридная разработка, а нативная :)

Information

Rating
Does not participate
Location
Таллин, Эстония, Эстония
Registered
Activity