История изменений

7.6 если брать вариант как я сказал - включена по умолчанию.

Сама то возможность использования гораздо раньше была. Зачем вам «включена по умолчанию»? Если уж так, то и в Python asyncio в стандарте не так давно появился (3.7.х ветка, ЕМНИП). И это позже все равно NodeJS.

Фича была в первую очередь экспериментальной, т.к. не было понятно нужно ли (программистам на JS как правило асинхронщина понятно и они видят чаще мало смысла делать код плоским в ущерб производительности) и требовалась совместимость проработать с полифилами (внезапно, тонны софта и библиотек используют полифилы и сейчас, т.к. не любимые быдлокодерами колбеки в разы быстрее) и перенести часть кода с callbacks на promise.

Шикарнейшая вещь, которую с удовольствием внедрил бы всюду.

Вопрос, а зачем, какую проблему вы этим решите? В Python это внедрили, чтобы код для не программистов был более читаемый. Т.к. вложенность видна. Ну и плюс интерпретатор было проще написать таким образом. Остальное - вкусовщина и рассказы о том, что код стал более читаем - просто отмазка и показатель, что community и фанбои питона не способны запомнить style guide или использовать linter (что решает проблему соответствия стандартам). Ещё бы к IDE привязывали язык, чтобы писать можно было только на Х, а на всём остальном нет, чтобы еще и среду разработки не учить дополнительную. Ну бред жеж.

Ок, тернарники это синтаксический сахар заменяющий if

Любой ЯП - это синтаксический сахар над машкодами. Конструкции вводят в язык для получения определённых абстракций, которые дают ту или иную степень выразительности кода. Понятный для вашей текущей компетенции пример - вы можете сделать струнный инструмент с парой струн (Н.Паганини по легенде доказал, что можно и на одной струне сыграть) или дать их больше. Чем больше струн - тем больше возможностей. Но они не всегда нужны. Зачем вам 12 струн, если ваша задача сыграть «мурку» для «Михалыча»? Оно ему не нужно. Больше за это он не заплатит.

Вопрос в том, что там где Python востребован - возможности более сложных языков не нужны. Есть Х, который не способен понять ни один паттерн и REST сервис или скрипт для DevOps, который нужно получить не через день, а через пару часов. Если ему дать JS, TS, C# или не дай бог любое ФП - он не сделает. А вот с примитивным языком, где нет большого набора абстракций - задача будет решена. А когда надо будет внести сложный и новый функционал - дешевле переписать. Вот и получаем гору капрокода и капростартапов, которые будут вечно переписываться. Это не плохо, это модель разработки, которая имеет место быть и право на существование. И да, даже на примитивном языке можно сделать что-то стоящее и сложное, но на это уйдёт слишком много сил и времени. Будет идти борьба с интсрументом, а не с задачей. Sad but true.

Когда реально нужен вложенный тернарный оператор? Приведите пример, элементарно интересно, когда обязательно нужен он и нельзя/хуже будет использовать if блок.

Ок, для примера (была подобная вещь у меня в сервисе авторизации на NodeJS, который писали в рамках перехода на микросервисы с монологита).

У вас есть переменная, которая может быть пустой или заполненной, т.е. необходимо применить две стратегии. Стратегия 1: если переменная заполнена,надо плюнуть ошибкой вверх и асинхронно вызвать логирование (зачем дожидаться ответа от сервиса логирования - замедлит API), присвоить переменной null (ведь то, что у нас нет условий для поиска - не ошибка сервиса, а ошибка переданных данных и должна быть показана на клиенте). Если заполнена - вызывать запрос к БД, результат отфильтровать и вызвать N обработчиков (асинхронно, зачем нам разные поля JSON заполнять в синхронном режиме), для мутации данных и присвоить к переменной.

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

Да, код можно выделить в отдельные функции (это можно сделать всегда, даже если функция будет возвращать просто число), но в части случаев это не требуется (т.к. он не переиспользуется) и нагляднее будет оставить и его внутри lambda-функций тернарника.

Далее эта переменная используется где-то дальше.

И скатиться к жаве, с десятками классов на HelloWorld приложение?

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

Нет спасибо. В некоторых областях оно элементарно избыточно.

А я разве призываю использовать ООП везде? Можно пруф на это можно? Я говорю о том, что Python примитивен, но в части его областей применения не требуется что-то развитый язык, достаточно Python, т.к. применение нормального ЯП дорого. Ну не будем же мы для скриптов CI/CD использовать PureC или Java.

Но - я не отрицаю, что общие принципы оттуда знать надо.

Не то что надо, это необходимо. Иначе даже на Python rод будет полным говном, которое нельзя поддерживать. Просто Python-код будет проходить linter (т.е. минимальная читаемость всё же будет), но менее говном он от этого не станет.

Не совсем понял. Можно пример на том же яваскрипте?

Та любое frontend-приложение возьми на каком-нибудь ember. Или пример сервиса на moleculer. Конечно, если эти примеры по стандарту, а не костылями. Свой код, к сожалению, пока используются в production решения показать не смогу, т.к. комтайна.

Сильно изменится, очень сильно.

