Редко, но метко: если рефакторить какую-то широко используемую сквозную функциональность в крупной кодобазе, то можно очень долго стабилизироваться уже лишь по причине лояльности JS к типам и количеству аргументов функций.
развитие HTML5 выбило все вышеперечисленные технологии
Выбивались они волевым решением хозяев платформ. Знаю истории про то, как конторы кастомили свои версии браузеров, для поддержки фронта на Flash.
HTML5 — это скорее консенсус-болеутоляющее, все проблемы это не решило. Потом история пошла по пути надстроек над JS: React/Angular/Vue и прочее.
WASM — эта технология, если судить по вакансиям, пока сильного распространения не получила
Незаметным ее существание тоже сложно назвать. Пусть пока это больше нишевой инструмент для числодробления. Но удочки в сторону фронта все чаще забрасываются как энтузиастами, так и крупными корпорациями.
Это альтернативная реализация все того же запроса, который никуда не пропадал.
"Паразитические" технологии или технологии надстройки — не новы.
Разве развитая экосистема костылей вокруг JS и веб-фронтенда в общем (Java Applets, Silverlight, Adobe Flash, теперь WASM-фреймворки) на протяжении всей истории не достаточно красноречиво говорит о наличии каких-то нерешенных проблем? Ведь эти "надстройки" никогда еще не умирали в пользу нативного JS, а всегда — в пользу других, более совершенных "надстроек". Под этим углом ситуация выглядит, как параллельные ветки развития: "технологии-надстройки" и целевой платформы, JS-рантайма.
он [TypeScript] является лишь технологической надстройкой и не умеет делать ничего такого, чего бы не умел делать JavaScript
JS не умеет самостоятельно статически контролировать контакты. Лопата умеет все то же, что экскаватор, но делает ли это ее ультимативным выбором?
Прямого такого требования нет. Судя по всему, упоминания client-side scanning появились при обсуждении реализации предложения, в контексте e2ee, как единственный разумный реалистичный способ делать проверку отправляемого контента. В частности, профильное ведомство (EU Data Protection Board and the European Data Protection Supervisor) выпустило отчет, в котором раскритиковало этот пропозал, в том числе упоминая этот интересный нюанс. И вроде бы даже не ставится вопрос о сканировании всей памяти устройства, лишь отправляемого контента.
Запрячь учеников, как команду, делать общий проект. По этой схеме уже работают "бесплатные стажировоки с гарантированным тродоустройством" современных галер. А здесь можно еще и деньги с курсантов брать.
вскоре позиции программистов-джунов теперь заменит этот чудо-сервис
Скорее не заменит, а необходимый скилл-сет джуна в очередной раз изменится. Уже лет 15 к ряду смеются над операторами SO. Сейчас информация станет (стала) еще доступнее: где раньше нужно было читать несколько постов SO на ангельском, теперь можно получить выжимку на родном-могучем. И это прекрасно, ведь хорошие специалисты будут созревать быстрее, а рутинные задачи будут эффективнее автоматизироваться, позволяя делать больше за то же время.
нужно пересмотреть планы преподавания, чтобы выпускать сразу мидлов.
Отличный маркетинговый лозунг, но, сдается мне, что за это чем-то придется жертвовать: размером программы или общим качеством. Голод индустрии GPT особо не заглушит, зато позволит инфоцыганам развернуться еще шире. Одни будут готовить "миддлов", другие — учить личной эффективности с чатом наперевес. Подобное мы уже переживали с датасаентистами за 3 месяца и зеро-кодерами.
Сомневаюсь, что нельзя обойтись без перезаписывания переменной. Если возврат — ранний return Collections.emptyList(), если добавляем в какую-то коллекцию List, то collection.add( Collections.emptyList()).
Мешать инлайнингу вызовов интерфейсами и параллельно рассуждать о производительности — это странно)
в java принято работать с максимально возможно узким типом
В Java принято контракты делать максимально гибкими, что логично. Делая то же самое для локальных переменных — это уже похоже культ карго.
как часто вы в повседневном коде используете методы, определённые для конкретной реализации общего интерфейса?
Как уже говорил выше, я всегда использую var, когда справа new и зачастую, когда справа метод с очевидным типом. То есть использую конкретные реализации.
Как я уже писал ранее такой код невалиден.
Можно написать new ArrayList<>() и код будет валиден. Мы же знаем тип, мы сами его тут создаем, к чему тут интерфейс?
Нет проблемы
Если "основные паттерны" не решают какие-либо проблемы, то это просто привычки.
Понял вас так: компилятор смотрит вниз по сценариям использования и выводит наименее общий тип, удовлетворяющий всем этим сценариям. То есть если тип объекта — ArrayList, а используется он лишь в рамках List, то выводится List. Это не выглядит очевидным.
под усложнением я имел ввиду именно понимание кода при чтении
Почему увидев varсложно понять, скажем, что тип переменной идентичен типу справа от new?
Вообще нет. Утверждение истинно только при условии, что эти переменные как минимум effective final.
Ну раскройте) Что им мешает быть мутабельными, если нам это необходимо?
Как часто вы использовали ArrayList#trimToSize(int) или ConcurrentHashMap.contains(Object)?
Не вижу особо проблем, кроме того, что второй метод задепрекейчен. Давайте сразу к сути проблемы, пожалуйста.
Приведите пример, а то звучит, как стандартный ответ религиозных фанатиков С)
В том, что не нужно тащить в голове весь багаж Rust
Эм… тащить? Либо владеете инструментом, либо нет. Когда его знаете — уже ничего за собой не тащите, это набор инструментов, облегчающих жизнь. Rust сложнее, чем C, но проще C++, при том обеспечивает некоторые преимущества.
можно сосредоточиться на предметной области
Можно сосредоточиться на рутине своего инструмента, вроде ручного управления памятью и отлаживания доступа к висячим указателям)
Размер багажа примерно определяется BNF языка плюс необходимых ей концептов.
С прост синтаксически, но концептов по борбе с отстреливанием ног в нем достаточно. И вот их как раз придется "тащить" в код каждый раз.
сказки про безопасность рассказывать не надо, это не подтверждается измерениями
Списки багов по текущей памяти, дата рейсам и уязвимостей через выход за границу буфера у различного софта более, чем красноречивы.
Редко, но метко: если рефакторить какую-то широко используемую сквозную функциональность в крупной кодобазе, то можно очень долго стабилизироваться уже лишь по причине лояльности JS к типам и количеству аргументов функций.
Наглядный аргумент против тех, кто говорит, что TS и JS — это один и тот же язык)
Моки просовывать жеж. Или тесты — тоже от лукавого?
Выбивались они волевым решением хозяев платформ. Знаю истории про то, как конторы кастомили свои версии браузеров, для поддержки фронта на Flash.
HTML5 — это скорее консенсус-болеутоляющее, все проблемы это не решило. Потом история пошла по пути надстроек над JS: React/Angular/Vue и прочее.
Незаметным ее существание тоже сложно назвать. Пусть пока это больше нишевой инструмент для числодробления. Но удочки в сторону фронта все чаще забрасываются как энтузиастами, так и крупными корпорациями.
Это альтернативная реализация все того же запроса, который никуда не пропадал.
О контрактах, пардон.
Разве развитая экосистема костылей вокруг JS и веб-фронтенда в общем (Java Applets, Silverlight, Adobe Flash, теперь WASM-фреймворки) на протяжении всей истории не достаточно красноречиво говорит о наличии каких-то нерешенных проблем? Ведь эти "надстройки" никогда еще не умирали в пользу нативного JS, а всегда — в пользу других, более совершенных "надстроек". Под этим углом ситуация выглядит, как параллельные ветки развития: "технологии-надстройки" и целевой платформы, JS-рантайма.
JS не умеет самостоятельно статически контролировать контакты. Лопата умеет все то же, что экскаватор, но делает ли это ее ультимативным выбором?
Зачем кивать на винды, где питона точно так же нет из коробки?)
Почти все то же самое можно сказать про C#, в частности:
Top-level statements, не нужно никаких
public static void Main.Командуем dotnet run и сразу из исходников запускается приложение, не требуя промежуточных дествий.
self-contained publishing. И в единый исполняемый файл собрать можно. Это все изкоробочными средствами.
Разве что скобки вместо отступов, но это уже на любителя (=
О, он вам еще и на лету выдумает парочку несуществующих библиотек, причем научит ими пользоваться) Был замечен за подобным.
Умножить количество ошибок компиляции на среднее минимальное время жизни тикета в баг-трекере.
Прямого такого требования нет. Судя по всему, упоминания client-side scanning появились при обсуждении реализации предложения, в контексте e2ee, как единственный
разумныйреалистичный способ делать проверку отправляемого контента. В частности, профильное ведомство (EU Data Protection Board and the European Data Protection Supervisor) выпустило отчет, в котором раскритиковало этот пропозал, в том числе упоминая этот интересный нюанс. И вроде бы даже не ставится вопрос о сканировании всей памяти устройства, лишь отправляемого контента.Запрячь учеников, как команду, делать общий проект. По этой схеме уже работают "бесплатные стажировоки с гарантированным тродоустройством" современных галер. А здесь можно еще и деньги с курсантов брать.
Скорее не заменит, а необходимый скилл-сет джуна в очередной раз изменится. Уже лет 15 к ряду смеются над операторами SO. Сейчас информация станет (стала) еще доступнее: где раньше нужно было читать несколько постов SO на ангельском, теперь можно получить выжимку на родном-могучем. И это прекрасно, ведь хорошие специалисты будут созревать быстрее, а рутинные задачи будут эффективнее автоматизироваться, позволяя делать больше за то же время.
Отличный маркетинговый лозунг, но, сдается мне, что за это чем-то придется жертвовать: размером программы или общим качеством. Голод индустрии GPT особо не заглушит, зато позволит инфоцыганам развернуться еще шире. Одни будут готовить "миддлов", другие — учить личной эффективности с чатом наперевес. Подобное мы уже переживали с датасаентистами за 3 месяца и зеро-кодерами.
Не рассматривали Yarn Workspaces?
Непонятно лишь, как игнорировать код, который нужно поддерживать.
Нет, подсветите разницу.
Сомневаюсь, что нельзя обойтись без перезаписывания переменной. Если возврат — ранний
return Collections.emptyList(), если добавляем в какую-то коллекциюList, тоcollection.add( Collections.emptyList()).Мешать инлайнингу вызовов интерфейсами и параллельно рассуждать о производительности — это странно)
В Java принято контракты делать максимально гибкими, что логично. Делая то же самое для локальных переменных — это уже похоже культ карго.
Как уже говорил выше, я всегда использую
var, когда справаnewи зачастую, когда справа метод с очевидным типом. То есть использую конкретные реализации.Можно написать
new ArrayList<>()и код будет валиден. Мы же знаем тип, мы сами его тут создаем, к чему тут интерфейс?Если "основные паттерны" не решают какие-либо проблемы, то это просто привычки.
Скорее бэкенд вообще, как Java.
Понял вас так: компилятор смотрит вниз по сценариям использования и выводит наименее общий тип, удовлетворяющий всем этим сценариям. То есть если тип объекта — ArrayList, а используется он лишь в рамках List, то выводится List. Это не выглядит очевидным.
Почему увидев
varсложно понять, скажем, что тип переменной идентичен типу справа отnew?Ну раскройте) Что им мешает быть мутабельными, если нам это необходимо?
Не вижу особо проблем, кроме того, что второй метод задепрекейчен. Давайте сразу к сути проблемы, пожалуйста.
Разумеется) Речь была о том, что не мгновенный набор популярности языка зависит не только от самого языка.
Приведите пример, а то звучит, как стандартный ответ религиозных фанатиков С)
Эм… тащить? Либо владеете инструментом, либо нет. Когда его знаете — уже ничего за собой не тащите, это набор инструментов, облегчающих жизнь. Rust сложнее, чем C, но проще C++, при том обеспечивает некоторые преимущества.
Можно сосредоточиться на рутине своего инструмента, вроде ручного управления памятью и отлаживания доступа к висячим указателям)
С прост синтаксически, но концептов по борбе с отстреливанием ног в нем достаточно. И вот их как раз придется "тащить" в код каждый раз.
Списки багов по текущей памяти, дата рейсам и уязвимостей через выход за границу буфера у различного софта более, чем красноречивы.