Ычан: [d | b / bro / hr / l / m / mu / o / s / tran / tu / tv / vg / x | a / aa / c / fi / jp / rm / tan / to / vn]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 21353)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, WEBP, XCF, ZIP размером до 5120 кБ.
  • Ныне 3657 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 500
civilized_argument_popukko.jpg - (63.68KB, 720×720)
21353
No. 21353  
Попробуем создать нить, в которой уважаемые разработчики могут поспорить на любые темы:

— Какая IDE удобнее?
— Какой язык лучше?
— Какой фреймворк православнее?
— Agile или не Agile?
— ООП нужно, или не нужно?
— Настоящий разработчик вы, или нет?

Здесь разработчики смогут невозбранно обсудить эти, и другие животрепещущие а иногда и извечные темы.
87 сообщений пропущено. Показаны 50 последних сообщений
No. 25400  
>>25399
GC к функциям не привязывается. У меня такое ощущение, что все в этом треде друг друга не понимают.
>Веруйте, кто ж вам запретит-то.
Хотя зачем понимать, когда можно просто покидаться чванливством.
No. 25402  
raccoon-4004766_1920.jpg - (601.06KB, 1920×1276)
25402
>>25399
Есть стек вызовов функций или блоков кода, не суть (зависит от языка). Локальные переменные и константы, в том числе not-null, прекращают существовать, когда блоки кода (или функции, зависит от языка), в которых они объявлены, доходят до конца, т.е. когда исчезает этот scope.

Это ответ на вопрос, как GC может подобрать объект, который находится в not-null-переменной. После того, как она исчезнет.

Синглтоны я упомянул не совсем к месту, хотя отчасти к месту, как предельный случай, чтобы показать, что обычно всё связано со стеком вызовов. Если синглтоны создаются IoC-контейнером, то они также находятся в какой-то коллекции, которая находится в каком-то скоупе, который также по идее должен исчезнуть незадолго до завершения программы.

Конечно, можно объявить нечто совсем не привязанное к стеку. Классический синглтон, который сохраняется в статическую переменную, по идее не удаляется никогда, пока программа не остановится, но так почти никто не кодит.

А вообще, да, GC что-то там мутит с графом взаимосвязей объектов, наверно. В Википедии можно почитать в статье Сборка мусора, как достижимость работает в mark-and-sweep (я не специалист).

Если какие-то объекты были достижимы только как поля объекта, ссылка на который была только в локальной переменной, которая больше не существует, то можно по идее собрать все эти объекты.
No. 25404  
>>25402
>GC что-то там мутит с графом взаимосвязей объектов, наверно.
Ты прав. Используются алгоритмы, похожие на Dijkstra's on-the-fly algorithm
https://lamport.azurewebsites.net/pubs/garbage.pdf
No. 25405  
>>25402
Если доступ к объекту осуществляется по ссылке, то единственный способ убить объект в языках без прямого доступа к памяти — это присвоить ссылке другое значение. Это вроде бы элементарно. Для этого обычно используется null. Но вы null запретили. Единственный выход у вас — это создать в статике объект-константу специально скостыленного подкласса, который будет заменой null. Но теперь вам надо проверять, не является ли какой-либо объект этой заменой. От чего бежали, к тому и пришли.

У взрослых, т.е. в Аде и Яве not null (@NotNull) — это по сути хинт для компилятора, заставляющий его пихать в нужные места код проверки на null и выбрасывания исключения. Область же применения ограниченных ссылочных типов, вроде
type ObjectAccess is not null access all Object'Class;

крайне ограничена.

Также хочу заметить, что ни один проект не делается с нуля, т.е. в любом проекте достаточно кода, который вы не контролируете. Отсюда любой объект, передаваемый по ссылке, который создан не вами, надо проверять на null.

Лол. Как с вами сложно.
No. 25406  
>>25394
> Зачем в этом случае программисту думать, что и когда ему обнулить (очистить)?
Так вот отчего некоторые категории современного софта сжирают столько памяти даже на самый элементарный функционал? Ясно. Понятно. Действительно, зачем думать.
No. 25407  
>>25406
А в чем проблема, чванливая няша? Ты пишешь, держа в уме gc, а не беспокоишься в каком месте поставить free. Прогресс не стоит на месте и на дворе не 2005. А память утекает не по этой причине, ты это прекрасно понимаешь, я надеюсь
No. 25408  
raccoon-anger.jpg - (91.24KB, 492×482)
25408
>>25405
>единственный способ убить объект в языках без прямого доступа к памяти — это присвоить ссылке другое значение