Ну синтаксис языка А отличается от синтаксиса языка В. Это нормально. Если есть понимание как работают даты и как они должны работать в виде прототипов - мало что изменится для вас.

Не совсем соглашусь с «хорошая стандартная библиотека» в жс

Почему же? Чего в стандартной библиотеки NodeJS вам не хватает?

но если в целом - именно современный JS в некоторых областях ничем не уступает, а то и превосходит питон.

Ну я это и сказал.

А можно чуть более подробно про нативную типизацию?

На сколько знаю, началось внедрение с типизированных массивов, как проверка «нужно ли» и развития идей Flow (который загнулся в итоге из-за TS). Начали обкатывать несколько вариантов статической типизации (от аннотаций как в TypeScript до гомункулов на основе JSDoc или WebAsm), пока смотрят как лучше реализовать, дабы не убить производительность. Пруфа к сожалению уже не найду, читал в обсуждении фич ES, которые принимали.

Все дело в том, что сейчас в JS можно писать декораторы и внедрена поддержка символов, по идее есть всё чтобы сделать Static Type Check и даже проверять его не как в TS при компиляции, но это скорее всего замедлит такой код. Поэтому в поисках вариантов.

А почему js нельзя назвать примитивным?

У него есть достаточно много уровней абстракций и свобода выбора в реализации, когда этого требует задача. Когда мне надо было написать сервис, который отдавался на поддержку студентам - я обмазал все async/await и максимально изолировал части через брокеры. Когда мне надо было сделать сервер для быстрой работы с изображениями (отдача пресетов, пережатие фоток, работа с CDN), который должен был выдерживать по 40к запросов в час минимум - то я сделал всё на основе cluster, ФП и callbacks, т.к. это давало меньше нагрузки и выше скорость работы. Когда мне в одной задаче на фронте понадобилось расширить объект стандартный для SPA я использовал proxy (таким образом не перебив стандартную библиотеку)… Примитивный язык заставляет вас придумывать абстракции для решения ваших задач (делаю некий микро-DSL-винегрет), а простой - обладает необходимыми абстракциями для решения задач на разных уровнях. Выбор же абстракций язык даёт возможность сделать на основе критериев задачи, а не на том, что язык Х не умеет так.

Я соглашусь, что чистое ФП, ООП, <имя_парадигмы> не нужны в прикладных задачах (чаще всего) и все языки в той или иной мере ограничивают программиста. Но, простые языки растут вместе с ним и дают под каждый уровень развития подходящие абстракции, а примитивные - заставляют писать велосипеды, чтобы реализовать те же абстракции.

7.6 если брать вариант как я сказал - включена по умолчанию.

Сама то возможность использования гораздо раньше была. Зачем вам «включена по умолчанию»? Если уж так, то и в Python asyncio в стандарте не так давно появился (3.7.х ветка, ЕМНИП). И это позже все равно NodeJS.

Фича была в первую очередь экспериментальной, т.к. не было понятно нужно ли (программистам на JS как правило асинхронщина понятно и они видят чаще мало смысла делать код плоским в ущерб производительности) и требовалась совместимость проработать с полифилами (внезапно, тонны софта и библиотек используют полифилы и сейчас, т.к. не любимые быдлокодерами колбеки в разы быстрее) и перенести часть кода с callbacks на promise.

Шикарнейшая вещь, которую с удовольствием внедрил бы всюду.

Вопрос, а зачем, какую проблему вы этим решите? В Python это внедрили, чтобы код для не программистов был более читаемый. Т.к. вложенность видна. Ну и плюс интерпретатор было проще написать таким образом. Остальное - вкусовщина и рассказы о том, что код стал более читаем - просто отмазка и показатель, что community и фанбои питона не способны запомнить style guide или написать linter (что решает проблему соответствия стандартам). Ещё бы к IDE привязывали язык, чтобы писать можно было только на Х, а на всём остальном нет, чтобы еще и среду разработки не учить дополнительную. Ну бред жеж.

Ок, тернарники это синтаксический сахар заменяющий if

Любой ЯП - это синтаксический сахар над машкодами. Конструкции вводят в язык для получения определённых абстракций, которые дают ту или иную степень выразительности кода. Понятный для вашей текущей компетенции пример - вы можете сделать струнный инструмент с парой струн (Н.Паганини по легенде доказал, что можно и на одной струне сыграть) или дать их больше. Чем больше струн - тем больше возможностей. Но они не всегда нужны. Зачем вам 12 струн, если ваша задача сыграть «мурку» для «Михалыча»? Оно ему не нужно. Больше за это он не заплатит.

Вопрос в том, что там где Python востребован - возможности более сложных языков не нужны. Есть Х, который не способен понять ни один паттерн и REST сервис или скрипт для DevOps, который нужно получить не через день, а через пару часов. Если ему дать JS, TS, C# или не дай бог любое ФП - он не сделает. А вот с примитивным языком, где нет большого набора абстракций - задача будет решена. А когда надо будет внести сложный и новый функционал - дешевле переписать. Вот и получаем гору капрокода и капростартапов, которые будут вечно переписываться. Это не плохо, это модель разработки, которая имеет место быть и право на существование. И да, даже на примитивном языке можно сделать что-то стоящее и сложное, но на это уйдёт слишком много сил и времени. Будет идти борьба с интсрументом, а не с задачей. Sad but true.

