Автор, спасибо тебе за видео, это одно из лучших видосов по проге, которые я видел в ютубе. Ты прям четко по теме говоришь, а многие авторы много воды льют, в итоге видос на 10 мин, а сути 0. Подписался на канал, буду следить за твоими видосами)
Java классный язык. Он - первый из тех, что я начал изучать. Из минусов для меня, Java громоздкая для небольших программ (утилит), поэтому для них лучше другие языки: python, kotlin и т.д. Но для больших приложений Java почти идеальная.
Очень интересно и наглядно, в классических традициях Хорошего программиста. А где находится JVM? Вот например пишется приложение на Java под Andriod, соответственно JVM - это компонента Android Studio?
jvm в андроид называется иначе en.wikipedia.org/wiki/Android_Runtime и работает она в самом андроиде, для каждого приложения запускается системный процесс, в котором оно выполняется (очень грубо говоря)
Филя Усков пишите по стандартам и на кроссплатворменных либах, будет кроссплатформенно. Серьезные приложения все равно надо тестить. Вы придумали себе искусственную проблему. Зачем вам вручную управлять памятью??
У нас есть два компилятора, которые могут компилить код в байт-код под две разные операционки. Ок. Берем код, отдаем его двум разным компилятором на двух разных операционках - получаем два результата. Теперь у нас есть код, который компилится в джава-байткод, который отправляется двум виртуалкам, которые умеют компилить его каждая под свою операционку. У нас был универсальный код на языке программирования, теперь мы взяли универсальный код на языке программирования и сделали из него тоже универсальный джава-байткод и скормили его уже не компилятору, а виртуальной машине? В чем разница? Если не говорить об управлении памятью? И вроде как джава-машина интерпретирует джава-байткод прямо по ходу исполнения, нет?
Разница в том, что на плюсах по-настоящему универсальный код возможен только в очень узких классах задач или очень простых проектах. Потому что ЖВМ для вас абстрагирует ОС почти полностью, включая низкоуровневый доступ, например, к USB портам. На плюсах вам надо под каждую ОС искать свои либы для работы с железом и с самой ОС.
@@Artistofun, я на плюсах не писал, я писал на питоне. Вот устанавливаю я питон на линукс через апт или на винду через .exe - он у меня и там и там интерпретирует один и тот же код. И если я не могу через встроенную либу питона подключиться к usb портам, это значит, что в интерпретаторе питона просто нет такой библиотеки. И все. Ну, допустим в ДжВМ есть такая под винду и такая же под линукс. Нужно разрабатывать две версии виртуальных машин под разные операционки, чтобы одинаковый код на джаве работал и там и там. Допустим, в питон добавили встроенную либу, которая умеет работать с усб-портами. И допустим, разработали два интерпритатора для винды и линя. Чем это отличается от разработки двух виртуальных машин с похожим функционалом, но под джаву?
@@Artistofun тут виртаульная машиныа умеет в порты усб, там либа в компиляторе умеет в порты усб. Или компилятор не может дополнительные либы включать?
Теоретически можете, но упоретесь портировать и адаптировать ваш код под каждую платформу. Если это сложное приложение, использующее множество библиотек и сложных функций системы. А не hello world
Джависты сделали круто виртуальную машину ? :)))) В то время когда жава машина требовала обновления железа до топового на протяжении многих лет та же самая смалталк машина летала на железе 90х только в путь. Причем установка этой самой машины под ту же винду требовала просто папки с дллками :)
И на самом деле да, это будет тормозить. Слава закону Мура, который сделал возможным плодить говнокод, абстракции над абстракциями над абстракциями. И наш Hello World соберется в файл на несколько мегабайт, запуск потребует уже под сотню и пару секунд времени, пока стартанет jvm. На железе, которое еще 30 лет назад считалось бы суперкомпьютером. Триумф потре#лядства.
Только если это исходный код программы. Если речь о машинных кодах например это еще как countable. Потому что таких кодов (как чит-кодов в doom) всегда определенное количество.
Концепция автоматического сборщика мусора - самый тупой маркетинговый миф, что можно было придумать. Фактически, если вы не хотите «out of memory» вам нужно ВСЕГДА отслеживать области видимости и где нужно вручную освобождать ресурсы. Последние 20 лет разработки, факапы из-за утечки памяти вижу только на Java-проектах среди секты Свидетелей Сборщика Мусора. 😁
Вот сколько ни встречал программистов, если начинает докапываться до написания/произношения слов (не путать с code style) в первую очередь - так себе специалист. А видео отличное на самом деле (см. соотношение лайков и дизлайков).