Да не единственный этот способ.

Допустим, есть методы
void doSomething() {

    A a = new A();
    // Что-то делаем.
}

void doSomethingElse(B b) {
    // Что-то делаем c b.
}


Есть некий другой метод. Неважно, в том же классе или нет.
void sdf() {

    doSomething();  // создалась ссылка "a"
    // Ссылка "a" больше не существует.
    // Мы ей не присваивали null, но это и не важно,
    // ведь её больше нет.

    // Ссылка zxc копируется в ссылку "b".
    doSomethingElse(this.zxc);
    // Ссылка "b" исчезла.
}

No. 25409  
>>25407
> чванливая няша
Зато не вруша, смешивающая взаимоисключающие параграфы.
No. 25410  
>>25409
Ну, во-первых, "зато" вряд ли уместно. Во-вторых, никакого смешивания не подразумевалось.
No. 25413  
>>25406
CGI-bin-щикам проще микросервис перезапустить, чем разбираться с памятью. Это у них уже проф.деформация. Ну привык человек всю жизнь гвозди камнем забивать.

>>25407
Я пишу, держа в уме механизмы работы с памятью конкретного языка. GC, malloc, счетчик ссылок. Все эти механизмы имеют четко определённые алгоритмы работы. Ни один из этих механизмов не является аналогом pizdato_lib, т.е. не умеет додумывать за программиста, что делать.

>>25408
В вашем мире проектов уровня laba1 не используются коллекции, многопоточность, сторонние библиотеки; там не надо хранить объекты между запросами, потоками, сессиями; там не порождаются объекты на каждый чих, даже коллекции копий самих себя не создают? Какой чудесный и простой мир!

З.Ы.: Я понимаю, о чём вы говорите, но к реальным проектам это не имеет никакого отношения, увы , если только вы не пишете системы управления для аэро-космической отрасли в стандарте Ravenscar, где ссылки и динамические объекты в бане — тогда делаю реверанс: написать на SPARK-е программу, которая компилируется — это само по себе достижение, можно лечь в гроб и спокойно умереть.
No. 25414  
>>25413
Забудь про cgi, это говно мамонта, к микросервисам не относится.

Я полностью согласен про четкий алгоритм работы и что gc не делает pizdato. Gc делает gc, и если не вставлять ему палки в колеса, он прекрасно будет делать свое дело.
No. 25415  
dog-days-026.jpg - (334.51KB, 1280×720)
25415
>>25414
GC подбирает лишь те объекты, которые он не видит со стэка. Он не может угадать, что вам этот объект больше не нужен. Время жизни объектов, если выйти за рамки студенческих лабораторок и CGI-Bin, может исчисляться годами. Даже на поганом ведрофоне приложения расчитаны на длительную работу в фоне.
No. 25416  
>>25415
Тебе выше отвечали, что ничего угадывать не нужно.

И опять cgibin? Тебя он в детстве покусал?
No. 25418  
>>25416
У вас аргументация человека, который никогда не задумывался, как сохранить или передать данные между запросами или потоками; у которого любая программа всегда имеет чёткий вход и четкий выход; и который всегда точно знает, что и где он создал. Это программы вида «посчитать и вывести результат», т.е. утилиты командной строки, лабораторки или скрипты CGI-Bin, вроде вакабы и кусабы.
No. 25420  
>>25418
У тебя аргументации совсем нет. Да и мимо по всем пунктам
No. 25424  
>>25413
> В вашем мире не используются коллекции,

А что с ними не так? Чем коллекция принципиально отличается от любого другого объекта, во-первых? Это обычный объект, который хранит ссылки на другие объекты, иногда в массивах.

> даже коллекции копий самих себя не создают?

В джаве вроде нет такого. Кто-то снаружи коллекции всегда создаёт её копию.

> многопоточность,

У каждого потока свой стек вызовов. В чем проблема?

> сторонние библиотеки;

Библиотека библиотеке рознь. В них тоже работает тот же самый GC.

> там не надо хранить объекты между запросами, потоками, сессиями

Я выше вроде писал static-переменные, например. Хотя, конечно, в CRUDах чаще скидывают данные в БД между запросами. Конечно, могут кэшироваться некоторые вещи фреймворком еще. Как это устроено, хороший вопрос, конечно.