Когда реально нужен вложенный тернарный оператор? Приведите пример, элементарно интересно, когда обязательно нужен он и нельзя/хуже будет использовать if блок.

Ок, для примера (была подобная вещь у меня в сервисе авторизации на NodeJS, который писали в рамках перехода на микросервисы с монологита).

У вас есть переменная, которая может быть пустой или заполненной, т.е. необходимо применить две стратегии. Стратегия 1: если переменная заполнена,надо плюнуть ошибкой вверх и асинхронно вызвать логирование (зачем дожидаться ответа от сервиса логирования - замедлит API), присвоить переменной null (ведь то, что у нас нет условий для поиска - не ошибка сервиса, а ошибка переданных данных и должна быть показана на клиенте). Если заполнена - вызывать запрос к БД, результат отфильтровать и вызвать N обработчиков (асинхронно, зачем нам разные поля JSON заполнять в синхронном режиме), для мутации данных и присвоить к переменной.

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

Да, код можно выделить в отдельные функции (это можно сделать всегда, даже если функция будет возвращать просто число), но в части случаев это не требуется (т.к. он не переиспользуется) и нагляднее будет оставить и его внутри lambda-функций тернарника.

Далее эта переменная используется где-то дальше.

И скатиться к жаве, с десятками классов на HelloWorld приложение?

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

Нет спасибо. В некоторых областях оно элементарно избыточно.

А я разве призываю использовать ООП везде? Можно пруф на это можно? Я говорю о том, что Python примитивен, но в части его областей применения не требуется что-то развитый язык, достаточно Python, т.к. применение нормального ЯП дорого. Ну не будем же мы для скриптов CI/CD использовать PureC или Java.

Но - я не отрицаю, что общие принципы оттуда знать надо.

Не то что надо, это необходимо. Иначе даже на Python rод будет полным говном, которое нельзя поддерживать. Просто Python-код будет проходить linter (т.е. минимальная читаемость всё же будет), но менее говном он от этого не станет.

Не совсем понял. Можно пример на том же яваскрипте?

Та любое frontend-приложение возьми на каком-нибудь ember. Или пример сервиса на moleculer. Конечно, если эти примеры по стандарту, а не костылями. Свой код, к сожалению, пока используются в production решения показать не смогу, т.к. комтайна.

Сильно изменится, очень сильно.

Ну синтаксис языка А отличается от синтаксиса языка В. Это нормально. Если есть понимание как работают даты и как они должны работать в виде прототипов - мало что изменится для вас.

Не совсем соглашусь с «хорошая стандартная библиотека» в жс

Почему же? Чего в стандартной библиотеки NodeJS вам не хватает?

но если в целом - именно современный JS в некоторых областях ничем не уступает, а то и превосходит питон.

Ну я это и сказал.

А можно чуть более подробно про нативную типизацию?

На сколько знаю, началось внедрение с типизированных массивов, как проверка «нужно ли» и развития идей Flow (который загнулся в итоге из-за TS). Начали обкатывать несколько вариантов статической типизации (от аннотаций как в TypeScript до гомункулов на основе JSDoc или WebAsm), пока смотрят как лучше реализовать, дабы не убить производительность. Пруфа к сожалению уже не найду, читал в обсуждении фич ES, которые принимали.

Все дело в том, что сейчас в JS можно писать декораторы и внедрена поддержка символов, по идее есть всё чтобы сделать Static Type Check и даже проверять его не как в TS при компиляции, но это скорее всего замедлит такой код. Поэтому в поисках вариантов.

А почему js нельзя назвать примитивным?

У него есть достаточно много уровней абстракций и свобода выбора в реализации, когда этого требует задача. Когда мне надо было написать сервис, который отдавался на поддержку студентам - я обмазал все async/await и максимально изолировал части через брокеры. Когда мне надо было сделать сервер для быстрой работы с изображениями (отдача пресетов, пережатие фоток, работа с CDN), который должен был выдерживать по 40к запросов в час минимум - то я сделал всё на основе cluster, ФП и callbacks, т.к. это давало меньше нагрузки и выше скорость работы. Когда мне в одной задаче на фронте понадобилось расширить объект стандартный для SPA я использовал proxy (таким образом не перебив стандартную библиотеку)… Примитивный язык заставляет вас придумывать абстракции для решения ваших задач (делаю некий микро-DSL-винегрет), а простой - обладает необходимыми абстракциями для решения задач на разных уровнях. Выбор же абстракций язык даёт возможность сделать на основе критериев задачи, а не на том, что язык Х не умеет так.

Я соглашусь, что чистое ФП, ООП, <имя_парадигмы> не нужны в прикладных задачах (чаще всего) и все языки в той или иной мере ограничивают программиста. Но, простые языки растут вместе с ним и дают под каждый уровень развития подходящие абстракции, а примитивные - заставляют писать велосипеды, чтобы реализовать те же абстракции.