Я так понимаю, предыдущая версия тирьямпампации не может объяснить черные дыры, пришлось новую, супертирьямпампацию выдумывать? Если серьезно, никаких ни доказательств, ни наблюдений нет, это чисто измышления теоретиков, которые выдаются за открытия Уэбба.
Как описывается маппинг от таблицы/запроса к полям dto (бизнес-объекта)? С условием, что dto нельзя засирать аннотациями? Имеется отдельный слой persistence, в методы которого входят/выходят dto.
Фиг знает. У меня есть подозрение, что животные (в частности кошки) умеют общаться с помощью мыслей. А человек эту способность потерял ввиду появления второй сигнальной системы.
Пока решения раба адекватны окружающей действительности, раб делает все правильно. Если раб говорит, что надо вкладываться в акции А, и они через неделю растут - значит, раб предлагает правильные решения.
Имхо, вся проблема в идее "саморегулирующего" сообщества. Нельзя давать читателям влиять на жизнь писателей явно. Возможность НЕ ЧИТАТЬ - должна быть. Возможность сделать так, чтобы автор НЕ ПИСАЛ - такого быть не должно.
А вообще есть в принципе возможность построения саморегулируемого сообщества? Что это вообще такое: "саморегулируемое сообщество"? Откуда эта идея вообще взялась про "саморегулируемое" сообщество? Есть хоть один пример в жизни реализации "саморегулируемого" сообщества? В жизни, в реале. На примере какой-то общины, государства, города и так далее.
Можно в Java писать в стиле Clojure. Максимально функционально. Максимально Streams, когда они нафиг не нужны - циклы, условия, обработка null. Можно наворачивать вызовы функций друг в друга, крайне желательно с лямбдами. При этом используя стохастическое форматирование. Огромные методы без единой переменной. Создается адовая матрешка, кочан вызовов, на разбор которого можно тратить целые часы. Что вызывается, в каком порядке? Какие данные передаются в вызовы, что возвращается? Невозможно понять ни чтением, ни дебаггингом, потому что идея при включении показа возвращаемого значения начинает тупить, а по f7 внутрь лямбд она не заходит.
Все робкие протесты против такого стиля программирования убиваются простейшим "Ты просто плохо разбираешься в стримах и функциональном программирование. Тебе надо расти и много упражняться. Ты не готов стать сеньором.".
Попробуйте провести мысленный эксперимент (такой кубизм в ИИ есть). Есть база картин с пейзажами. База с кубизмами нет. Про кубизм вы даже не подозреваете. Какой запрос типа "придумай новое" нужно задать чату, чтобы он придумал кубизм.
Причем, запросы типа "пейзаж, но чтобы элементы пейзажа "рисовались" кубиками" не пойдет - это будет ВАША новизна.
Есть мнение, что ни по запросу "придумай новое", ни по запросу "пейзаж, но элементы кубиками и линиями" - чат не осилит.
Да, вы сделали НАПИСАНИЕ проще. Ну молодец. Облегчили себе жизнь. А какая когнитивная нагрузка ляжет на тех, кто будет поддерживать и дебажить ваш код, подумали? И первый же вопрос для размышления - как будет реагировать ваш метод, если передать ему строку и число? А если массив и число? А картинку и число? И будет ли работать? Придется читать доки, лепить пробы. И каждый новый программист будет натыкаться на эти вопросы, натыкаться и натыкаться. На сколько человеко-часов вы ограбили свою контору этой "простотой"? "Может свалиться на проде". Я угораю. Во сколько человеко-часов и тысяч (миллионов) рублей выльется ваша "простота"?
Код не должен быть "простым". Он должен нести минимальную когнитивную нагрузку на тех, кто его читает и поддерживает.
Согласно теории информации, никакая программа (а любой ИИ это всего лишь программа), неспособна извлечь больше информации, чем в нее подали. Количество информации после обработки любой программой может только уменьшаться. Вот как обучили ИИ огромным массивом информации - то мы от него и получим.
Собственно, именно об этом и говорит Маск в вашей ссылке. Количество информации, которое закладывают в ИИ, ограничено, и эта информация подходит к концу.
Статическую типизацию для того и делали, чтобы в методе не было ахинеи типа "23" + 10. Здесь половина кода не логика приложения, а разбирательство, к какому типу будет приводится это выражение в данном языке - к строке или к числу. Это придется программисту помнить (и уметь про это отвечать на собесах).
Метод с логикой приложения, это:
int add(string v1, int v2) {
int p1 = cast v1 as int;
int r = p1 + v2;
return r;
}
Но лучше
int add(int v1, int v1) {
return v1 + v2;
}
...
r = add(cast "32" as int, 10);
Зачем привлекать гены для объяснения падения технологии? Найдите статистику запусков ракет в СССР и РФ и посмотрите на падение количества. Чьи гены в этом виноваты?
Нам надо, чтобы имея dto - классы объектов, и таблицы базы данных, сохранять и доставать в/из базы одним вызовом. При этом dto не должно обременяться барахлом из ОРМ, то есть, детали реализации persistence не должны вылезать дальше слоя persistence. При этом dto и таблицы базы могут различаться, иногда весьма значительно (диктуются деталями реализации хранения в базе). Какая еще генерация?
Кроме того, надо реализовать множество срезов таблицы, когда в dto должно попадать только часть полей исходной таблицы (по требованиям производительности). А еще надо сохранять отдельные поля. Много и часто.
Хибернат при таких условиях - тяжкие гири, потому что приходится воротить классы entity, трансляцию dto в entity и обратно, сохранение отдельных полей в виде достать объект - изменить поле - сохранить объект.
Интерес представлял Spring Data JDBC. Вектор отличный. Но и он недостаточно хорош, потому что детали реализации persistence лезут в бизнес-слои в виде необходимости классы dto загрязнять @Entityи @FifthColumn
В связи с этим материал автора представляет большой интерес, но нужно больше информации. Как задается dto в persistence, где указывается соответствие полей dto полям таблиц? Для нас размещение такой информации в базе и генерация по ней кода неприемлемо, потому что необходимо менять слой persistence от базы к базе и даже к nosql, при этом требуется, чтобы слои бизнеса не менялись.
Я так понимаю, предыдущая версия тирьямпампации не может объяснить черные дыры, пришлось новую, супертирьямпампацию выдумывать? Если серьезно, никаких ни доказательств, ни наблюдений нет, это чисто измышления теоретиков, которые выдаются за открытия Уэбба.
Как описывается маппинг от таблицы/запроса к полям dto (бизнес-объекта)? С условием, что dto нельзя засирать аннотациями? Имеется отдельный слой persistence, в методы которого входят/выходят dto.
Первая атомная электростанция была запущена в середине прошлого века, напомню.
Фиг знает. У меня есть подозрение, что животные (в частности кошки) умеют общаться с помощью мыслей. А человек эту способность потерял ввиду появления второй сигнальной системы.
О мертвых - либо хорошо, либо ничего (кроме правды!).
Hibernat, кстати, тоже дрянь аналогично ломбоку. Присматриваюсь к SpringDataJDBC, и в нем, между прочим, рекорды использовать можно.
Практика - критерий истины.
Пока решения раба адекватны окружающей действительности, раб делает все правильно. Если раб говорит, что надо вкладываться в акции А, и они через неделю растут - значит, раб предлагает правильные решения.
Можно уточнить, 70% редкоземельных металлов ДОБЫВАЮТСЯ в Китае, или находятся в РЗВЕДАННЫХ месторождениях?
Даже то, что это находится в разведанных месторождениях, мало что означает - будет необходимость, пошарят по земному шарику и, уверен, найдут.
Имхо, вся проблема в идее "саморегулирующего" сообщества. Нельзя давать читателям влиять на жизнь писателей явно. Возможность НЕ ЧИТАТЬ - должна быть. Возможность сделать так, чтобы автор НЕ ПИСАЛ - такого быть не должно.
А вообще есть в принципе возможность построения саморегулируемого сообщества? Что это вообще такое: "саморегулируемое сообщество"? Откуда эта идея вообще взялась про "саморегулируемое" сообщество? Есть хоть один пример в жизни реализации "саморегулируемого" сообщества? В жизни, в реале. На примере какой-то общины, государства, города и так далее.
Минусы на пикабу убрали ровно потому-же, почему система минусов и кармы убивает Хабр.
Добавлю по языкам.
Можно в Java писать в стиле Clojure. Максимально функционально. Максимально Streams, когда они нафиг не нужны - циклы, условия, обработка null. Можно наворачивать вызовы функций друг в друга, крайне желательно с лямбдами. При этом используя стохастическое форматирование. Огромные методы без единой переменной. Создается адовая матрешка, кочан вызовов, на разбор которого можно тратить целые часы. Что вызывается, в каком порядке? Какие данные передаются в вызовы, что возвращается? Невозможно понять ни чтением, ни дебаггингом, потому что идея при включении показа возвращаемого значения начинает тупить, а по f7 внутрь лямбд она не заходит.
Все робкие протесты против такого стиля программирования убиваются простейшим "Ты просто плохо разбираешься в стримах и функциональном программирование. Тебе надо расти и много упражняться. Ты не готов стать сеньором.".
Попробуйте провести мысленный эксперимент (такой кубизм в ИИ есть). Есть база картин с пейзажами. База с кубизмами нет. Про кубизм вы даже не подозреваете. Какой запрос типа "придумай новое" нужно задать чату, чтобы он придумал кубизм.
Причем, запросы типа "пейзаж, но чтобы элементы пейзажа "рисовались" кубиками" не пойдет - это будет ВАША новизна.
Есть мнение, что ни по запросу "придумай новое", ни по запросу "пейзаж, но элементы кубиками и линиями" - чат не осилит.
Да, вы сделали НАПИСАНИЕ проще. Ну молодец. Облегчили себе жизнь. А какая когнитивная нагрузка ляжет на тех, кто будет поддерживать и дебажить ваш код, подумали? И первый же вопрос для размышления - как будет реагировать ваш метод, если передать ему строку и число? А если массив и число? А картинку и число? И будет ли работать? Придется читать доки, лепить пробы. И каждый новый программист будет натыкаться на эти вопросы, натыкаться и натыкаться. На сколько человеко-часов вы ограбили свою контору этой "простотой"? "Может свалиться на проде". Я угораю. Во сколько человеко-часов и тысяч (миллионов) рублей выльется ваша "простота"?
Код не должен быть "простым". Он должен нести минимальную когнитивную нагрузку на тех, кто его читает и поддерживает.
В том, что ИИ не способен к созданию нового.
Согласно теории информации, никакая программа (а любой ИИ это всего лишь программа), неспособна извлечь больше информации, чем в нее подали. Количество информации после обработки любой программой может только уменьшаться. Вот как обучили ИИ огромным массивом информации - то мы от него и получим.
Собственно, именно об этом и говорит Маск в вашей ссылке. Количество информации, которое закладывают в ИИ, ограничено, и эта информация подходит к концу.
Статическую типизацию для того и делали, чтобы в методе не было ахинеи типа "23" + 10. Здесь половина кода не логика приложения, а разбирательство, к какому типу будет приводится это выражение в данном языке - к строке или к числу. Это придется программисту помнить (и уметь про это отвечать на собесах).
Метод с логикой приложения, это:
Но лучше
Зачем привлекать гены для объяснения падения технологии? Найдите статистику запусков ракет в СССР и РФ и посмотрите на падение количества. Чьи гены в этом виноваты?
Цивилизация крайне хрупкая вещь.
Нам надо, чтобы имея dto - классы объектов, и таблицы базы данных, сохранять и доставать в/из базы одним вызовом. При этом dto не должно обременяться барахлом из ОРМ, то есть, детали реализации persistence не должны вылезать дальше слоя persistence. При этом dto и таблицы базы могут различаться, иногда весьма значительно (диктуются деталями реализации хранения в базе). Какая еще генерация?
Кроме того, надо реализовать множество срезов таблицы, когда в dto должно попадать только часть полей исходной таблицы (по требованиям производительности). А еще надо сохранять отдельные поля. Много и часто.
Хибернат при таких условиях - тяжкие гири, потому что приходится воротить классы entity, трансляцию dto в entity и обратно, сохранение отдельных полей в виде достать объект - изменить поле - сохранить объект.
Интерес представлял Spring Data JDBC. Вектор отличный. Но и он недостаточно хорош, потому что детали реализации persistence лезут в бизнес-слои в виде необходимости классы dto загрязнять @Entityи @FifthColumn
В связи с этим материал автора представляет большой интерес, но нужно больше информации. Как задается dto в persistence, где указывается соответствие полей dto полям таблиц? Для нас размещение такой информации в базе и генерация по ней кода неприемлемо, потому что необходимо менять слой persistence от базы к базе и даже к nosql, при этом требуется, чтобы слои бизнеса не менялись.
Результат ложится в обычный класс, или record? Нет необходимости в классах данных указывать @Entity, @Table, @Column?
Вот почему так-же нет в Java?! Один файл подправил - две трети файлов в проекте перекомпилируются.