Проблема спринга и хибернейта в том, что они аккумулировали в себя уже критическое количество магии™. Сейчас вот открыл один проект на Spring Boot, и пытаюсь разобраться.

С точки зрения меня, основная точка общения с БД - это интерфейсы, расширяющие JpaRepository. Спринг их находит на этапе запуска и создаёт для них скорее всего SimpleJpaRepository, который использует EntityManager, который берётся из entityManagerFactory. И результирующий JpaRepository, и entityManagerFactory - это синглтоны, которые лежат в ApplicationContext, который берёт бины из поля beanFactory типа DefaultListableBeanFactory, который расширяет DefaultSingletonBeanRegistry, который там внутренне хранит сингтоны в ConcurrentHashMap. И всё это без static-полей.

Сам ApplicationContext создаётся как локальная переменная в главном методе фреймворка (см. приложенную картинку). В общем, судя по коду, он никогда не уничтожается. Даже когда метод run завершится, контекст вернётся как возвращаемое значение. Быстрее программа завершится, чем GC подберёт ApplicationContext, и неважно, куда он там дальше пробрасывается.

Дальше, как устроен кэш. В JPA есть два уровня кэша.

Кэш первого уровня - это такая штука, которая в рамках текущей транзакции позволяет, еще не сохраняя состояние объектов в базу, получая изменённый в этой сессии объект через другой запрос, получить не состояние из базы, а состояние, которое предстоит в базу сохранить. https://stackoverflow.com/a/22732345/1240328

Там черт ногу сломит, как это реализовано в хибернейте. Похоже, что entityManager - это потенциально долгоживущая/вечная штука (их может быть много в проекте). В хибернейте ее реализация - это SessionImpl, которая хранит потенциально вечный StatefulPersistenceContext, который по каким-то сложным правилам хранит в коллекциях (там их много) закэшированные сущности, чистит их по завершению транзакций и т.п. Причем никакой синхронизации потоков я там не нашел... Значит ли это, что сессия гарантировано привязана к потоку. Честно говоря, слегка подзавис на этом вопросе.

Что касается кэша второго уровня, то это кэш, отделённый от сессии. Т.е. он хранит detached-сущности, причем, в зависимости от реализации, он может хранить их даже за пределами java-кучи, т.е. где нет GC, а по запросу создавать объекты в куче, получая данные из этого некоего места. В джаве есть встроенные механизмы выделения оперативной памяти за пределами кучи: https://blogs.oracle.com/javamagazine/creating-a-java-off-heap-in-memory-database
No. 25425  
Есть попытки переписать Spring заново, уменьшить количество внутренней магии, сделать compile-time DI.
Модные-молодёжные Java-фреймворки:
Я сам пока не пробовал, не разбирался.
No. 25427  
Да, кстати, вот это вот off-heap хранение сделано по очевидной причине. GC, так скажем, не очень быстро работает, когда куча разрастается до двузначных гигабайтов.
No. 25428  
shocked-anime-face.jpg - (55.23KB, 1280×720)
25428
А о чем спор? Нужен ли нулл? Нужен ли сборщик мусора? Чем была хороша Ада? Почему настоящие программисты не используют Котлин?
No. 25429  
>>25428
> не используют
Используют!
No. 25430  
2011-05-27-407284.jpg - (152.09KB, 700×1000)
25430
>>25424
Вас куда-то не в ту степь понесло... Мой пойнт заключается в том, что за пределами пары Ada/SPARK и аэрокосмической отрасли весь этот аутизм с ограниченными ссылочными типами тупо не работает, поскольку на одну строку вашего кода приходится сотня строк чужого, который вы не контролируете. Коллекции — самый простой пример такого кода, ни один проект без них не обходится.

Ну и если говорить про Аду, фишки из которой традиционно тырили себе Плюсы и Ява, то в ней типы порождаются где угодно в коде, так что там не является проблемой создать новый тип, локальный для одной из ветвей условия в обработчике исключения локального блока в методе doSomething, и повертеть на причинном месте ограничения при помощи Unchecked_Conversion. Если вы этот аутизм с ограниченными типами хотите внедрить в свой ЯП, то вы должны внедрить также и всё остальное, включая встроенный в скоупы try-catch. Ну или вы отказываетесь от аутизма и делаете not null просто хинтом для компилятора, заменяемом на if (o == null) throw new NullPointerException ();

