Почему ООП умирает | Стрим про языки программирования с
Вставка
- Опубліковано 26 вер 2024
- Говорим с demimurych про парадигмы программирования, про Javascript и про умирающий ООП.
Ваши вопросы в эфире/Донат: www.donational...
Поддержать канал/задать вопросы/смотреть видео сразу: boosty.to/dece...
Вконтактик: decembr...
Телеграм новости/мемы: t.me/decembristit
Телеграм чат: t.me/Decembris...
Инстаграм: / nevornevor
Зашёл на видео думал так минуток 15 послушаю перед снов, в итоге не заметил как досмотрел до конца.
Гостя слушать одно удовольствие, будет круто, если встретитесь ещё!)
А мне понравился гость, ему бы подкасты вести на такие философско-технические темы, это прям его стезя.
Для философии гость мыслит очень узко и однобоко, только как хакер-реверс-инженер, а выскочить из этой скорлупы не может и даже не понимает зачем это нужно.
@@bulsond Может, понимает и если ему 20 минут дать в воздухе повитать у него философия начнет бить из головы. Философия это стиль, а не конкретное занятие. Не всем дано - ему дано.
@@bulsond А разве философы когда то понимали зачем им это нужно ? ))) Впрочем придирки к гостю излишни. по существу он прав.
@@ZhigDenis >> А разве философы когда то понимали зачем им это нужно ?
Разьве это не центральная задача философии любого течения и направления? Поиск максимально фундаментальной базы для причинно следственных построений, и суждений?
@@MetaJamm Нет и никогда не была. Там где один философ выстроит базу, другой не менее весомо ее опровергнет и построит новую. В том и суть что философия не наука и не математика, и многие ее выводы притянуты за уши и крайне сильно намешаны с элементарной софистикой ...
Пока вы там думали что круче js или java. Навалял пару сайтов на PHP
Ахаха)))
Это диагноз
и подтерся ими )
всем похуй
@@user-wf6lc5jz9xты по сей день сам того не понимая лазиешь по сайтам написанным на пхп как навозный жук по говну. Этих сайтов в большинстве. Никогда не понимал таких денди боев с тугими мозгами которые где услышали что пхп умирает типа. Подержи моё пиво паря как говорится…
Мурыч, ты классный дядька! Слушать тебя одно удовольствие
Да, после смерти Ясира Арафата ООП было обречено.
а ты любишь рыбные палочки?
Гей рыба
Вчера был в Магните, - там яблоки по 106 рубликов...
Гилфойл занимательно философствует, мне зашло.. )
мне нравяться подобные видосы потому что они заставляют смотреть на процессы которые кажуться тривиальными из за обильного использования их в программах и разработках в слепую только потому что так тебя учили по иному. Ты начинаешь копать глубже на то что происходит под копотом. Спасибо автору
30:00 БОГИ! как я долго ждал этой мысли от кого-то "сверху"!!!!
как же меня зае.... тенденция отупивания всех программ, сжирания всех ресурсов, грёбаного подхода, что "да плевать на оптимизацию - нужно срочно в прод!"
как же
блин
задолбало!
и задолбало бороться с ветряными мельницами.... словно один в поле... сцукоблин!....
едрить.... мысль на 35:05 просто вводит меня в режим берсерка!
ненавижу. просто блять ненавижу. устраивал бы пытку ложкой. пожизненно.
пятая точка просто горит.
Што случилось?)
"Бороться в ветряными мельницами" - оч правильно себя оценил
@@AbdulAshur ты сути не уловил
Ну, там уже необратимая профдеформация, чел угорел по копанию вглубь и дркопался до реверса, нашел себя, но при этом окуклился и воспринимает все вокруг как байтоебство, которым все обязаны заниматься.
Человек разбирается в своем деле. Не вижу проблемы
Очень правильный гость. Спасибо!
ООП может и облегчить понимание кода (удачные абстракции, понятные паттерны), так и усложнить его (неудачные или многочисленные абстракции, state management). Разумеется, сочетание ООП и ФП, а еще лучше в добавок простая процедурщина с модульностью может приблизить средний-большой проект к успеху. Только код пишут не розовые пони, процесс разработки это не радуга. Каждая команда должна сама решать как писать код, главное решить и следовать этому.
Есть подозрение, что неудачные (на первый взгляд) и многочисленные абстракции могут быть следствием сложности предметной области, которую они описывают.
@@ДмитрийХайтцманн Сложность предметной области субъективна, более того область может диктовать правила написания кода. С абстракциями по большому счёту нет проблем, проблема в полной документации к ним. Я сейчас не про описание API(для внешнего пользователя), я про описание того, что делает код внутри. Для примера, представьте, что вы описываете функцию для ML(AI) чтобы он её "написал".
@@НоунеймНофамов Сложность программы определяется количество if переходов и соответственно количеством тестов для проверки. Больше ничем (кроме тупого оверинжиниринга и бессмысленного раздувания кода).
и тут ООП ну никак не причина@@ВикторГиль-ф2ф
@@ВикторГиль-ф2фВы упомянули цикломатическую сложность. Объясните пожалуйста, как она относиться к теме обсуждения? А сложность для проджект менеджера может выражаться в кол-ве денег, которые надо потратить на код...
Вторая половина стрима вообще классная! Про ФП моя любимая тема, хотя я не большой поклонник чистого ФП. И вот что я хочу сказать, как программист на Лиспе: мы(лисп программисты) находимся в земле обетованной, в то время как "развиватели" языков си подобного синтаксиса, и паскалеподобного включая питон, водят своих последователей по пустыне, подобно Моисею, несовместимых версий "развития" языков. В лиспе что бы реализовать какую нибудь идеологию или парадигму .не надо ждать когда её внесут в стандарт языка программирования. вы можете сами изменить язык для своих задач, а все остальные сидят и ждут, когда это сделают разработчики языка.
Зпощу в тг
Не всегда супер-пупер конструктор это самое классное решение. Часто прелесть языка в том, что на нем не возможно писать любое "поделье" программы или архитектуры, которое пришло отдельному программисту))
@@Mytest437 Ну да, новичку не стоит заниматься сложными вопросами, которые позволяет делать ЯП , например метапрограммированием. Но наличие таких возможностей в ЯП, гораздо лучше их отсутствия, ибо рано или поздно придет время заняться сложными вещами и вот тут то, новичков выбравших простоту вместо выразительности ждет большой облом.
Каша, которая сама себя хвалит. Пропиши функцию или метод и вот тебе твой личный оператор, твоего и только твоего яп. Вкурил мысль?
@@generalakano2788 я? не курю. а ты? ты хоть понял что ты мне написал? ты дебил! написать функцию, это не значит изменить язык и внедрить в него новую парадигму. Ты просто программист на блабле, иди кури свой шарп. или плюснытый си. Тебе до лиспа как до луны. это не твой уровень.
По моему суждению, ведущий совершенно не дотягивает до уровня приглашенного гостя
По каким критериям?
Да ведь так и должно быть, разве нет? ;))
У ведущего борода ниочем
Просто вы выбрали своего кумира…
Согласен, честно говоря ведущего противно слушать даже
В гостях у Гвидона Вишневского)
Ну функциональный подход в С++ вызван ведь не желанием внести доказуемость (хотя, кто знает, за всех разработчиков не говорю), а тем, что многие конструкции при помощи функционального подходя значительно проще реализовать. Вместо написания трёх классов пишешь одну анонимную функцию.
В точку. Что самое интересное, что никаких таких ООП языков в начале 90-х просто не было. Просто не было и были языки процедурные и функциональные, ибо ибо. А все потому, что раньше ты высрать это не мог и строгость языков объясняется тем, что нужно было думать башкой и экономить память. А с появлением дешёвой памяти это стало нахер не нужным и этот динозавр непонятно о чем топит, потому что осмысле стал срать кодом только во второй половине 90-х и поэтому ему нравится говноязык JS, который до появления нод и его пиара не то что языком не считался, а считался дырявой хуйней, что и послужило в середине 00-х заменой его флэшом, ведь именно поэтому это и произошло. Так вот, пошел он козе в трещину.
В точку! И понятно, что это намного лаконичней.
Сначала гость показал себя, как профессионал, однако рассуждениями о Java и JаvaSrip немного дискредитировал себя. JIT-компиляция, которая существенно повышает скорость работы программ, используется не только в движке V8, интерпретиующем JavaScript, но и в JVM (виртуальной машине Java). А если JVM не стековая, а регистровая (как в Android), то программы на JavaScript не могут соперничать по производительности с ПО на Java. Боле того, в JDK 9 появился новый инструмент - jaotc, котрый позволяет ещё больше повысить производительность программ, написанных на Java. Гость также ошибается в отношении языка Python. Кроме стандартного интерпретатора CPython существуют РуРу, который тоже использует JIT. Ещё существует Cython (не путать с CPython), который позваляет использовать статическую типизацию. Высказываю критические замечания только потому, что к словам Вашего гостя прислушивается молодежь, а это накладывет на него большую ответственность. В целом очень полезная передача. Многое из того, о чем рассказал гость, современные программисты вообще не знают.
Супер стрим, на одном дыхании посмотрел и некоторые новшества открыл для себя
Спасибо за Мурыча. Топ контент.
Так и не понял почему же всё-таки ООП умирает: тенденции в статистике - это конъюнктура, сегодня одно - завтра другое. И не нужно всё ООП сводить исключительно к JS и Java, не ими едиными он жив. И по моему субъективному мнению он ещё на наших похоронах простудится - существует огромное множество задач где без него ну просто никак.
По-моему это беседа ни о чём. "Сейчас я объясню, что такое Java. Язык Java - это язык кооперативной многозадачности." Что?! Объяснил как боженька. Ну может умный чел, но хз, по-моему вода сплошная.
Я думал расскажут про какое-нибудь ESC или аналоги. А тут лишь полраза упомянули функциональное программирование.
вообще тоже мало что понял
Джава это язык, где нужен класс для написания хело ворлд. Все, что надо знать.
уже не нужен в последних версиях (но возможно ещё preview, точно не помню)
Думаю фреймворки переходят на функциональщину из-за доказуемости функций - их проще тестировать и потом проще использовать как библиотеку готовых элементов. Пусть ФП и конь в вакууме но как отдельный элемент приложения очень даже удобно подать данные на вход и забрать результат на выходе. Такой изолированный блок можно оптимизировать, переиспользовать и параллелить, проще выделять и освобождать ресурсы. Эдакие микросервисы внутри приложения
Вроде декомпозиция на модули о том ж.
Нет, они делают это, потому, что модно 😂. Грамотный дизайн оо- компонента тестируется проще, чем непонятная зверушка с одним входом, в который нужно передать всё на свете, а половина из этого изначально вхардкожена внутрь этой функции в виде констант... Изменить сигнатуру функции нельзя - посыпится вся "стройная" система реакта (в ооп можно просто добавить ещё один конструктор...). Нет, спасибо, наелся уже фп... Что касается, почему это сделал фейсбук, то на тот момент это тупо быстрее работало... Опять вот такой же "оптимизатор" нашелся...
Функциональную парадигму в чистом виде пока не понятно куда преткнуть. (Для примера чистый язык это, например, ML - очень нишевый язык. Ветка его "потомков" нашла примение в системах автоматических доказаиельств и по сути всё. Т е чисто математическое применение). Отдельные элементы ФП есть уже практически в каждом языке, но они в нем не являются основными. И это js также касается, т к нету не одного серьезного приложения на js которое использовало бы только замыкания и функции. В том или ином виде все используют его псевдо-ооп с прототипами. Кроме того сама спецификация js говорит о том, что функция есть объект...
Про "математическую точность" функциональных языков: когда то думал так же, пока не понял, что любой тьюринг-полный язык позволяет писать код, результат которого не вычислим в математическом смысле и это необходимость в реальных программах. Отсюда и вывод, что ооп оно не вытеснит полностью никогда. Что касается тестирования, то ооп также нормально тестируется, причем гораздо легче. Там где в ФП придется передавать функции в качестве параметров что бы, например, подменить реальную базу, ее моком, в ооп можно просто объявить новую реализацию интерфейса и сунуть ее в тест через ioc-контейнер. Пока не видел ничего подобного в чистых фп языках. Именно за счёт позднего связывания ооп позволяет подменять блоки в работающей программе целиком, в то время как фп языки предлагают заменять отдельные функции. Потому в свое время при огромных преимуществах такого фя как лисп (теже синтаксические макросы, которые сейчас только вводят в некоторые языки), выстрелил паскаль и си, а не лисп. И не только потому, что они были быстрее. А потому, что они позволяют делать разбиение большой задачи на модули естественным образом, а не изголяться, выдумывая как на уровне монад и замыканий родить концепцию динамической связи модулей...
А приглашенный гость хоть и имеет опыт в it, исполняет роль какой-то престарелой ванги, гадающей на кофейной гуще. Это просто смешно прогнозировать смерть языка на основе того, что в нем основная парадигма - ооп. Ооп был и останется основным инструментом в программировании.
Что касается выживания js, то во первых он сам же сказал, что выживание js с точки зрения качеств языка яаляется парадоксом, потому что лучший (по мнению гостя) руби почти умер. Во вторых js - динамически типизированный и снова для большинстаа задач это скорее проблема чем польза. Такие языки прекрасно работают для написания коротких скриптов, для чего js изначально и создали. И в целом если слушать внимательно , гость часто противоречит самому себе.
@@alexandrdeveloper1242 Тысячу раз 👍. Что касается гостя, попробуйте больше 20 лет посидеть в дизассемблерах и не сойти с ума :)
@@alexandrdeveloper1242 , ты ведь пишешь на Java, так?
Java - это язык, в котором невозможно без ООП. Он заточен под ООП. Именно в ООП его производительность.
Поэтому у тех, кто заточил себя на Java представление о мире основано исключительно на Java. Иначе говоря, ты считаешь, что так у всех должно быть или есть.
Первый раз на канале. Интересный стрим получился) подписался.)
Содержание видео не соответствует заголовку: собственно об ООП мало что сказано.
ООП не умирает и не умрет, по-крайней мере в области написания прикладных приложений для бизнеса. Заказчиком, как правило, выступает бизнесмен с неглубокими познаниями в IT технологиях, с ним необходимо общаться, принимать задания, пожелания и проч. Все это описывается в ТЗ, написанное в формате пользовательских историй User Story и Use Cases. Людям проще мыслить и оперировать объектами, объекты окружают нас повсюду. По-этому, общение с заказчиком через описание объектов, их характеристик, естественно и очевидно. Потому ООП как инструмент для разделения кода на логические единицы очень удобен и практичен.
Если же речь идет о системном программировании, разработке прошивок для железок, то да, ООП здесь не нужно и вредно.
Надо шире смотреть на проблему, а не только с колокольни "Хакера" и реверс-инженера. "Специалист подобен флюсу".
Системное программирование может быть разным. Лично я совершенно не удивлюсь, если в ряде "системных" кодобаз на сотни тысяч строк кода ООП в том или ином виде вполне успешно применяется. Во всяком случае, сходу не получается придумать аргументов в пользу Вашего мнения о ненужности и уже тем более вредности ООП в данном направлении.
ООП вообще не соответствует реальным бизнес задачам. В бизнесе 99% не нужно в один объект поведение и данные. Как правило Данные не должны меняться у реальных объектов. Вот например договор. Его заключают один раз и он не меняется. И т.д.
Совсем нет обьектов в бизнесе. Корзина, товар, профиль клиента, история покупок, скидка, транзакция, валюта...@@Torzd1
Для системного программирование есть такая штука как zero cost abstraction. Я так понимаю что в определенных (а может и во многих) случаях если я зык программирования поддерживает данный механизм наличие абстракции не влияет на перформенс приложения.
Полностью с Вами согласен. Особенно если учесть, что почти все паттерны проектирования и тот же DDD невозможно себе представить без ООП.
Речь хорошо поставлена у докладчика, тяжело оторваться.
Сначала была картонка и шило. Шилом в картонке делались дырки. И назвали картонку с дырками перфокартой с машинным кодом. Затем переделали литеры в печатной на литеры с шипами, а клавиатуру печатной машинки назвали ассемблером. Далее к этому ассемблеру приделали барабан от калькулятора железный феликс, получился ванильный си. Когда у си стала туева хуча сменных барабанов, которые обозвали библиотеками, решили сделать один большой барабан, в котором внутри была свора маленьких барабанчиков. И назвали си с классами. Но пришли продажники и сказали, что надо назвать с++. Если посмотрите листинги gcc, там вся эта история написана. В дальнейшем развитии языков программировании программисты уже не использовались. Их место заняли синьоры, как они себя называют. По сути никакого ооп, наследования и тп нет, а есть умные слова для придания своей значимости. Си может и определить пользовательский тип данных и обойтись функциями вместо классов. Все равно машинный код не видит ни классов, ни наследований. В python эти все прибамбасы вылились только в синтаксис. Я думаю, что следующий шаг в программировании должен быть шагом в алгоритмическом направлении, а не в проблеме, как передать значение в функцию или класс.
Запощу в тг на неделе)
Я не согласен в том плане, что всё уже изобретено. Все человеческие алгоритмы реализуются структурным и функциональным программированием (ИЧСХ ООП не решает новых задач, просто упрощает процесс доработки программы, как и структурное не даёт относительно goto никаких преимуществ, кроме понятности кода).
Следующим этапом развития языков можно будет считать их адаптацию к нейросетям, когда нейронки будут не просто дописывать обычный код за программиста а позволят решать задачи не при помощи человеческой логики.
@@КузГА я к тому, что все языки программирования и различные ооп это всего лишь уровни абстракции над машинным кодом и сами над собой. А вот выбор алгоритма решения задачи самим компилятором (интерпретатором, компоновщиком и тп) это и будет шагом вперед. Компьютерным ИИ занимаются уже более 30 лет, но кроме коммерческих поделок дальше не ушли. В архитектуре процессора, начиная с 8080, по большому счету ничего не изменилось кроме векторов, да и то не у всех. Если не считать, что сопроцессор засунули в процессор. Я так думаю.
"Все равно машинный код не видит ни классов, ни наследований" - ооп не для того, чтобы машина что-то лучше видела, а как-раз для того чтобы человек лучше понимал код.
Тактика понятна - Что не знаю, то допридумую. Если поймают на лжи, скажу, что не то имел ввиду и допридумую ещё.
Прикольно, я пол детства на Казантипе провела. Значит пересекались там, но уже конечно не помню этого
Как может человек с такой внешностью (причёска, борода, "чашка" с напитком) рассуждать о красоте кода?
Тема "Почему умирает ОО" начать с "я в Яве профан полный"
1:01:30 впервые услышал разницу между прикладным и системным программированием. Браво Демимурыч.
Гость интересный, многие тезисы хорошие, но по сути все к чему свелось - это почему фп приколы появляются в других языках. Остальное это «потому что я так думаю и у меня есть один пример»
да да, такое очень веселит )))
Очень познавательный стрим!
Ох, помню золотые времена WASM'a и античата, exelab'a, jabbera и ICQ, аж мурашки.
Если Java скоро умрет, то PHP по идее должен уже 10 лет назад умереть?😁
Нет. Как раз таки PHP очень хорош для говнокодинга. Он очень практичен и много для чего подходит. Поэтому не умрет. Умирают обычно непрактичные языки, даже если там все красиво и правильно это никому особо не надо.
Сейчас в основном JS популярен потому что на нем и бэк и фронт можно писать, и php.
Джава реально скоро помрет. Особенно в России. Тут программисты с 3 классами образования на коленках пишут код, и надо что бы с кучей ошибок он всеравно работал.
когда-то разница была ощутимой - IDE рассматривало весь проект как что-то целое, иерархия классов/файлов/модулей... а текстовые редакторы с подсветкой - оперировали одним конкретным файлом, при этом имея возможность контекстного поиска по другим файлам... сейчас эта разница сильно потерлась, соотвественно далее - дело вкуса и маркетинга...
Заносчивость гостя отталкивает
У вас 30 лет опыта и соответствующе количество тысяч прочитанных страниц книг и сотен тысяч строк кода написано вами ВИДИМО
- "Коробочка в которой лежит ссылка на коробочку в которой возможно лежит значение..."" - так это ж по сути аналог указателя из C
Гость интересный, живой, горячий. Но уж весьма консервативен, категоричен. Колокольня опыта гостя так высока, что доступно приподнести свои мысли и идеи не выходит, то и дело заносит. Если начать кирпичик за кипричиком спрашивать за слова, выяснится, что не так всё категорично, как утверждается.
Вот я сейчас на моменте, где гость утверждает, что виртуальная машина, которая является более простой, имеет меньше издержек, чем предыдущая. Сложность решения и его издержки не палка на двух концах.
+++ , слишком душный согласен, если начать спрашивать за каждый кирпич то вся стена сломается
Возможно, дело в том, что он смотрит на всё как человек из времён программистов-учёных (чисто из-за своего личного жизненного опыта). По этой причине, вероятно, его и восхищает "академичный" язык руби и тому подобное.
На мой взгляд, большая часть современных (как-минимум СНГ) программистов, вкатывающихся в рынок, скорее хочет с максимальным для себя удобством формочки клепать и джсончики перекидывать попивая смузи и получая 300 k в наносекунду, а не виртуозно оперировать памятью и исполнять код нативно. Им фиолетово "используют они все уникальные возможности IDE, которых нет в VS" или не используют. Максимально утилитарно-гедонистический подход.
Просто поменялись времена. Рынок массовый, ему нужны решения здесь и сейчас. Да Винчи от мира программирования на всех не напасёшься.
P.S. Несмотря на мой тезис, мужик крутой. Видно, что человек наблюдал за эволюцией программирования в реальном времени и активно им интересовался.Вот такой вот летописец наших дней
спасибо Дугину за атмосферу! Сам застал времена когда не было окон, был паскаль, потом .net и т.д. Понимаю его))
Уверяю вас. Как только армия тру программеров получит мощнейшего фундаментального пинка под свои сраки от искусственного интеллекта ,они сразу вспомнят что последние 20 лет занималась искусственным усложнением и наведением коммерческого тумана в своей профессии. Сразу же придумают и нормальный универсальный язык программирования дружелюбный для новичков и удивительно дружелюбную ide с кучей готовых модулей. Но будет поздно.
Что то вспомнил историю как МВД закупило серверы на процессорах Эльбрус, которые прилично тормозили. Эффективные менеджеры считали, что можно бесконечно говнокодить увеличивая при этом производительность машин, однако всему есть предел
Чувак оторван от реальности, не осознает, что корпорации умеют считать деньги лучше. Всем диктует Капитал.
по поводу IDE я с ним не согласен на 100%. я тоже долго думал что VScode достаточно.. но как оказалось от его пришлось полностью отказаться в рабочих процессах. она даже банально не смог подхватить вменяемо настройку линтера для авто форматирования. ну нет там таких плагинов. а наставишь плагинов, он уже жрет больше чем IDE. я уже молчу про то чтоб показать банальные ошибки.. даже банально в верстке плагины которые помогали в итоге лишь мешали, не говоря уже о js, php и python. да, какое-то время мне его хватало, но когда перешел в компанию с среднего уровня проектами, все, его пришлось забыть навсегда.. да, на нем можно писать как и в vim тоже можно, но на много дольше пишешь и много чего не автоматизировать. меня допустим такое бесит сильно.
А чем тогда пользоваться вместо vs code? Какие посоветуешь варианты?
Проблемы Java немного в другой плоскости. Это разработка 90-х годов, когда были одноядерные процессоры. Обещали, написанное один раз работает везде, что по определению невозможно. Следующая проблема - наследование, которое вызывает расход памяти на каждый объект в наследовании ( отсюда резкий рост расхода памяти и снижение быстродействия, даже если реально используется 1 байт в классе (наследование от Object автоматически добавляет несколько десятков байт и обработку этой памяти). Еще одна - автоматическая сборка мусора, вызывающая строгую очередь к выделению и освобождению памяти в нескольких потоках, что по сути все потоки выстраивают в один поток и вызывает снижение быстродействия на современных многоядерных системах до уровня Pentium 4 + вынуждает работать только в оперативной памяти и при превышении физического объема памяти просто падает и не может использовать swap.
ПС: новые языки появляются из за появления людей, которые не хотят изучать языки и по причине отсутствия понимания, считают, что напишут что то лучше. В процессе написания они выясняют, что ни на что не способны и новый язык умирает.
И самое главное в ООП, проблема синхронизации состояния класса в многопоточной системе. Нельзя прерывать выполнение метода класса, потому что соседний поток может получить некорректное состояние класса. В результате ООП очень плохо работает на многоядерных системах из за проблем с синхронизацией. И пытались даже сделать особый процессор, работающий с классами. Но ничего хорошего из этого не получилось... История показывает отрицательные результаты использования ООП. В той же Java был awt, потом Swing... потрачены огромные деньги и все выбросили на свалку, никакого повторного использования. В то время как в С есть библиотеки, используемые повторно более 50 лет!
Бородатый выдал базу на 50 секунде чем он занимается на ютубе во всех роликах со своим участием - повышает уровень энтропии, то есть повышает меру неопределенности приводя все к еще большему хаосу, а не уменьшая его.
было жарко, было интересно
41:41 Число 4 млрд в 2х байтах? Уровень!
оговорился человек, скорее всего имелось в виду int32 и 4мб
@@КенниМазафак value 4000000000 to uint32 !
Да, это уметь надо, 4 байта до двух ужимать. Не каждому смертному дано )
Проблема в том что даже супер спецы по с++ не знают и не могут знать до конца ни устройство кода ни ос ни архитектуру компьютера. Это всегда угроза выстрелить себе в ногу. Компьютер сложное устройство с огромным количеством узких мест и неожиданных эффектов. Не получается ни использовать какой-то уже отработанный код в основе ни углубляться каждый раз до самого железа. Постоянно образуются такие глюки и тормоза которые очень трудно предсказать и предусмотреть. А учитывая то что сложность кода она растет взрывообразно при увеличении возможностей продукта то становится очевидно что ни один мозг не сможет охватить все и сразу. И ведущий совершенно верно говорит что есть реальность где нужен результат и идеализм в создании он практически не реализуем. Да современное производство по оно пугающе странное для людей старой закалки. Что-то там побыстрее криво лепят потом фиксят глюки тормоза, нет чтобы сразу все нормально писали. Но оно работает и даёт коммерческий результат. В конце концов нас спасет искусственный интеллект которому по силам оптимизировать весь наш кривой код и пофиксить ошибки. Тем не менее я не верю и в искусственный интеллект. В итоге сложность кода и его поставит в принципиальный тупик и тогда мы увидим пределы его возможностей.
Просто гость близко не знаком с современной технологией производства по. Вот она именно такая с командами разноуровневых специалистов лепящих хреновенький код который потом тестят и доводят до ума опять же весьма странными способами .
Вообще чисто теоретически возможность сокращать сложность существует если планомерно совершенствовать железо. Например перейти на троичную логику, что убережёт от ошибок. Это убрать семь уровней разного уровня памяти заменив его на один. Это уйти от шинной архитектуры к системам с параллельным доступом и вообще от многоядерных систем к системам из матриц полноценных микро компьютеров.
@Red_Paper6495 Да? сразу видно специалист комментирует, ничего кроме эмоций.
@Red_Paper6495 это не комментарий а высер называется.
@Red_Paper6495 высер ты написал. А я написал развёрнутый комментарий со всеми обоснованиями.
Не означет ли данное видео тот факт, что в некотором роде люди, которые претендуют на то, чтобы его посмотреть, в каком-то роде, если говорить инасказательно, вдруг подумали, что знают тенденцию рынка джава программистов, или же джаваскрипт рынка.
Вот как раз к вопросу о "коробочках", интервьюер говорит что "функции в java есть", но фактически не понимает, что лямбды и ИНТЕРФЕЙС Functional - по сути анонимные объекты с заранее определенными методами, т.е. это не функции как в js, а все еще объекты. Именно поэтому в Java сложно писать в истинно функциональном стиле. Нельзя просто взять и создать функцию, нужно воспользоваться встроенным интерфейсом или определить свой. И это все после вопросов "какая разница две у нас коробочки или одна?". В этом и разница, начинаем с коробочек, а потом рассказываем про ФП в Java
Спасибо что за меня решил, что я понимаю а что нет. Тока в js функции это тоже объекты, теперь обьясняй разницу.
Классный гость, совсем недавно канал Мурыча открыл для себя. Не заметил таксичности в нём, но заметил здоровое непринятие глупости и невежества. Привет всем славянам из Новосибирска
Согласен с вами.
Именно глупостью и невежеством Мурычь объясняет работу UA-cam.
Цитата из стрима 22:22:
"Интерфейс UA-cam, он жеж простой, он же элементарный до задницы.
С чего вдруг он может жрать столько памяти?!"
При историческом необходимости технологии будут обновляться, так что не волнуйтесь все будет хорошо)
Вы умрете а ООП всё ещё будет быть и здравствовать))
"Честно мужик пока несет преимущественно наукообразную бредятину" - Это ваша банда 4-х и паттерны проектирования - бредятина.
Я вот тоже не понимаю, почему всякие gmailы занимают какие-то гигабайты, рисуют огромное количество html, зачем нужны всякие reactы в фейсбуках, 300 Мб зависимостей, ведь все это делается элементарно на простом js, там же ничего сложного. Может это заговор seniorов долины, чтобы им платили по $700k?
Знаешь, что было с последним кто встал между фейсбучными сеньорами и их 700к? Никто не знает. Будь осторожнее...
@@MyName-tg8ek я бы тебе запросто показал такой проект, но куда ни плюнь, везде требуют реакт/вью
мы ждём примера
@@kotix_ тут ссылку удаляет, у меня есть два небольших проекта, анимация и игра на вебсокетах с использованием только нативных инструментов
Надеюсь это троллинг) Пока ты пишешь на голом JS простенький туду лист (с анимашками, лоадбарами, ленивыми подгрузками и т.п.), на реакте можно будет сделать полноценную CRM-систему)
6:05 Чего?! В HTTP никогда не было ограничений на размер тела запроса. Это ограничение всегда было только на стороне сервера.
Естественно. чепуху несет.
Конечно я ни разу не программист, можно сказать, что рядом стоял, но из беседы понял, что обсуждались два подхода, либо продумать поведение программы, её увозможные узкие места в начале написания, либо исправлять появляющиеся ошибки и неточности по мере их, так сказать, поступления, что является современным подходом, как я понимаю.
15:21 значение ссылки(адрес) передается по значению АЛОО
приятненько даже в записи
про логические сдвиги непонятно, в java тоже просто отбрасываются биты, ровно как и в JavaScript, но в js виртуальной машине нужно сначала ещё узнать, что перед ней вообще числа, а не например, строки, поэтому вероятность генерации оптимального когда в среднем будет лучше в java - именно для логических сдвигов имею в виду
Если бы я не слушал это интерью в наушниках пока еду на работу, то я мог бы сказать, что потратил время зря. Абсолютно ничего нового для себя не почернул и не сделал никаких выводов. Кроме одного заключения. С Деми Мурычем можно говорить только о двух вещах: как никто не знает JavaScript и о реверс-инжениринге (о котором я ещё его видео не встречал). Только больше бардака в голове образовалось. Честно говоря, ожидания у меня были совершенно иные.
Почти все рассуждения Деми кажутся не объективными и высосанными из пальца. Единственное, что понравилось, так это тема про IDE, где он почти подводит к мысли, чем на самом деле является IDE. Но конкретного определения так и не было дано (обидно).
МУРЫЧ ЛЕГЕНДА ИНТЕРЕСНО СМОТРЕТЬ СТРИМЫ С ЕГО УЧАСТИЕМ
А ООП когда-то жило? Разве можно назвать жизнью существование чего-то, что хвастается фичами, половина из которых не является эндемичными для этого чего-то (полиморфизм ≈ перегрузка функций/операторов из ФП, например), а половину оставшихся фич вообще не рекомендуют использовать (ради справедливости: ОДНУ фичу - наследование, но фразу "composition over inheritance" дети кодеров произносят до "мама"/"папа"; и да, композиция - тоже фича ФП, и она настолько крута, что Юниксы практически строят воркфлоу на её основе, например, направляя вывод одной проги в другую)? Я даже не говорю о том, что чувак, придумавший само понятие ООП и вроде как самый ООПшный язык из всех, спустя сколько там? 20 лет? резко переобулся в прыжке и начал рассказывать, что НА САМОМ ДЕЛЕ всё это время он имел в виду под ООП системы, взаимодействующие при помощи сообщений, но типа чел, поезд ушёл, вернулся, постоял в депо и в итоге там нахрен сгнил, пока ты набирался смелости сказать, что наследование - ваще не круто, а инкапсуляция - условно круто, но тоже ну такое. А уж какого говна поверх этих стрёмных понятий навертели Sun - просто дичь; этот чёртов Левиафан может тягаться с Дебианом по тормознутости, только Деб тормозит с заливкой нового софта в свои репозитории, а Жаба - адаптированием фич. Да чёрт возьми, у них всё настолько плохо, что пришлось аж целый отдельный язык пилить (и я даже не про ту динамически типизируемую ересь, на которой энтерпрайз любит чтобы ты писал пайплайны - это совсем звездец; я про Дуэйна Scala Джонсона), лишь бы поменьше контактировать с Жабой. Тьфу!
Опубликую у себя в ТГ
@@DecembristITTV 😸
насчет фортрана. так он используеться под капотом пандас библиотеки питона для работы с терсерами и массивами
Гость - ЗАЧЁТНЫЙ!!! отсылки к 97 году - уважуха!!!! Я в эти года как раз и переходил на линукс. Си подобный синтаксис - это ХЛАМ!!!! У перла тоже си подобный синтаксис, если вы на нём напишете однострочник, 10 академиков не разберутся как он работает.
Можно пример? А то я не совсем понимаю, чем один однострочник выгодно отличается от другого.
@@сергейсемёнов-о7ю нет, я давно не писал на перле, Но вы можете посмотреть любое регулярное выражение. Как правило именно они используются в однострочниках на перле. такое выражение может быть размером несколько килобайт, или несколько экранов.
Дерьмо из всего сделать можно)
Соглашусь с гостем, что есть проблема.
Решение - дать правильную дефиницию термину "Программист". Сейчас программистом называют того, кто может решить задачу и код реализует бизнес-логику. И ошибка в этом.
Представьте, что от сантехника требовалось бы только чтобы вода утекала в канализацию - а как и каким путём не важно. Так, он может нагородить кучу труб, поставить кучу насосов, посадить мужика который будет ведром черпать - и т.д. Любые глупые, неуместные, дорогие и нелепые решения. Но если мы ничего этого не видим и оцениваем лишь то, что вода утекает куда нужно - то мы назовём его компетентным сантехником? Вот это происходит в программировании.
И если излишние трубы у сантехника стоят денег - то какой-нибудь фреймворк или сторонняя библиотека программисту ничего не стоят.
Но в программировании "нагромождения труб и насосов" не очевидны и потому за программиста сойдёт любой, кто заставляет "воду утекать в канализацию".
Безусловно, для решения этой описанной выше проблемы нет простых решений. Реализовать задачу - это уже начальный уровень знаний по программированию. Но главное чего не хватает - это понимания озвученной проблемы у самих программистов. Задача программиста не просто в том, чтобы бизнес-логика работала. Задача в том, чтобы реализовать это относительно адекватными для этой задачи инструментами. Если нужно нарастить сточную трубу, то нужны труба и соединения, а не фреймворк с насосами, потому что он универсален под любые задачи с водой.
А сегодня большинство программистов не то, что не задумываются о том как работает интерпретатор или компилятор (во что превратится программный код на машинном уровне и сколько ресурсов это будет стоить, как это будет выполняться и как можно изменив логику получить многократное улучшение), а используют сложные фреймворки или библиотеки лишь потому, что это в минимальной степени сокращает их работу (как им кажется), но в итоге это просто до сумасшествия пожирает необоснованно много ресурсов.
Разумеется, можно найти много примеров, где тот или иной фреймворк или библиотека окажется крайне полезными и будут использованы правильно. В конце-концов их создавали для решения конкретных задач. Но часто можно увидеть, как фреймворк или библиотеку используют на 0,5%, а архитектура этого фреймворка или библиотеки построена крайне избыточно или неподходящим методом, если оценить её с точки зрения решаемых задач и эта избыточность не просто лежит без дела - а выполняется и отнимает ресурсы. И дело не в фреймворке или библиотеке. Дело в том, что программист использует инструмент в задаче для которой этот инструмент не подходит. А всё потому, что он себе не ставил задачу реализовать бизнес-логику адекватными инструментами. Он просто решал задачу любым, самым простым для него способом.
И потому, это вопрос в том, чтобы исправить дефиницию слова Программист.
Программист, это не просто человек, который как-нибудь заставит программу работать. Просто реализовать как-нибудь код - это человек который знаком с программированием и имеет некоторое (может даже и углублённое понимание) того как пишутся программы и понимание в какой-то мере языка на котором программа пишется. Но Программист - это тот кто не просто решит задачу и обеспечить функционал. Этот то, кто решит эту задачу адекватными (относительно) методами. Ведь он программирует компьютер, верно? Тогда, в идеале, он должен иметь представление о том сколько ресурсов и почему та или иная его команда занимает у компьютера?
Безусловно, слово "относительно" добавляет градацию - кто-то хуже, кто-то лучше. Вот мы и имеем, что один программист лучше другого. А кто-то настолько плох, что и за программиста не сойдёт, хотя простенькие программы вроде пишет и они даже работают.
Короче это вопрос понимания этой проблемы и вопрос выбора кадров при найме. А тогда соответственно и вопрос обучения кадров изменится в соответствии с такими потребностями рынка.
Пока программистов сильно не хватало, работодатели вынуждены были нанимать снижая требования и рынок породил эти сегодняшние проблемы. Но исправить дефиницию слова Программист важно. Ведь пока не будет правильного понимания, процесс исправления этой ситуации не начнётся.
Программист это тот, кто умеет выполнять бизнес-задачи в кратчайшие сроки инструментами, которые имеются под рукой. Если завтра у твоего магазина черная пятница, то тебе нужна формула расчёта скидок, сортировки и красивой анимацией в четверг любыми костылями, а не через месяц зато красиво и оптимизировано. А аналогия с сантехником нагромодившим труб и насосов больше подходит как раз к программисту, который что-то там оптимизирует и размышляет о поисках "оптимальных инсрументов", тратя самый драгоценный ресурс бизнеса - время.
Хороший сантехник - это который когда у тебя заливает дом, затапливает соседей чинит трубу из того, что имеется, даже если придется нагромоздить прокладок, переходников, а не думает о "самом оптимальном варианте на века и откуда заказать трубу попрочнее".
@@vladyslavenvironment5368 Вы как раз и подтверждаете, что у нас с Вами разная дефиниция слова "Программист" и это будет приводить к разному подходу к работе.
Что касается Ваших аргументов в защиту Вашей дефиниции - то Вы вправе относиться к работе так, как считаете. Рынок на то и рынок, что люди могут практиковать разные подходы. И у каждого подхода свои плюсы и минусы.
Безусловно, бывают аварийные ситуации когда нужно сделать лишь бы заработало прямо сейчас... И конечно, хороший сантехник умеет "чинить" в аварийных ситуациях - по-быстрому. Но думаю очевидно, что такой вид ремонта "по-быстрому" нельзя назвать качественным и после аварии это "аварийное" решение стоит переделать на штатное, надёжное.
Конечно, мы не говорим о ситуациях, когда сам заказчик является проблемой. Мы говорим лишь о том, как свою работу понимает специалист.
Норм мужик, меня так же бомбит и от гугла с его программистами и тестиррвщиками, и от современной веб-разработки, и того, куда она докатилась. Я сам работал в конторе, проект которой грузит бандлы 15+3+3 Мб, затем они конечно кэшируются, но понятно, где это сидит со всеми своими структурами, и явно не в таком размере, а бОльшем. У меня рабочий стек с браузером выжирал после запуска 19 гигов оперативки, а после пары недель работы с уходом ноута в сон все это начинало выжирать все 32 гига моего ноута. И потом гугл вводит в строй свои идиотские превью вкладок при наведении мыши, после чего все 32 гига выжираются уже в течение рабочего дня.
А при входе в раздел происходит так много запросов и сваливается так много jsonов, что это открывается18 секунд. Если че, я говорил, что это недопустимо, как и громадный бандл. Меня правда нахер уволили, и теперь два года без работы сижу...😂 Так что, лучше делайте тормозное говно как все, и не высовывайтесь.
Но все это будет не долго, ваш язык умрет, и вы со всеми своими знаниями станете не нужны.😂 Как стали не нужны программисты на Перл, РоР, адобе флэш. Айти - это лотерея... Тратишь половину жизни на изучение этого всего, а потом оказываешься у разбитого корыта. Даже джуном никто не возьмет.
Меня тоже выбешивает такой подход к разработке сайтов, недавно сделал сайт услуг, в котором всего 70 Кб JS, никаких фреймворков и JQuery естественно. И страницы сайта весят не более 600-800 Кб (основная часть - это картинки). По Google PageSpeeed - честных 100 баллов. Думаю, что для интернет-магазина допустимо в пределах 200 килобайт js-кода, весь его интерактив можно вместить в этот объём кода. Но никак не бандлы по 3-5 мегабайт.
Бизнесу вообще насрать на качество и быстродействие сайтов, особенно если это мелкий и средний бизнес. Им важно, чтобы сайт был сделан побыстрее и подешевле. Недавно в мою компанию поступил на продвижение очередной ИМ-быдлосайт, там всего 50 товаров, но при отключенном кэшировании у него TTFB 1500 мс! Сделано это уебанство, как и полагается, на WooCommerce + Elementor + "премиум-шаблон" WP.
27:30 это решаемо. Можно включать эту опцию для тех ресурсов, которые это одобряют.
Классный стрим, спасибо за гостя.
Java вообще появился как платформа для встраимых устройств и подразумевалось аппаратное исполнение байткода, а не потому что была востребованность на рынке. Но всё пошло совсем не туда, как часто бывает. Его появление совпало с массовым внедрением Интернет-сервисов и он случайно попал в эту нишу.
Уважаю Мурыча, крутой дядька, очень хорошо объясняет, что под капотом программного языка, чем не многие могут обладать.
Хз, какой-то задроченный хрыч без карьерных успехов, пытающийся повысить самооценку за счёт блогеров и СПЕЦИФИКАЦИИ
Жизнь джавы зависит сейчас не из-за графиков и рабочих мест, а от того начинают ли новые проекты писаться на джаве. Если, условно, сейчас все начинает на го, шарпах, даже котлине, то капитал написанного кода будет уже совсем другим. То есть, если доля новых проектов крайне мала, то будет эффект инерции и стагнации.
Субъективно, в моем окружение, люди когда думают о новых проектах, о джаве уже не вспоминают вообще. А бизнесу все равно, главное чтобы специалистов много было. Сейчас может это джависты, завтра там другие, главное чтобы побольше.
Статистика нужна иначе нет смысла
В моем окружении вполне себе вспоминают и вполне себе пишут, будь то госуха или коммерческие проекты, и речь не только об СНГ. Есть ребята в известных компаниях в европе, которые стартуют коммерческие и внутренние проекты на современной джаве с модными фреймворками
смотря с кем общаешься
ты может пацан современный, а коллеги джаву с пхп забыть не могут и ничто их уже не вылечит)
Давайте стрим где оба пишут Фибоначчи и замеряют перфоманс.
Подоставали свои фибоначи и перформансами меряются....
Кстати, спасибо автору канала!
Благодаря ему я поменял свое отношение к Григорину и Соеру и познакомился не только с такими личностями как Мурыч и Назаров, но и с творчеством группы TheDecemberists.🤘
Рекомендую иметь собственное мнение
@@Das.Kleine.Krokodil Рекомендация полезная, хоть я и ее и не просил, но вы о чем?
@@сергейсемёнов-о7ю домашнее задание тебе
насчёт переиспользования памяти в ФП парадигме непонятно, о чём речь. об иммутабельности?
Примерно 26:00 - разговор о темной теме.
Это полный трэш. Уже сколько лет прошло, а приложение Ютуба до сих пор превращается в черно-белую страницу при автоматической смене темы, потому что цвет дневного шрифта это тот же цвет, что у ночного фона, а цвет ночного шрифта - цвет дневного фона.
Ребята java не функциональный язык не был и не будет. Все что заимствованно из fp под капотом так или иначе работает по принципам ооп. Scala по сути тоже самое что и kotlin
1. Что это меняет?
2. Где работает иначе?
@@DecembristITTV меняет это то что все функциональные тайпклассы в большинстве своем вырождены и применимы в чистом виде в чистых фп языках таких как haskell и лисп подобных. То что говорил гость вы не совсем правильно поняли. То что функция всегда что то возращает, а точнее возращает как правило функцию это вовсе не в парадигме java и мультипарадигменных языков. Если быть точным вы можете это делать или не делать, но к примеру в haskell, функция от двух аргументов работает на исчислениях ( ленивый язык), то есть вы передаете первый аргумент и вам возращаеться функция от одного аргумента.
Я не думаю что ФП бивалентно я думаю ФПшность языка это градиент. Умеет ли жаба делать часть того что умеет хаскель? - Я не знаю, но кажется что да. Если аргумент в том что ФП это только хаскель, то тогда ФП никому не нужно, судя по популярности хаскеля. Ваше определение ФП просто не полезно в таком случае.
@@DecembristITTV Моя специфика это scala. На java дай бог покрываеться процентов 10-15 от того что может scala. И даже это джависты не всегда могут освоить по причине что ооп не дает им рассмотреть фп в глубину. Это не вымысел а личный опыт. А про популярность того или иного языка не совсем правильно рассматривать в теккщем контексте. Популярность устанавливают работодатели, а им не выгодно учить джунов годами фп нежели за 3 месяца дать основы ооп.
Если аргумент в том что скала больше ФП чем джава то я с этим и не спорил бы. Но аргумент, что джава вообще не ФП так как там все объекты и тд, просто не имеет смысла, во вселенной где хаскель никому не нужен. Особенно учитывая, что поинт стрима был в том что ООП умирает тк как всех победит ФП. Типа ФП вот-вот всех победит, только на нем никто не пишет, как-то неправдоподобно.
Если хотя бы одну виртуалку постоянно держать, то 64Гб оперативки это необходимый минимум
>реакт двигается в сторону функциональны
Нифига подобного. Реакт никогда не был ООПшным.
Несмотря на классовые компоненты, в реакте никогда не поощрялось ООП, а наследование компонентов вообще было отмечено жирными буквами в доке как антипаттерн. В то время как фп паттерны использовались в реакте с бородатых времён - hoc, композиция в рекомпоуз и тд.
Я не разбираюсь, но доверяю этой информации
Потому что реакт - мультипарадигменный. От ООП у него, например, методы жизненного цикла. Это если говорить про кассовые компоненты.
ООП по сути это тоже функциональщина только обернутая в объекты, так же как функции принадлежат файлам так и в ООП эти функции принадлежат объектам внутри файлов. Я фронтенд разработчик, пишу сложные вещи на typescript и даже боюсь представить как-бы мой код выглядел с использованием только ФП
ооп - это не об адекватности моделирования задачи, а об удобстве эксплуатации разработчиков и производительности производства для нужд бизнеса. давно существующий лозунг "долой императивное рабство" как раз об этом.
По мне, языки делятся на нормально отлаживаемые, типа 1C v8. И остальные, которые вроде бы отлаживаются, но на деле этим мало кто пользуется. Не знаю, по каким причинам. Возможно, это связано с компилируемостью или интерпретируемостью языка.
А какая спецификация имеется ввиду, когда говорится, что все значения передаются по ссылке?
Arguments are always passed by value and never passed by reference. This means that if a function reassigns a parameter, the value won't change outside the function. More precisely, object arguments are passed by sharing, which means if the object's properties are mutated, the change will impact the outside of the function.
Надо написать в MDN, а то вдруг они там ошиблись или, страшно сказать, заблуждаются.
все еще достойны лайка от СЕООНЛИ!
Ведущий не дает спуска гостю, красава.
Покажите мне этот блистательный код, написаный в ФП :D. Пока что только одни слова
Код вообще или код этого бородатого? Есть такой сервис, whatsapp, работающий на Erlang и поддерживаемый весьма небольшим числом разработчиков. Подозреваю, что там функциональный код хорошего качества.
"в джаве появились стримы" не прошло и 40ка лет, как эти стримы были описаны в лекциях SICP с подробностями которые и дегенерат поймёт, удалось реализовать на джаве эти стримы!!! да джва это передовой функциональный язык!!!
посмотрел треть стрима. было душно, но я смотрел на лицо ведущего и жестикуляцию гостя - было весело уже.
Но это же не разработчик. Что он может знать о полезности/бесполезности ООП?
а что такое ООП? странно можно делать понятные и читабельные проекты применяя функциональный подход, что в итоге оптимальнее, чем ООП, ООП пора на покой.
@@ViktorAr2023 и где все эти оптимальные и читабельные проекты на фп?
Мурыч как пентиум 4 среди райзенов )) Перл сейчас наверно слова такого не слышали ))
Вы чего вообще хотели от пенсионера-растамана, который всю жизнь реверсом занимался? Давайте еще министра образования позовите для полной жести!
Типичный случай, когда мужик любит поумничать даже в тех вопросах, где не очень компетентен.
Себя описал?
@@bobomurod 40 лет стажа разработки ПО. А у тебя, умник, сколько?
ютуб не просто так жрет столько ресурсев ... это происходит только в случае когда ты не смотришь рекламу ;) ... убираешь адблокер и все проходит
начинать изучение с prolog или logo - это вообще бред на мой взгляд, чтобы начать изучать программирование
Я совсем не программист . Но около. Очень стало интересно: какой серверный фреймворк на JAVA самый быстрый? На java script вроде бы сейчас Bun js жарит.
Спасибо за пищу для размышлений.
- В java ты не можешь переопределить тип number, а в JS можешь!!1111
- А нахрена?
- Вооот, а в JS можно!111
Бл, как бы обьяснить, что профессиональный инструмент тем и отличается от любительского, что позволяет сделать что-то охуенное именно одним единственным ОПТИМАЛЬНЫМ способом, а не вот эта вот ваша гибкость ради гибкости, что бы каждый хрен с горы мог каждый год высерать свой новый фреймворк/либу/семантику в JS. Потом заказчики не понимая садятся на все это и потом мне лично приходится все это говно выгребать в осенизаторском костюме.
!!! Та же чешуйня!
Это все нужно только для говнокодинга. Поэтому JS и PHP так популярны, потому они позволяют программистам самоучкам кодить с кучей ошибок и без понимания вообще что такое тип данных. Именно поэтому их и используют. А не потому что он быстрее или еще что-то.
Там говнокода понапишут такого. что ни о какой скорости и речи не идет. Но в jave этот код не будет работать и надо будет сидеть дебажить его, а в пхп будет работать, вот в этом и вся разница.
JAVA только в крупных компаниях банках и проч поэтому используется, а PHP везде где нужно что-то тяп ляп сделать главное что бы работало.
Есть такие ЯП, где переменные - это действительно коробочки и это приводит к страшным последствиям, когда вы объект посылаете в переменную, он там самопроизвольно исполняется. 😆 Поэтому создатели таких ЯП придумывают специальные объекты, которые не исполняются при помещении в переменную. Что приводит к перегруженности языка.
Я из соседнего болота)
1:21:52 - мысль примерно с этого момента, что "Проект написанный на Java вряд ли будут переписывать", если я понял правильно. Если я действительно понял правильно, то согласен и не согласен одновременно. Переписывать будут - просто не все, не всё и не сразу, поэтому не согласен. А согласен, потому что альтернатива на которую станет переходить разработчик или команда будет такой, что сможет соответствовать всему тому, что было реализовано, но привнесет бенефиты. Пример моих слов - переписывание мобильных приложений с Java на Kotlin. При этом проект внезапно не становится написанным в функциональном стиле, о чем и есть основный посыл, но привносит полезного сахарку:-)
30:30 - 16 гиговая планка гораздо больше стоит чем 15 баксов. Во первых не вовсякую мать воткнёшь 16 гиговую. Т.е. нужно и мать менять и проц. И новые модели 16 гиговых планок стоят от 50 USD, Но это одна планка. А при замене всей системы меняем всю память . так что апгрейд выйдет не менее 700 долл. Только чтобы сайты не висли.
Какие придирки к гостю? Такого грамотного программиста я в сети больше не встречал. И да, уметь так выражать мысль в программировании это надо уметь...
Настоящий программист, а не гавнокодер
Великолепное объяснение про подмену знаний аналогиями. деривативы от деривативов приводят к краху.
Спасибо за честную и точную техническую позицию!
Проблема в том что его знания тоже аналогия. И вообще любое знание это аналогия и лишь одна из большого количества возможных.
@@12strel На мой взгляд, иначе обстоит дело - как раз ложные аналогии отсечены бритвой Оккама безжалостно и быстро.
@@FimaMillston бритва Оккама не исключает принцип дополнительности
@@12strel Вряд ли это сочетается с "не множ сущности". А вот демагония Ваша, вероятно, кому-то интересна могла бы быть, но не мне. Увы.
@@FimaMillston думаю вы не поняли что такое бритва Оккама. Она не про аналогии, она про научные модели. Согласно ей если есть простая модель которая объясняет предмет исследования так же как и сложная то нет смысла использовать сложную модель. Но согласно принципу дополнительности нильса Бора ни одна теория не описывает предмет столь исчерпывающе чтобы исключить возможность других подходов. И все это нужно ещё проверять через другие принципы научности например принцип фальсифицируемости поппера. В общем вы должны понимать что бритва Оккама это рекомендация а не правило.
1:06 в java есть reflection. Он много чего позволяет, но размахивать этим, как дубинкой действительно моветон.
Меня после java в лёгкую прострацию ввело то что в js массивами называется.