Ровно так же как все генералы готовятся к давно закончившейся войне, искусственные идиоты не могут выдать ничего сверх того, на чём были обучены. Бесконечный ремикс с фантазией на подмешанные из промпта токены — сколько угодно.
Вот только смысла сгенерированной ими же самими последовательности токенов они понимать не могут, и покуда не научатся, у кожаных есть преимущество. Ну а что касается этого самого понимания смысла, то у современных моделей его даже близко не просматривается. Это просто гигантские формулы с миллиардами коэффициентов. А формула, какой бы гигантской ни была, не может чего-то осознавать.
Ну как что. Софт просто развалится. Все эти «сопилоты» не видят общей картины, значит, через пару бездумных прогонов через них любая кодовая база превратится в месиво. А как тяжело заставить бредогенерилку исправить стиль отлично видно на этих примерах.
Ого, я даже угадал. Действительно, человеки обошлись с this/that ровно так, как в русском языке положено обходиться с английским указательным артиклем, а нейронки везде навтыкали мерзотный «этот».
(Дисклеймер: я почему-то не смог осилить «Дюну». Начинал читать в оригинале несколько раз, так до конца даже первой книги не дотянул, бесит она меня.)
Хммм... значит, LLM по какой-то причине очень любят оставлять в тексте английское this/that, и в переводе получаем сплошное «этот-этот-этот». Омерзительно.
Тоже верно. В зависимости от того, какой метод применялся для моделирования предметной области, получившаяся абстрактная модель может быть разной. (И если продукт в итоге не дошёл до релиза, значит, неправильный был выбран метод... :)
У молотка должен быть метод .удар(). А булевское свойство .забиваемость() у наследника класса Материал, из которого состоит экземпляр класса Поверхность (заданный оному через соответствующее свойство), в который экземпляр класса Гвоздь забивается методом .забить() экземпляром класса Плотник. Перед этим надо ещё координаты забивания указать, и выбрать конкретный молоток, потому что у плотника их несколько... И количество вызовов метода .удар() зависит как от нужной глубины забивания, так и от сопротивления материала.
А то ведь гвозди не сами себя забивают, и в металлический швеллер их тяжеловато будет вогнать.
Короче, сначала модель надо ещё как следует смоделировать.
Если понимать под «ООП» имплементацию с классами, то некоторые претензии можно принять. И то с натяжечкой, — если злоупотреблять концепциями ряди концепций, как это делают авторы некоторых фреймворков, код может превращаться в переусложнённое маловменяемое нечто. Но ведь и другие имплементации бывают. Прототипная, на локальных контекстах/лямбдах. В конце концов, даже на голом C можно писать во вполне себе объектном стиле.
И вообще, для гоняния туда-сюда сообщений между базой и юаем развитое ООП и в самом деле не особенно нужно (для логики вполне можно обойтись процедурным программированием, а DTO, которые не имеют собственных методов — это же просто структуры), но для написания некоторых классов приложений подход с классами может очень удобным.
Если пишешь интерпретатор или компилятор, например. Или когда твои абстрактные объекты точно моделируют объекты реального мира — причём не собачек или кошечек, а что-то на пару порядков посложнее. Или если есть необходимость в инверсии контроля и инжектах логики, что часто бывает в распределённом энтерпрайзе. Там, где всё действительно строится на интерфейсах, стратегиях, и фабриках, просто потому что код размазан между десятков сервисов, и логика приложения собирается в далёком рантайме.
Просто серебряных пуль и универсалий не существует, каждому классу задач — свой ограниченный набор инструментов. А ещё над методологией разработки нужно думать головой, а не тупо брать какой-то шаблон, потому что он популярный. Обзывать же что-то скамом только из-за того, что для вашей конкретной частной задачи оно плохо подошло — даже не глупость, а свинство.
Ну так развал СССР это ведь «крупнейшая геополитическая катастрофа XX века» по мнению Путина В.В. (см. «Обращение к Федеральному собранию» 2005 года).
Ну а коли президент так думает, значит, надо всеми силами восстанавливать совок. Значит, всё логично и правильно, точно в русле курса партии и правительства...
Чтобы заблокировать к чёртовой матери половину интернета, руководствуясь какими-то внутренними распоряжениями, им и так полномочий хватает. Куда больше-то?
Впрочем, даже сокрушаться на эту тему уже надоело. Вот прям щас они Cloudflare зарезали для большей части страны. Видимо, просто потому что могут.
Которые тоже дружно пойдут на рынок труда, как только маленькому проценту программистов станет невозможно заниматься разработкой. Вот только они что-то найдут, а мы вряд ли.
В моём 600-тысячном городе суммарный состав всех фирм, занимающихся IT как основной деятельностью (т.е. по первичному коду ОКВЭД — разработка ПО/БД, сопровождение (1С бухгалтерия), а также интернет-провайдеры, и т.п.), составляет 4100 человек. Это данные из официальных источников за 2023 год. Если добавить хотя бы айтишные подразделения местных заводов (их много, так как город промышленный), не говоря уже о других непрофильных отделах, то айтишников брутто наберётся даже поболее, чем 1% населения.
Сколько среди нас чистых программистов, не берусь экстраполировать. Но не так мало, как вам кажется. А уж тех, кто от нас зависит, и того больше. И вот прикинем, что средства разработки стали недоступными... Потому что они все нынче завязаны на интернет, а вендоры-то где? За бугром, конечно. (Как получаются отечественные «аналоговнеты», вы, надеюсь, понимаете.)
Те, кому зарубежный интернет не нужен для работы, могут и пойти делать какие-то дела. А вот те, кому он таки нужен, смогут пойти только на хрен. Без развлечений ещё как-то можно перекантоваться, а вот без работы что делать?
Но охранителям «суверенитета» на нас, по всей видимости, наплевать. И ещё хорошо, если просто наплевать...
Мде. 3.14дец, но что поделать. Увы, но со спарком такие фокусы это проза жизни. Местами он действительно плохо спроектирован, и проще заманкипатчить, чем пытаться расширить что-то официальным способом. Слишком многое в ядре (написанном на скале), помечено как @DeveloperApi, и даже в жабу не экспозится, и фиг ты что с этим сделаешь, если надо поменять.
А ишьи они по полгода рассматривают, даже если есть пулреквест, — а потом бот их закрывает, так как никто из разработчиков не изъявляет желания ревьюить чужие контрибы.
(Как бы преодолеть мне лень, чтобы написать таки статейку на тему «как я курочил спарк»... Хотя, после миграции на 3.4 большую часть подобного у меня получилось в своей кодовой базе или обойти или убрать. Но в одном месте всё равно до сих пор приходится в кишки залазить, хотя уже и без патчинга.)
Тормозной интерфейс и бесполезные свистелки можно перетерпеть, но падение любого приложения на основе Chromium / Electron через 6–7 дней использования — это уже выше моих сил. А ведь на них сейчас чуть ли не большая часть десктопного софта делается.
Рабочую машину я никогда не выключаю, а домашнюю отправляю в сон. Так вот, на десятке спокойно от одного ежемесячного patch tuesday до другого всё работает, а на 11 процесс рендерера рано или поздно аварийно завершается, и что браузер, что vscode какой-нибудь падает со всеми вкладками.
То есть, DWM в 11 течёт по памяти, и особенно сильно течёт после восстановления из гибернации. Багу эту я репортил несколько раз, но фиксить её, видимо, не собираются. И пока не пофиксят, буду оставаться на десятке...
Хмм... Любой уважающий себя Java-разработчик обязан написать как минимум 1 ORM/JDBC-коннектор, 1 контейнер/DI/AOP, 1 кодогенератор/интерпретатор/компилятор. А лучше 5. Это единственный нормальный путь становления сеньором — и других наверное, нет.
Если вам удалось в одном проекте покрыть сразу несколько перечисленных категорий, значит, вы всё делаете правильно, и станете хорошим Java-сеньором. А если у вас хватает наглости выложить его в паблик, и добавить в название true/ultimate, то вы имеете все шансы стать просто отличным Java-сеньором. Большинство почему-то стесняется :)
Но хватит похвалы. Подобного DO layers написано очень много — я лично штук 6 имплементаций видел, заточенных под конкретный проект, и сам как минимум три писал (ещё более специализированных). У всех один недостаток: если надо сделать шаг влево или вправо от видения автора, то сразу приплыли. Сколько ни думай головой, заранее всех кейсов не продумаешь.
Мне попадалась исследование по дохристианскому Риму — там также ~50% умирали до наступления совершеннолетия, а из оставшихся примерно треть могла дожить до 60 (если повезёт, и не будет эпидемий). Это, получается, общая норма доиндустриальной эпохи — то есть, людей как биологического вида в более-менее естественных условиях.
Ровно так же как все генералы готовятся к давно закончившейся войне, искусственные идиоты не могут выдать ничего сверх того, на чём были обучены. Бесконечный ремикс с фантазией на подмешанные из промпта токены — сколько угодно.
Вот только смысла сгенерированной ими же самими последовательности токенов они понимать не могут, и покуда не научатся, у кожаных есть преимущество. Ну а что касается этого самого понимания смысла, то у современных моделей его даже близко не просматривается. Это просто гигантские формулы с миллиардами коэффициентов. А формула, какой бы гигантской ни была, не может чего-то осознавать.
Ну как что. Софт просто развалится. Все эти «сопилоты» не видят общей картины, значит, через пару бездумных прогонов через них любая кодовая база превратится в месиво. А как тяжело заставить бредогенерилку исправить стиль отлично видно на этих примерах.
(Но всё равно хайп сдуется рано или поздно.)
Ого, я даже угадал. Действительно, человеки обошлись с this/that ровно так, как в русском языке положено обходиться с английским указательным артиклем, а нейронки везде навтыкали мерзотный «этот».
(Дисклеймер: я почему-то не смог осилить «Дюну». Начинал читать в оригинале несколько раз, так до конца даже первой книги не дотянул, бесит она меня.)
Хммм... значит, LLM по какой-то причине очень любят оставлять в тексте английское this/that, и в переводе получаем сплошное «этот-этот-этот». Омерзительно.
Тоже верно. В зависимости от того, какой метод применялся для моделирования предметной области, получившаяся абстрактная модель может быть разной. (И если продукт в итоге не дошёл до релиза, значит, неправильный был выбран метод... :)
Таки раскрылся. Правда, ещё больше 40 лет назад. За аппаратом всё это время таки наблюдали, известно точно.
У молотка должен быть метод .удар(). А булевское свойство .забиваемость() у наследника класса Материал, из которого состоит экземпляр класса Поверхность (заданный оному через соответствующее свойство), в который экземпляр класса Гвоздь забивается методом .забить() экземпляром класса Плотник. Перед этим надо ещё координаты забивания указать, и выбрать конкретный молоток, потому что у плотника их несколько... И количество вызовов метода .удар() зависит как от нужной глубины забивания, так и от сопротивления материала.
А то ведь гвозди не сами себя забивают, и в металлический швеллер их тяжеловато будет вогнать.
Короче, сначала модель надо ещё как следует смоделировать.
Если понимать под «ООП» имплементацию с классами, то некоторые претензии можно принять. И то с натяжечкой, — если злоупотреблять концепциями ряди концепций, как это делают авторы некоторых фреймворков, код может превращаться в переусложнённое маловменяемое нечто. Но ведь и другие имплементации бывают. Прототипная, на локальных контекстах/лямбдах. В конце концов, даже на голом C можно писать во вполне себе объектном стиле.
И вообще, для гоняния туда-сюда сообщений между базой и юаем развитое ООП и в самом деле не особенно нужно (для логики вполне можно обойтись процедурным программированием, а DTO, которые не имеют собственных методов — это же просто структуры), но для написания некоторых классов приложений подход с классами может очень удобным.
Если пишешь интерпретатор или компилятор, например. Или когда твои абстрактные объекты точно моделируют объекты реального мира — причём не собачек или кошечек, а что-то на пару порядков посложнее. Или если есть необходимость в инверсии контроля и инжектах логики, что часто бывает в распределённом энтерпрайзе. Там, где всё действительно строится на интерфейсах, стратегиях, и фабриках, просто потому что код размазан между десятков сервисов, и логика приложения собирается в далёком рантайме.
Просто серебряных пуль и универсалий не существует, каждому классу задач — свой ограниченный набор инструментов. А ещё над методологией разработки нужно думать головой, а не тупо брать какой-то шаблон, потому что он популярный. Обзывать же что-то скамом только из-за того, что для вашей конкретной частной задачи оно плохо подошло — даже не глупость, а свинство.
Ну так развал СССР это ведь «крупнейшая геополитическая катастрофа XX века» по мнению Путина В.В. (см. «Обращение к Федеральному собранию» 2005 года).
Ну а коли президент так думает, значит, надо всеми силами восстанавливать совок. Значит, всё логично и правильно, точно в русле курса партии и правительства...
Не сегодня, так завтра развернут на всю страну.
Ну, останутся разработчики без stackoverflow и docker, ну так и хер с ними... Хабр ведь не про разработку же.
Чтобы заблокировать к чёртовой матери половину интернета, руководствуясь какими-то внутренними распоряжениями, им и так полномочий хватает. Куда больше-то?
Впрочем, даже сокрушаться на эту тему уже надоело. Вот прям щас они Cloudflare зарезали для большей части страны. Видимо, просто потому что могут.
Которые тоже дружно пойдут на рынок труда, как только маленькому проценту программистов станет невозможно заниматься разработкой. Вот только они что-то найдут, а мы вряд ли.
А на чём сам 1С написан? Не на visual C++, часом? А СУБД какая штатно? Не PostgreSQL ли?
В моём 600-тысячном городе суммарный состав всех фирм, занимающихся IT как основной деятельностью (т.е. по первичному коду ОКВЭД — разработка ПО/БД, сопровождение
(1С бухгалтерия), а также интернет-провайдеры, и т.п.), составляет 4100 человек. Это данные из официальных источников за 2023 год. Если добавить хотя бы айтишные подразделения местных заводов (их много, так как город промышленный), не говоря уже о других непрофильных отделах, то айтишников брутто наберётся даже поболее, чем 1% населения.
Сколько среди нас чистых программистов, не берусь экстраполировать. Но не так мало, как вам кажется. А уж тех, кто от нас зависит, и того больше. И вот прикинем, что средства разработки стали недоступными... Потому что они все нынче завязаны на интернет, а вендоры-то где? За бугром, конечно. (Как получаются отечественные «аналоговнеты», вы, надеюсь, понимаете.)
Те, кому зарубежный интернет не нужен для работы, могут и пойти делать какие-то дела. А вот те, кому он таки нужен, смогут пойти только на хрен. Без развлечений ещё как-то можно перекантоваться, а вот без работы что делать?
Но охранителям «суверенитета» на нас, по всей видимости, наплевать. И ещё хорошо, если просто наплевать...
Мде. 3.14дец, но что поделать. Увы, но со спарком такие фокусы это проза жизни. Местами он действительно плохо спроектирован, и проще заманкипатчить, чем пытаться расширить что-то официальным способом. Слишком многое в ядре (написанном на скале), помечено как @DeveloperApi, и даже в жабу не экспозится, и фиг ты что с этим сделаешь, если надо поменять.
А ишьи они по полгода рассматривают, даже если есть пулреквест, — а потом бот их закрывает, так как никто из разработчиков не изъявляет желания ревьюить чужие контрибы.
(Как бы преодолеть мне лень, чтобы написать таки статейку на тему «как я курочил спарк»... Хотя, после миграции на 3.4 большую часть подобного у меня получилось в своей кодовой базе или обойти или убрать. Но в одном месте всё равно до сих пор приходится в кишки залазить, хотя уже и без патчинга.)
Тормозной интерфейс и бесполезные свистелки можно перетерпеть, но падение любого приложения на основе Chromium / Electron через 6–7 дней использования — это уже выше моих сил. А ведь на них сейчас чуть ли не большая часть десктопного софта делается.
Рабочую машину я никогда не выключаю, а домашнюю отправляю в сон. Так вот, на десятке спокойно от одного ежемесячного patch tuesday до другого всё работает, а на 11 процесс рендерера рано или поздно аварийно завершается, и что браузер, что vscode какой-нибудь падает со всеми вкладками.
То есть, DWM в 11 течёт по памяти, и особенно сильно течёт после восстановления из гибернации. Багу эту я репортил несколько раз, но фиксить её, видимо, не собираются. И пока не пофиксят, буду оставаться на десятке...
Оно редко за 2~3к строк вылазит, если только генератора триггеров или ещё какой-нибудь эзотерической фигни не требуется.
А на современной жабе с рекордами писать такое вообще считай читерство. Не нужно, как во времена 6, извращаться с рефлексией.
Хмм... Любой уважающий себя Java-разработчик обязан написать как минимум 1 ORM/JDBC-коннектор, 1 контейнер/DI/AOP, 1 кодогенератор/интерпретатор/компилятор. А лучше 5. Это единственный нормальный путь становления сеньором — и других наверное, нет.
Если вам удалось в одном проекте покрыть сразу несколько перечисленных категорий, значит, вы всё делаете правильно, и станете хорошим Java-сеньором. А если у вас хватает наглости выложить его в паблик, и добавить в название true/ultimate, то вы имеете все шансы стать просто отличным Java-сеньором. Большинство почему-то стесняется :)
Но хватит похвалы. Подобного DO layers написано очень много — я лично штук 6 имплементаций видел, заточенных под конкретный проект, и сам как минимум три писал (ещё более специализированных). У всех один недостаток: если надо сделать шаг влево или вправо от видения автора, то сразу приплыли. Сколько ни думай головой, заранее всех кейсов не продумаешь.
Но за выкладку в паблик зачёт, конечно.
Мне попадалась исследование по дохристианскому Риму — там также ~50% умирали до наступления совершеннолетия, а из оставшихся примерно треть могла дожить до 60 (если повезёт, и не будет эпидемий). Это, получается, общая норма доиндустриальной эпохи — то есть, людей как биологического вида в более-менее естественных условиях.