Не буду дискутировать, и сразу соглашусь, что в Китае не социалистический строй. Но буду придерживаться официоза, что они сами утверждают, что Китай является социалистический государством, и Википедия придерживается того-же.
Да, вы правы. Изначально я задумал написать "современный капиталистический строй вообще не способен делать то, на что было способно советское социалистическое общество и капиталистическое общество шестидесятых".
Совершенно верно. Но в данной статье обсуждается принципиальная невозможность изготовить двигатели. Типа "мы могли бы изготовить по тем-же чертежам, но у нас не получается". То, что поставщика нет - это не вопрос технологической невозможности, а вопрос цены, жлобства и нежелания платить. Так мы договоримся до того, что мы не можем изготовить двигатели для пятерки, потому что не можем найти токарей, согласных за еду точить коленвалы.
Вообще, возникает крамольная мысль, что не можем повторить то, что делалось в шестидесятые не потому, что какие-то технические проблемы, а потому, что современный капиталистический строй вообще не способен делать то, на что было способно социалистическое общество.
Есть стандарты на материалы. Тысячи. И у всех материалов эти параметры прописаны. Прописаны, по крайней мере, состав сплавов. Какие проблемы выплавить медь с определенным составом? Физика и химия с даты последнего полета на Луну (если он конечно, был) не изменились.
В СССР никакой сертификации и прочей ахинеи типа ISO-9000 не было. Но ракеты летали. Потому что их принимали военпреды. Военпреды - это иногда такие доктора технических наук, только получившие образование в военных академиях (а почти все военные академии, сюрприз!!! выпускают технических (а также медиков и биологов) специалистов, только в отличии от пиджаков, умеющих командовать людьми). То, что на Ближнем Востоке ТАКИЕ военные - характеризует только Ближний Восток, и не показывает никакой важности сертификации.
Ну да, девяносто девять процентов не справятся с этим. И девяносто девять процентов не справятся с диагностикой рака. И девяносто девять процентов не справится с пилотированием самолета. И девяносто девять процентов не справится с обучением детей грамоте.
Странная статья вообще говоря. В ней делается открытие, что безграмотные и дураки не способны нарисовать или реализовать велосипед. Или паровоз. Или космическую ракету.
Велосипед я, инженер, нарисую по памяти. Со всеми трубками, втулками, подшипниками и прочими цепями. По крайней мере, фикс. С шимано, возможно, я намучаюсь. С обгонной муфтой у меня тоже будут затруднения. Но за месяц черчения я, уверен, справлюсь с обгонной втулкой. Почему? Да потому что я закончил УГТУ, и у меня была инженерная графика и проектирование механизмов.
Паровоз? Давайте чертежи. Никаких проблем не будет. Дорисую потом, чего не хватает. Паровоз, кстати, офигенная машина, я на Ютубе смотрел и был просто в восторге. Более тог, я читал сканы учебников по проектированию паровозов - все понятно было.
Для кого техника может быть магией? Для безграмотных и онлифанщиц? Для гуманитариев и юристов? Вот это открытие! И для медиков, и для учителей, и для поваров, тоже, и ничего тут зазорного нет.
Девяносто девять процентов людей не справятся с проектированием паровоза? Вот это открытие!
Проблема не в этом. Проблема в том, что не стало даже одного процента, которые способны спроектировать ракету.
Сначала загнали инженеров (и ученых) под плинтус, создав такое общество, в котором они получают меньше равшана-дворника, а потом "ай, а кто нам будет делать ракеты?!". Это и Россию и США касается.
В чем криминал наличия большого количества маленьких понятных функций, пусть даже и мало отличающихся друг от друга (почему это вообще должно парить?)?
В чем героизм наворотить систему, в которой даже сам автор через полгода не может разобраться, пусть даже (теоретически!) его поделие чуть короче?
Не надо в классы данных, описывающих какую-то сущность, вкладывать методы бизнес-логики. Класс сущности может быть один на всё приложение, а бизнес-логика может быть реализована в десятке классов-процессоров.
В этом случае, код
if (obj.State == 1) obj.UpdateState(2, 49.5);
может быть в десяти вариантах. Логика этого выражения ДОЛЖНА инкапсулироваться в классах-процессорах (алгоритмах) а не не в классе С.
Статья (источник) - чушь. Она опоздала как минимум, лет на пятнадцать. Полностью противоречит нынешним SOLID, и к примеру, SPRING, да и довольно старым уже "Паттернам проектирования".
Я к тому, что при АИ не будет необходимости напрягать извилины, чтобы развивать математику. Достаточно спрашивать у АИ. Профессия математика деградирует и станет неценной. Люди не станут заниматься математикой. Если общество не станет заниматься математикой, оно научно и технически деградирует.
Язык стабилизировался, перестал падать, разработчики освоили его, количество использующих его достигло насыщения, количество новых последователей и изучающих Го начало снижаться. Количество запросов снизилось.
Вы высказали феноменально важную мысль, которую Ферми не включал в свои рассуждения: конечность жизни цивилизации, крайне малое значение продолжительность жизни в галактических масштабах, огромные расстояния, огромный срок жизни вселенной и крайне малую скорость перемещения сигнала, не говоря уже о просто смехотворно малой скорости перемещения представителей цивилизации.
Короче, добавили конечность и фактор времени.
Мне кажется, вам имеет смысл доработать формулу Дрейка и публиковаться в научном журнале.
ПС. Дрейк ошибался, вообще говоря, считая, что после появления цивилизации она остается бессмертной. Это не более, чем шовинизм.
Программирование требуется всегда. Это заблуждение и маркетинговое вранье продаванов "нокод" систем, что вам не придется программировать. Для разработки, доработки, "конфигруции" и прочего допиливания всегда необходимо программирование. Программирование - суть появления софта.
Только вместо программирования на Java, Delphi, Шарпа, вы будете "программировать" на джейсоне, каких-то самопальных языках разметки, скриптовых общепринятых и самопальных скриптовых языках, типа одинэсной ахинеи.
В crud-операциях, как минимум, надо где-то описать модель базы данных, связи и прочее. Вместо java-кода, вам придется "программировать" на Json, или упаси боже, на xml. Аргумент, почему эти конфиги хуже простого кода на Java - в Spring ушли от конфигов на xml в сторону кода Java. И стало проще и читабельнее.
Ваш пример с конфигурацие хитрого уведомления - просто пример ужаса. Код Java, который будет решать данный функционал, будет проще и короче. Его можно будет отлаживать очень просто. Код на Java отлично автодополняется и проверяется компилятором. Вашу конфигурацию, чтобы проверить, что вы не наврали с синтаксисом, придется проверять запуском приложения и тычком на кнопку. При этом надо промудохаться с поднятием стенда. Да еще надо сформировать пример Customer-а, к примеру, чтобы добраться к нужному интерфейсу и функционалу. Чтобы удостовериться, что вы не написали ru.platform.Mail:sеndEmail (найдите здесь ошибку).
В реальности вся работа падает на группу разработчиков, потому что клиентам нахрен не уперлось разбираться в ваших правилах и синтаксисе конфигураций, им проще заплатить. Они не будут содержать спецов, которые должны уметь конфигурировать вашу систему, это дорого. Особенно, если нужно добавлять всякие provoteAction, которые приходится разрабатывать чуть реже, чем для каждого бизнес-кейса. И разработчики либо деградируют, "программируя" на конфигах и мучаясь с отладкой, либо увольняются с отличным резюме разработки "гибкой системы", в которой они-же не желают работать, либо сбрасывают эту работу на команды лохов из регионов, чтобы они деградировали.
https://ru.wikipedia.org/wiki/Государственный_строй_КНР
Не буду дискутировать, и сразу соглашусь, что в Китае не социалистический строй. Но буду придерживаться официоза, что они сами утверждают, что Китай является социалистический государством, и Википедия придерживается того-же.
Да, вы правы. Изначально я задумал написать "современный капиталистический строй вообще не способен делать то, на что было способно советское социалистическое общество и капиталистическое общество шестидесятых".
Прочитал "интегрировать".
Совершенно верно. Но в данной статье обсуждается принципиальная невозможность изготовить двигатели. Типа "мы могли бы изготовить по тем-же чертежам, но у нас не получается". То, что поставщика нет - это не вопрос технологической невозможности, а вопрос цены, жлобства и нежелания платить. Так мы договоримся до того, что мы не можем изготовить двигатели для пятерки, потому что не можем найти токарей, согласных за еду точить коленвалы.
Вообще, возникает крамольная мысль, что не можем повторить то, что делалось в шестидесятые не потому, что какие-то технические проблемы, а потому, что современный капиталистический строй вообще не способен делать то, на что было способно социалистическое общество.
Когнитивная нагрузка от десятка-сотни простых функций меньше, чем от одной сложной.
Есть стандарты на материалы. Тысячи. И у всех материалов эти параметры прописаны. Прописаны, по крайней мере, состав сплавов. Какие проблемы выплавить медь с определенным составом? Физика и химия с даты последнего полета на Луну (если он конечно, был) не изменились.
В СССР никакой сертификации и прочей ахинеи типа ISO-9000 не было. Но ракеты летали. Потому что их принимали военпреды. Военпреды - это иногда такие доктора технических наук, только получившие образование в военных академиях (а почти все военные академии, сюрприз!!! выпускают технических (а также медиков и биологов) специалистов, только в отличии от пиджаков, умеющих командовать людьми). То, что на Ближнем Востоке ТАКИЕ военные - характеризует только Ближний Восток, и не показывает никакой важности сертификации.
Простите, а что там за магические исходные материалы?
Ну да, девяносто девять процентов не справятся с этим. И девяносто девять процентов не справятся с диагностикой рака. И девяносто девять процентов не справится с пилотированием самолета. И девяносто девять процентов не справится с обучением детей грамоте.
Странная статья вообще говоря. В ней делается открытие, что безграмотные и дураки не способны нарисовать или реализовать велосипед. Или паровоз. Или космическую ракету.
Велосипед я, инженер, нарисую по памяти. Со всеми трубками, втулками, подшипниками и прочими цепями. По крайней мере, фикс. С шимано, возможно, я намучаюсь. С обгонной муфтой у меня тоже будут затруднения. Но за месяц черчения я, уверен, справлюсь с обгонной втулкой. Почему? Да потому что я закончил УГТУ, и у меня была инженерная графика и проектирование механизмов.
Паровоз? Давайте чертежи. Никаких проблем не будет. Дорисую потом, чего не хватает. Паровоз, кстати, офигенная машина, я на Ютубе смотрел и был просто в восторге. Более тог, я читал сканы учебников по проектированию паровозов - все понятно было.
Для кого техника может быть магией? Для безграмотных и онлифанщиц? Для гуманитариев и юристов? Вот это открытие! И для медиков, и для учителей, и для поваров, тоже, и ничего тут зазорного нет.
Девяносто девять процентов людей не справятся с проектированием паровоза? Вот это открытие!
Проблема не в этом. Проблема в том, что не стало даже одного процента, которые способны спроектировать ракету.
Сначала загнали инженеров (и ученых) под плинтус, создав такое общество, в котором они получают меньше равшана-дворника, а потом "ай, а кто нам будет делать ракеты?!". Это и Россию и США касается.
Спросить бы у спецов - тащить Kafka в стек для организации очередей (буфера) - это сложнее и хлопотнее, чем лепить очередь на Редисе?
Интересная мысль, что при вайбкодинге на AI, надо диктовать, чтобы разрабатывалась программа на Си.
В чем криминал наличия большого количества маленьких понятных функций, пусть даже и мало отличающихся друг от друга (почему это вообще должно парить?)?
В чем героизм наворотить систему, в которой даже сам автор через полгода не может разобраться, пусть даже (теоретически!) его поделие чуть короче?
Не надо в классы данных, описывающих какую-то сущность, вкладывать методы бизнес-логики. Класс сущности может быть один на всё приложение, а бизнес-логика может быть реализована в десятке классов-процессоров.
В этом случае, код
может быть в десяти вариантах. Логика этого выражения ДОЛЖНА инкапсулироваться в классах-процессорах (алгоритмах) а не не в классе С.
Статья (источник) - чушь. Она опоздала как минимум, лет на пятнадцать. Полностью противоречит нынешним SOLID, и к примеру, SPRING, да и довольно старым уже "Паттернам проектирования".
Я к тому, что при АИ не будет необходимости напрягать извилины, чтобы развивать математику. Достаточно спрашивать у АИ. Профессия математика деградирует и станет неценной. Люди не станут заниматься математикой. Если общество не станет заниматься математикой, оно научно и технически деградирует.
Это было описано в рассказе "Мешок знаний".
Если АИ научится решать математику, то это будет гибель математики как науки и гибель человечества как разумного вида.
Язык стабилизировался, перестал падать, разработчики освоили его, количество использующих его достигло насыщения, количество новых последователей и изучающих Го начало снижаться. Количество запросов снизилось.
Вывод: язык стал непопулярным.
Статья хорошая, только одно но. Это не ошибки, а халтура.
Вы высказали феноменально важную мысль, которую Ферми не включал в свои рассуждения: конечность жизни цивилизации, крайне малое значение продолжительность жизни в галактических масштабах, огромные расстояния, огромный срок жизни вселенной и крайне малую скорость перемещения сигнала, не говоря уже о просто смехотворно малой скорости перемещения представителей цивилизации.
Короче, добавили конечность и фактор времени.
Мне кажется, вам имеет смысл доработать формулу Дрейка и публиковаться в научном журнале.
ПС. Дрейк ошибался, вообще говоря, считая, что после появления цивилизации она остается бессмертной. Это не более, чем шовинизм.
Позволю себе еще раз повторить свою мысль.
Программирование требуется всегда. Это заблуждение и маркетинговое вранье продаванов "нокод" систем, что вам не придется программировать. Для разработки, доработки, "конфигруции" и прочего допиливания всегда необходимо программирование. Программирование - суть появления софта.
Только вместо программирования на Java, Delphi, Шарпа, вы будете "программировать" на джейсоне, каких-то самопальных языках разметки, скриптовых общепринятых и самопальных скриптовых языках, типа одинэсной ахинеи.
В crud-операциях, как минимум, надо где-то описать модель базы данных, связи и прочее. Вместо java-кода, вам придется "программировать" на Json, или упаси боже, на xml. Аргумент, почему эти конфиги хуже простого кода на Java - в Spring ушли от конфигов на xml в сторону кода Java. И стало проще и читабельнее.
Ваш пример с конфигурацие хитрого уведомления - просто пример ужаса. Код Java, который будет решать данный функционал, будет проще и короче. Его можно будет отлаживать очень просто. Код на Java отлично автодополняется и проверяется компилятором. Вашу конфигурацию, чтобы проверить, что вы не наврали с синтаксисом, придется проверять запуском приложения и тычком на кнопку. При этом надо промудохаться с поднятием стенда. Да еще надо сформировать пример Customer-а, к примеру, чтобы добраться к нужному интерфейсу и функционалу. Чтобы удостовериться, что вы не написали ru.platform.Mail:sеndEmail (найдите здесь ошибку).
В реальности вся работа падает на группу разработчиков, потому что клиентам нахрен не уперлось разбираться в ваших правилах и синтаксисе конфигураций, им проще заплатить. Они не будут содержать спецов, которые должны уметь конфигурировать вашу систему, это дорого. Особенно, если нужно добавлять всякие provoteAction, которые приходится разрабатывать чуть реже, чем для каждого бизнес-кейса. И разработчики либо деградируют, "программируя" на конфигах и мучаясь с отладкой, либо увольняются с отличным резюме разработки "гибкой системы", в которой они-же не желают работать, либо сбрасывают эту работу на команды лохов из регионов, чтобы они деградировали.
Поход на Москву - это чистой воды декабристы. Крайне далеки они от народа.