>В джаве вроде нет такого
ЕМНИП, какой-то из reverse-ов возвращает копию списка; какой-то из итераторов для деревьев создаёт список и перемещается по нему. Не говоря о том, что коллекции могут хранить и возвращать null.
>У каждого потока свой стек вызовов. В чем проблема?
Объекты общие, т.к. потоки банально должны обмениваться информацией. К тому же поток может работать в бесконечном цикле, обрабатывая запросы. Хуже того, он может порождать другие потоки.
>Библиотека библиотеке рознь.
Как правило, у вас есть одна библиотека, которая возвращает null. Этот кактус вам грызть весь проект.

PersistenceContext-ов существует три вида: управляемый контейнером транзакционный (для SlSB), управляемый контейнером транзакционный расширенный (для SfSB), управляемый приложением (для JavaSE окружения и рукоблудия). EntityManager не является thread-safe. EntityManager ассоциируется или с уже существующим PersistenceContext-ом, или с вновь созданным. EntityManager использует одно соединение с базой, потому не может быть @ApplicationScoped. Отвечая на ваш вопрос
>Значит ли это, что сессия гарантировано привязана к потоку.
В случае управляемого приложением это зависит от самого программиста. В случае управляемого контейнером привязка идёт ко времени жизни EJB (транзакция здесь всегда коммитится). Время жизни SfSB ограничено лишь временем жизни самого приложения: если он не убивается по @Remove, он живёт пока на него есть хоть одна ссылка; ассоциированный с ним PersistenceContext живёт столько же, кроме того, может наследоваться другими SfSB.

>>25428
Честно? Не знаю. Я говорю про ограниченные типы в ЯП, мне говорят про JPA и Spring.
No. 25432  
Wanted_Raccoon.jpg - (165.38KB, 1117×954)
25432
>>25430
>Как правило, у вас есть одна библиотека, которая возвращает null. Этот кактус вам грызть весь проект.

Ну так я не предлагаю объять необъятное. Есть наш какой-то модуль. Мы знаем, что для него получить null на вход - бессмыслица. Почему бы не гарантировать во время компиляции (может хинтами, хотя на мой взгляд лучше самим ЯП), что мы не сможем ему передать null на вход, и чтобы внутри модуля была такая типа чистая комната от отсутствующих значений.

Жаль что так же нельзя сделать, ограничивая в компайл-тайме диапазоны целых чисел, например. Тогда бы действительно какой-нибудь квантовый компилятор был бы нужен, чтобы всё все возможные выполнения просчитать. Сейчас прибегут хаскелисты и скажут, что у них это уже реализовано.
No. 25433  
>>25432
Вы действительно считаете, что это — весело? Попробуйте Аду тогда, и её подмножество SPARK с нескучными фичами.
No. 25434  
>>25433
На что тут ещё обратить внимание?

Типы Length и Coord производные от типа Count и наследуют его методы, однако промеж них нельзя делать арифметику напрямую, поскольку по умолчанию не определены арифметические операторы для аргументов разных типов — грубо говоря, надо ещё пару десятков функций прописать вида function "+" (Left: Coord; Right: Length) return Coord. Зато их можно конвертировать друг в друга т.к. они одного диапазона значений. К сожалению типы не всегда возможно безопасно сконвертировать друг в друга, так что приходится по ходу пьесы инстанциировать дженерик-функцию Unchecked_Conversion. Это первое.

Второе, выстроить иерархию типов, которыми реально будет удобно и безопасно пользоваться в проекте на порядки сложнее, чем выстроить иерархию классов и сущностей.

Третье, арифметику никто не отменял, так что умножение Length на Length может выдать вместо Length исключение Constraint_Error. Эта проблема при строгой типизации практически нерешаема, но для серии арифметических операций добрый адский компилятор сначала сконвертит все типы в какой-нибудь Long_Integer, посчитает и уже потом решит, кидать ли исключение. Однако, эта магия не работает при переопределении операторов.
No. 25435  
>>25434
Не, ну с исключениями, это не серьёзно.
No. 25436  
>>25435
Тогда у вас любая функция вида function "*" (Left, Right: T) return T при любом ограниченном типе T нелегитимна. Максимум, что вы можете сделать для того, чтобы реабилитировать её, — это написать ей контракт посредством расширений SPARK-а. Можете подумать, кстати, на досуге, какими будут условия контракта, чтобы функция стала легитимной.
No. 25437  
>>25436
Ну я и говорю, что с числами это не сработает. Но если просто как бы включить нуллабельность в T, то никаких проблем нет.
No. 25887  
Digital Design and Computer Architecture, RISC-V Edition
Мнения?
No. 26348  
image.png - (258.88KB, 540×540)
26348
Delphi или Lazarus?
No. 26437  
000def15_134140.png - (1.15MB, 1280×720)
26437
Я вот не понимаю, Стиви.

