Проще писать небольшие программы на одну-две страницы с линейным графом исполнения. Это частый случай.
И, повторюсь, если динамическая типизация в этих языках намеренно, то почему все они начали обрастать статическими типами?
Потому, что в ИТ всё делается через (_|_). Вместо того, чтобы взять язык с подходящей под задачу типизацией, берутся дешёвые программисты «на языке А», которые не желают учиться, и упорно пишут на языке с динамической типизацией. Программы разрастаются, начинает требоваться стать. типизация, но переписывать уже поздно, поэтому начинаются вопли про стат. типизацию в языке.
Потому что для разных задач нужны разные инструменты?
Какую задачу решает динамическая типизация? И, повторюсь, если динамическая типизация в этих языках намеренно, то почему все они начали обрастать статическими типами?
Странная концепция, я понимаю, многие уверены, что существует только один расово верный.
Да, жаль, что не все поймут...
У вас аргументы кроме принципов Василия Алибабаевича имеются?
А какие тезисы мне следует подрепить аргументами? Не припомню, чтобы я какие-либо выдвигал, но, может, запамятовал.
Но по-факту, мы до сих пор широко пользуемся языками с динамической типизацией, хотя проверка и вывод типов — это вполне себе рутинная автоматизированная штука.
Всё так. Проверка и вывод типов — это вполне себе рутинная автоматизированная штука. На кой чёрт заставлять программистов писать эти типы, программируя на языках со статической типизацией, решительно не понятно, ведь всё можно рповерить и определить автоматически!
Потому что для разных задач нужны разные инструменты? Странная концепция, я понимаю, многие уверены, что существует только один расово верный.
начали добавлять типы
Если перечислять чего в истории ИТ сначала начали добавлять, потом перестали, потом начали убирать, получится труд размером с БСЭ, не меньше. У вас аргументы кроме принципов Василия Алибабаевича имеются?
Мне одного вечера джаваскрипта хватило чтобы сгореть, начать затаскивать типы и заворачивать на ревью код без них. Без типов я бы или уволился, или повесился
Пробежадться по всей кодовой базе и починить утечку ресурсов — никто нигде PrepareStatement не закрывал. Везде код разный, автозаменой Intellj IDEA или вимом это не решить (я сперва пытался, это невозможно)
Для этого уже давно есть статические анализаторы. В случае конкретно с Java: Checkstyle, PMD, FindBugs, Error Prone, дополнительные расширения и наборы правил к ним. Причём это будет работать на этапе сборки для даже без внешних систем вроде SonarQube. А при некотором должном усилии можно написать собственные проверки и правила для каждого из этих анализаторов.
А для всего, что касается проверки конфигурациионных файлов, можно написать собственные правила, например, для Maven Enforcer Plugin.
Ну вот пример из комментария, на который вы ответили. Перевод с одного ЯП на другой.
Еще пример. Пробежадться по всей кодовой базе и починить утечку ресурсов — никто нигде PrepareStatement не закрывал. Везде код разный, автозаменой Intellj IDEA или вимом это не решить (я сперва пытался, это невозможно). Но задача на 100% рутинная.
Еще пример. Тесты начали по-новому писать. Старые тесты переносить в новый формат (заполнять базу не кодом, а из файла) — можно LLM попросить, задача банальная и справится любой. А скриптом это не решить. На такой скрипт больше времени уйдет, чем на ручное переписывание всех тестов.
Вопрос откуда вообще берутся рутинные задачи. Программирование тем и отличается, что рутинные задачи автоматизируются и больше не появляются при правильном процессе.
Рутинный задачи и задачи по аналогии gpt3.5 решал хорошо.
Я очень удивился, когда дал chatGpt свой скрипт на Clojure, который писал около часа, используя свою же библиотеку, и он тут же перевел его на Bash без ошибок.
В 2022 (и в 2023) ChatGPT не мог решить ни один вопрос на среднем уровне. То, что вы им пользовались, даже несколько пугает. Разве не проще, быстрее и качественнее было сделать самому? Сейчас это уже не так, но это сейчас.
Блин, могут быть десятки причин. В данном случае я сам написал енам, продолжил писать, понял по ходу дела, что силд лучше подойдет. Но суть же в другом: бывает ясный рефакторинг, который нужно делать. LLM тут помогает сэкономить время и избавить от рутины.
Потому что после первого пенделя он благодарит за науку, увольняется и уходят туда, где используют не только пендели? Потому что запомнить с первого раза средний человек не способен, это исключение, а не норма.
Проще писать небольшие программы на одну-две страницы с линейным графом исполнения. Это частый случай.
Потому, что в ИТ всё делается через (_|_). Вместо того, чтобы взять язык с подходящей под задачу типизацией, берутся дешёвые программисты «на языке А», которые не желают учиться, и упорно пишут на языке с динамической типизацией. Программы разрастаются, начинает требоваться стать. типизация, но переписывать уже поздно, поэтому начинаются вопли про стат. типизацию в языке.
Какую задачу решает динамическая типизация? И, повторюсь, если динамическая типизация в этих языках намеренно, то почему все они начали обрастать статическими типами?
Да, жаль, что не все поймут...
А какие тезисы мне следует подрепить аргументами? Не припомню, чтобы я какие-либо выдвигал, но, может, запамятовал.
Всё так. Проверка и вывод типов — это вполне себе рутинная автоматизированная штука. На кой чёрт заставлять программистов писать эти типы, программируя на языках со статической типизацией, решительно не понятно, ведь всё можно рповерить и определить автоматически!
Вы не знаете, что такое вывод типов?
Речь о том, что не надо писать сигнатуры, примерно как вот тут:
https://github.com/ocaml/ocaml/blob/trunk/middle_end/closure/closure.ml
Вы не знаете, что языки с динамической типизацией существует вовсе не потому, что создатели не осилили статическую?
Потому что для разных задач нужны разные инструменты? Странная концепция, я понимаю, многие уверены, что существует только один расово верный.
Если перечислять чего в истории ИТ сначала начали добавлять, потом перестали, потом начали убирать, получится труд размером с БСЭ, не меньше. У вас аргументы кроме принципов Василия Алибабаевича имеются?
Сильная женщина..
Мне одного вечера джаваскрипта хватило чтобы сгореть, начать затаскивать типы и заворачивать на ревью код без них. Без типов я бы или уволился, или повесился
Одна моя знакомая в фаанге видит результаты этого пользования: каждый второй тип —
any.Не скажу за все языки, но, по ощущениям, в мире джаваскрипта подавляющее большинство уже давно тайпскриптом пользуется
Для этого уже давно есть статические анализаторы. В случае конкретно с Java: Checkstyle, PMD, FindBugs, Error Prone, дополнительные расширения и наборы правил к ним. Причём это будет работать на этапе сборки для даже без внешних систем вроде SonarQube. А при некотором должном усилии можно написать собственные проверки и правила для каждого из этих анализаторов.
А для всего, что касается проверки конфигурациионных файлов, можно написать собственные правила, например, для Maven Enforcer Plugin.
Ну вот пример из комментария, на который вы ответили. Перевод с одного ЯП на другой.
Еще пример. Пробежадться по всей кодовой базе и починить утечку ресурсов — никто нигде PrepareStatement не закрывал. Везде код разный, автозаменой Intellj IDEA или вимом это не решить (я сперва пытался, это невозможно). Но задача на 100% рутинная.
Еще пример. Тесты начали по-новому писать. Старые тесты переносить в новый формат (заполнять базу не кодом, а из файла) — можно LLM попросить, задача банальная и справится любой. А скриптом это не решить. На такой скрипт больше времени уйдет, чем на ручное переписывание всех тестов.
Вопрос откуда вообще берутся рутинные задачи. Программирование тем и отличается, что рутинные задачи автоматизируются и больше не появляются при правильном процессе.
Рутинный задачи и задачи по аналогии gpt3.5 решал хорошо.
Я очень удивился, когда дал chatGpt свой скрипт на Clojure, который писал около часа, используя свою же библиотеку, и он тут же перевел его на Bash без ошибок.
Скрип https://functional.works-hub.com/learn/writing-a-clojure-script-to-open-docker-and-two-terminal-windows-2befc
В 2022 (и в 2023) ChatGPT не мог решить ни один вопрос на среднем уровне. То, что вы им пользовались, даже несколько пугает. Разве не проще, быстрее и качественнее было сделать самому? Сейчас это уже не так, но это сейчас.
Уже сформированный программист также пользуется ИИ, но может утилизировать этот рычаг с большей эффективностью.
Утилизировать? Серьёзно? Вы русский после английского учили?
Спасибо, не знал.
Enum конвертируется в sealed class двумя кнопками в IntelliJ IDEA. Нейронка тут избыточна.
Блин, могут быть десятки причин. В данном случае я сам написал енам, продолжил писать, понял по ходу дела, что силд лучше подойдет. Но суть же в другом: бывает ясный рефакторинг, который нужно делать. LLM тут помогает сэкономить время и избавить от рутины.
А зачем вы переписываете enums на sealed classes? Если перечисления уже работают в проекте, зачем?
Потому что после первого пенделя он благодарит за науку, увольняется и уходят туда, где используют не только пендели? Потому что запомнить с первого раза средний человек не способен, это исключение, а не норма.