Для меня веб разработка, это любая серверная разработка, начиная от банальных сайтов и заканчивая теми же игровыми серверами или финтех решение, которое вы упомянули.
Видимо значение "веб разработки" с годами изменилось, потому что я из того, поколения, когда под вебом понималось далеко не только крудошлёпство. И имел ввиду, что к оффлайн приложениям термин хайлоад если и применяется то намного реже.
что же все-таки не так с ООП, если лично мне быстрее, проще и понятнее — реализовывать свои проекты на функциональном эликсире
И далее разговор о проблемах только ООП, и не слово о проблемах с аллокациями памяти и сборщиками мусора, работой с общими состояниями, тот же спагетти код с монадами в сложных проектах. Ваша статья воспринимается, как противопоставление ФП против ООП, даже если вы так не считаете.
Иными словами, в ООП нет ничего прям плохого, но только пока вы не погрузились в сильно связанный хайлоад.
Может вы и не работаете с вебом, но это была ваша претензия к ООП в контексте веба. Ведь термин хайлоад, чаще всего применяется в контексте работы с веб бэкендом.
Объектная модель всем хороша в однопоточной среде.
Что? На C#, Java, C++ например ООП нормально работает в многопоточности. Честно, дальше не читал, но судя по комментариям, там перлов много. Уже молчу, что по логике автора, те же проблемы могут возникать вполне себе и при ФП. Потому что конкурентоспособность никто не отменял и изменение одного и того же объекта может вызвать такие же проблемы.
Вообще, проблема многопоточности имеется в основном на web бэкенде. Изначально подразумевалось, что потоки должны быть изолированы и потом уже добавили возможность получать или изменять данные из одного потока в другом при помощи всяких invoke. Однако, на серверах может крутиться множество потоков, либо, как с node js, один основной поток и очереди на выполнение в нём кода. При этом все эти потоки по сути выполняют один и тот же код, с одними и теми же данными, что и является проблемой организации конкурентного доступа, а не парадигмы. В других многопоточных приложениях, обычно не такое большое количество потоков и важнее синхронизация данных между ними. Например, игра в которой game loop это один поток с рендером и логикой, звуки про омываются во втором потоке, ui например это третий поток. Пример стрёмный, но в контексте хороший. В такой игре мы имеем изолированные потоки, выполняющие разный код с разной бизнес логикой, их всего 3 и важна синхронизация данных между ними. А на бэкенде код и бизнес логика одна порой на сотни потоков, что приводит к другим проблемам.
Только не надо мне говорить, что качество промышленной продукции в СССР было гамном
А теперь будьте добры, показать где, я такое написал, это уже "борьба с соломенным чучелом".
Я говорил про то, что СССР понимал проблему бюрократии и то что IT может её решить. Вы сами пишите про какию-то бабку Маню с тётей Клавой, явно не представляя, как выглядит даже сейчас выглядит архивно-документационный отдел. Уж простите но тётя Клава в две руки не потянула бы документооборот и отчётность на заводе. Касаемо предоставленных вами данных, честно самому лень чекать, но GPT 4.5 с вами не совсем согласен.
Я удивился на этом моменте, когда у них на производстве в теории можно было прогонять через рабочее место одну и ту же деталь, а записывать, как несколько. Любой ОТК, подобные махинации очень быстро раскроет.
Папочки это прошлый век, можно сделать так же нормальный электронный документооборот и тех. процесс по отделам, чтобы можно было проследить например весь путь детали и где были проблемы.
Было всё тоже самое, но с огромным количеством бюрократии, которую сейчас можно заменить ERP (правда S3 и кубер имхо тут и правда немного лишние). СССР кстати, так же сильно развивал компьютеризацию, потому что это могло бы спасти страну от бюрократии, но до рассвета IT, не дожил.
Про объёмы производства, надо задавать вопросы не начальству и программистам, а тем-кто за 30 лет у власти сначала всё разрушил, а потом не смог или не хотел ничего восстанавливать. Вот сейчас во время войны, что-то впопыхах пытаются оживить.
Заграницей спад количества вакансий по ощущениям ещё больше.
То что, многие уехали из России после войны, на найм не сильно повлияло. Думаете заграницей так легко устроиться или перевезти туда свой бизнес? В части стран, даже имея внж не всегда оно даёт право на работу. Во многих странах ЕС например, работодатель должен доказать почему он берёт на работу иностранца, а не местного, у которого кроме визы ничего нет. Так что огромное количество программистов уехало забугор, но работает дальше в России.
Касаемо кризиса найма, то война конечно повлияла, но экономически, плюс лопнуло 2 пузыря за последние 3 года, это AI пузырь и пост ковидные сокращения бюджетов и темпов разработки. Отсюда и кризис по всему миру, а война это доп. условие для ухудшения просто.
Есть визуальное программирование, но что-то те, кто пытались на нём создавать большие проекты без единой строчки кода в текстовых файлах, не особо довольны таким экспириенсом)
Я скорее про то, что любой код нагенеренный нейронкой, будет лучше, чем большинство легаси кода, который писали люди лет 5-10 назад. Когда огромное количество программистов, брали кривые куски кода с форумов и пытались, как-то склеить из них проекты. Кстати генерировать нейронкой 500-1000 строк кода за раз такая себе идея. Нейронки вполне себе хорошо справляются с одной небольшой рутинной задачей, если предварительно описать что именно хочешь получить, но полностью вайбкодить это такое себе. Многое проще и быстрее сделать ручками, чем описывать нейронке, как и что пофиксить.
Если честно, править вайбкод всё-равно проще, потому что нейронка хоть стандартов придерживается и способна писать код, который в комментариях не нуждается, пусть и багованный.
А теперь расскажите, какой клиент/разработчик захочет общаться с нейросетью, касаемо проектов? Специальности, в которых требуется человеческое общение, будут заменены последними.
Представьте вы, директор какого-то предприятия, хотите найти ИТ компанию для создания, пусть будет CRM/ERP. Он заходит на сайт, оставляет заявку на promo call и ему вместо менеджера звонит ИИ Алиса... Через сколько наносекунд директор или допустим его подчинённый, которому он поручил найти подрядчика добавит эту компанию в свой ЧС?
Значит они нас засмеют) получается не важно что выбирать, засмеют в любом случае)))
Они вас не засмеют, скорее удивятся, потому отношение к фронтенд фреймворкам предвзятое из-за проблем с производительностью. Кстати, в комментариях так и произошло, что над авторами же никто не смеётся, а советуют более удобные инструменты для создания приложений)
О, Рад Студио теперь имеет бесплатную версию? Это очень любопытно. Как писал, могу ошибаться касаемо цен. Такой вопрос, а Рад Студио бесплатна только для Дельфи или есть бесплатная версия для С++? Просто я писал приложения только на С++ в ней ещё давно поскольку на Дельфи никогда не писал)
Если говорить про Рад Студио, то решения, что показал HemulGL можно и правда собрать быстро, потому что у Ембракадеро есть огромное количество готовых компонентов на все случаи жизни. Правда есть несколько минусов, удовольствие это не бесплатное (насколько помню, но может что-то поменялось) и готовые компоненты не всегда могут закрыть потребность в имеющимся дизайне, поэтому приходиться их переписывать.
Я бы посоветовал смотреть в сторону WPF, там xaml, тоже есть огромное количество компонентов, C# довольно простой в освоении ЯП и мне кажется любой фронтендер довольно быстро освоится в WPF, а главное всё бесплатно.
Я это называю "солидностью стека". Когда есть отличные инструменты для решения задач, но видите ли они не солидны и за них засмеют... И правда, кто засмеёт? Клиенты? Если им вечно не говорить, что солидно, а что нет, то им пофиг на техническую реализацию им важен функционал и поддержка. Большая часть энтерпрайза сидит на java erp/crm, состоящих целиком и полностью из легаси решений.
Засмеют другие программисты? Если программист смеётся над использованием релевантного стека, для быстрого и эффективного решения задачи, то стоит усомниться в его компетентности.
Причём, в контексте темы, это иронично слышать, учитывая отношение многих программистов, пишущих под desktop, к фронтенд фреймворкам.
Сильное заявление. Сейчас на том же WPF, можно собирать вполне себе красивые решения для бизнеса. Даже на древних, но быстрых вин формах можно, при помощи готовых компонентов, но это муторнее.
Есть QT, который позволяет тоже делать красоту для энтерпрайза. Если честно не понимаю зачем писать десктоп приложения на фронтенд фреймворках, которые всё-равно не будут настолько же быстро и эффективно работать, как приложения на C# и C++. Недавно была новость, что меню пуск в win11, написана на React Native, из-за чего в моменте открытия нагружает пк.
Для меня веб разработка, это любая серверная разработка, начиная от банальных сайтов и заканчивая теми же игровыми серверами или финтех решение, которое вы упомянули.
Видимо значение "веб разработки" с годами изменилось, потому что я из того, поколения, когда под вебом понималось далеко не только крудошлёпство. И имел ввиду, что к оффлайн приложениям термин хайлоад если и применяется то намного реже.
И далее разговор о проблемах только ООП, и не слово о проблемах с аллокациями памяти и сборщиками мусора, работой с общими состояниями, тот же спагетти код с монадами в сложных проектах. Ваша статья воспринимается, как противопоставление ФП против ООП, даже если вы так не считаете.
Может вы и не работаете с вебом, но это была ваша претензия к ООП в контексте веба. Ведь термин хайлоад, чаще всего применяется в контексте работы с веб бэкендом.
Что? На C#, Java, C++ например ООП нормально работает в многопоточности. Честно, дальше не читал, но судя по комментариям, там перлов много. Уже молчу, что по логике автора, те же проблемы могут возникать вполне себе и при ФП. Потому что конкурентоспособность никто не отменял и изменение одного и того же объекта может вызвать такие же проблемы.
Вообще, проблема многопоточности имеется в основном на web бэкенде. Изначально подразумевалось, что потоки должны быть изолированы и потом уже добавили возможность получать или изменять данные из одного потока в другом при помощи всяких invoke. Однако, на серверах может крутиться множество потоков, либо, как с node js, один основной поток и очереди на выполнение в нём кода. При этом все эти потоки по сути выполняют один и тот же код, с одними и теми же данными, что и является проблемой организации конкурентного доступа, а не парадигмы. В других многопоточных приложениях, обычно не такое большое количество потоков и важнее синхронизация данных между ними. Например, игра в которой game loop это один поток с рендером и логикой, звуки про омываются во втором потоке, ui например это третий поток. Пример стрёмный, но в контексте хороший. В такой игре мы имеем изолированные потоки, выполняющие разный код с разной бизнес логикой, их всего 3 и важна синхронизация данных между ними. А на бэкенде код и бизнес логика одна порой на сотни потоков, что приводит к другим проблемам.
А теперь будьте добры, показать где, я такое написал, это уже "борьба с соломенным чучелом".
Я говорил про то, что СССР понимал проблему бюрократии и то что IT может её решить. Вы сами пишите про какию-то бабку Маню с тётей Клавой, явно не представляя, как выглядит даже сейчас выглядит архивно-документационный отдел. Уж простите но тётя Клава в две руки не потянула бы документооборот и отчётность на заводе. Касаемо предоставленных вами данных, честно самому лень чекать, но GPT 4.5 с вами не совсем согласен.
Я удивился на этом моменте, когда у них на производстве в теории можно было прогонять через рабочее место одну и ту же деталь, а записывать, как несколько. Любой ОТК, подобные махинации очень быстро раскроет.
Папочки это прошлый век, можно сделать так же нормальный электронный документооборот и тех. процесс по отделам, чтобы можно было проследить например весь путь детали и где были проблемы.
Было всё тоже самое, но с огромным количеством бюрократии, которую сейчас можно заменить ERP (правда S3 и кубер имхо тут и правда немного лишние). СССР кстати, так же сильно развивал компьютеризацию, потому что это могло бы спасти страну от бюрократии, но до рассвета IT, не дожил.
Про объёмы производства, надо задавать вопросы не начальству и программистам, а тем-кто за 30 лет у власти сначала всё разрушил, а потом не смог или не хотел ничего восстанавливать. Вот сейчас во время войны, что-то впопыхах пытаются оживить.
Заграницей спад количества вакансий по ощущениям ещё больше.
То что, многие уехали из России после войны, на найм не сильно повлияло. Думаете заграницей так легко устроиться или перевезти туда свой бизнес? В части стран, даже имея внж не всегда оно даёт право на работу. Во многих странах ЕС например, работодатель должен доказать почему он берёт на работу иностранца, а не местного, у которого кроме визы ничего нет. Так что огромное количество программистов уехало забугор, но работает дальше в России.
Касаемо кризиса найма, то война конечно повлияла, но экономически, плюс лопнуло 2 пузыря за последние 3 года, это AI пузырь и пост ковидные сокращения бюджетов и темпов разработки. Отсюда и кризис по всему миру, а война это доп. условие для ухудшения просто.
Есть визуальное программирование, но что-то те, кто пытались на нём создавать большие проекты без единой строчки кода в текстовых файлах, не особо довольны таким экспириенсом)
Статья хорошая, но кому лень читать, советую сразу перейти в конец к Выводам. Там кратко написана база.
Если так будет. Интересно, попробовать пройти тест когда уже переехал забугор.)
Честно звучит, как не выдуманная история о которой невозможно молчать.
Я скорее про то, что любой код нагенеренный нейронкой, будет лучше, чем большинство легаси кода, который писали люди лет 5-10 назад. Когда огромное количество программистов, брали кривые куски кода с форумов и пытались, как-то склеить из них проекты. Кстати генерировать нейронкой 500-1000 строк кода за раз такая себе идея. Нейронки вполне себе хорошо справляются с одной небольшой рутинной задачей, если предварительно описать что именно хочешь получить, но полностью вайбкодить это такое себе. Многое проще и быстрее сделать ручками, чем описывать нейронке, как и что пофиксить.
Если честно, править вайбкод всё-равно проще, потому что нейронка хоть стандартов придерживается и способна писать код, который в комментариях не нуждается, пусть и багованный.
Давно писал, что следующей "революцией" будет подключение ИИ к условному Dreamweaver.
А теперь расскажите, какой клиент/разработчик захочет общаться с нейросетью, касаемо проектов? Специальности, в которых требуется человеческое общение, будут заменены последними.
Представьте вы, директор какого-то предприятия, хотите найти ИТ компанию для создания, пусть будет CRM/ERP. Он заходит на сайт, оставляет заявку на promo call и ему вместо менеджера звонит ИИ Алиса... Через сколько наносекунд директор или допустим его подчинённый, которому он поручил найти подрядчика добавит эту компанию в свой ЧС?
Они вас не засмеют, скорее удивятся, потому отношение к фронтенд фреймворкам предвзятое из-за проблем с производительностью. Кстати, в комментариях так и произошло, что над авторами же никто не смеётся, а советуют более удобные инструменты для создания приложений)
О, Рад Студио теперь имеет бесплатную версию? Это очень любопытно. Как писал, могу ошибаться касаемо цен. Такой вопрос, а Рад Студио бесплатна только для Дельфи или есть бесплатная версия для С++? Просто я писал приложения только на С++ в ней ещё давно поскольку на Дельфи никогда не писал)
Если говорить про Рад Студио, то решения, что показал HemulGL можно и правда собрать быстро, потому что у Ембракадеро есть огромное количество готовых компонентов на все случаи жизни. Правда есть несколько минусов, удовольствие это не бесплатное (насколько помню, но может что-то поменялось) и готовые компоненты не всегда могут закрыть потребность в имеющимся дизайне, поэтому приходиться их переписывать.
Я бы посоветовал смотреть в сторону WPF, там xaml, тоже есть огромное количество компонентов, C# довольно простой в освоении ЯП и мне кажется любой фронтендер довольно быстро освоится в WPF, а главное всё бесплатно.
Я это называю "солидностью стека". Когда есть отличные инструменты для решения задач, но видите ли они не солидны и за них засмеют... И правда, кто засмеёт? Клиенты? Если им вечно не говорить, что солидно, а что нет, то им пофиг на техническую реализацию им важен функционал и поддержка. Большая часть энтерпрайза сидит на java erp/crm, состоящих целиком и полностью из легаси решений.
Засмеют другие программисты? Если программист смеётся над использованием релевантного стека, для быстрого и эффективного решения задачи, то стоит усомниться в его компетентности.
Причём, в контексте темы, это иронично слышать, учитывая отношение многих программистов, пишущих под desktop, к фронтенд фреймворкам.
Сильное заявление. Сейчас на том же WPF, можно собирать вполне себе красивые решения для бизнеса. Даже на древних, но быстрых вин формах можно, при помощи готовых компонентов, но это муторнее.
Есть QT, который позволяет тоже делать красоту для энтерпрайза. Если честно не понимаю зачем писать десктоп приложения на фронтенд фреймворках, которые всё-равно не будут настолько же быстро и эффективно работать, как приложения на C# и C++. Недавно была новость, что меню пуск в win11, написана на React Native, из-за чего в моменте открытия нагружает пк.