https://gist.github.com/paulirish/5d52fb081b3570c81e3a
> Avoiding layout thrashing — Web Fundamentals The best resource on identifying and fixing this topic.
> https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing
Гугель публикует советы, делает perfomance measuring tool для своего браузера... А где это всё? Внутренние страницы хрома — настройки, история, букмарки — томрозят как не в себя, и это при том что оперируют с локальными данными.
Чем занимаются все эти люди прошедшие 10 кругов собеседований про алгоритмы, структуры, паттерны, люки и шарики, заполняющие автобус?
No. 26438  
>>26437
Почиванием на лаврах. Когда столько всего уже прошел, делать потом ничего не хочется.
No. 26439  
>>26438
Хитро. Устроиться в богатую корпорацию и саботировать. Впрочем вспоминаются те статейки смешных недовольных: мне хорошо платили но можно ничего не делать, мои идеи не никому не были интересны и мне скучно, я уволился.
No. 26440  
>>26439
В богатых корпорациях с 10 кругами часто действуют подпольными методами и устраивают новых сотрудников на какую-нибудь полную хрень проекта, чтобы проверить, в первую очередь на предмет шмионства. Возможно именно отсюда растут ноги у "можно ничего не делать" и "мои идеи никому не были интересны". Хотя растянутость бюрократических процессов и имитацию бурной деятельности на всех его этапах тоже никто не отменял.
No. 26441  
— Какая IDE удобнее?
Не знаю, не пользуюсь.
— Какой язык лучше?
С++
— Какой фреймворк православнее?
Qt
— Agile или не Agile?
Не знаю что это.
— ООП нужно, или не нужно?
Нужно.
— Настоящий разработчик вы, или нет?
Нет.
No. 26453  
Это нормально, что взрослый солидный дяденька-шарпист смотрит на тебя как на полубога, когда ты показываешь как работают деструкторы в C++?

Мы просто случайно познакомились бухими на улице, а потом пошли к нему домой писать код
No. 26458  
>>26456
Как минимум, это приятно.
No. 26520  
>>26458
Если честно, то чувствуешь себя скорее вот так: https://youtu.be/HKbMYl-a1SE
No. 26526  
>>26348
Хотел бы вкатиться, но пугает неясность карьерной перспективы, скажем так.
No. 26539  
>>26526
При том что язык очень нравится.
No. 26550  
>>26539
Мой знакомый делфист занимается в основном переписыванием или починкой старой кодбазы, уже много лет.
No. 26557  
>>26550
Как я понимаю даже теоретически только этим и можно заниматься на этом языке.
No. 26575  
>>24683
Весьма, но лучше перекатиттся в 3d max, я понимаю, что ответ тебе уже не очень нужен, но пусть будет.
No. 26600  
Не так давно обратил внимание на странную вещь.
Код, написанный всякими левыми индусами, зачастую, оказывается понятнее для чтения, чем творения мастеров. Особенно, если ты сам новичок в теме.

Да, он продублировал одно и то же 100500 раз. Но зато — всё собрано в одном месте, не надо продираться через паутину абстракций. Сразу видно, что он имел в виду.

Правда, всё это — ровно до тех пор, пока индус сам не наткнется на что-то абстрактное… а потом ты хватаешься за голову, увидев, что он для каждого объекта целиком продублировал огромную библиотеку. Старательно всё переименовывая. Там, где достаточно было одной строчки кода, ага…
No. 26603  
>>24675
Всё так.
No. 26604  
>>26603
просто соглашаться не интересно
No. 26726  
Облизываются ли джависты на скалу как это делают сисярписты на фаршик?
No. 26727  
>>26726
Зачем облизываться, они ее наминают!
No. 26741  
>>26726
Джависты игнорируют ее в целом, до сих пор.
No. 26795  
kotlin_scala.png - (575.18KB, 1920×1546)
26795
>>26726
Удалить сообщение []
Пароль  
[Mod]