Зачем сборщик мусора?

[valexey]

Во-вторых, там сборщик мусора всегда гарантированно работает линейное время (от размера кучи).

Кто бы мне пояснил... в чём радость от использования сборщиков мусора?..
К примеру, научили школяра/студента писать на oberon, где встроенный сборщик мусора. Устроился этот бывший школяр на работу программистом, а там на C++ пишут или на Delphi... И начались проблемы с протечками. Не лучше ли прививать культуру работы с памятью. Нет же в этом ничего заумного и трудного. Меня не напрягает для программ, где используется много объектов, расписывать карту памяти... это позволяет заблаговременно понять, что же и как, собственно, делается в программе... увидеть узкие места. Такие задачи никакой сборщик мусора за программиста не решит.
Другими словами, наличие сборщика мусора в среде разработки/языке я бы скорее оценил отрицательно... не говоря уже о тех проблемах (тормоза), которые поднял Сергей.

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

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

В-третьих, предыдущие два это фигня на самом деле. Ну, то есть они объясняют зачем в ерланге сборщик мусора, но не объясняют зачем он скажем в XDS-Обероне. Так что вот главный довод - наличие в системе сборщика мусора позволяет массово использовать дешевых программистов, которые без сборщика мусора напишут ужас-ужас. А со сборщиком мусора будет вполне рабочий код.

[valexey]

А, ну забыл еще один пункт - система со сборщиком мусора В СРЕДНЕМ, работает быстрее чем программа со, скажем, подсчетом ссылок (shared_ptr и компания). Но это именно что в среднем. За скорость расплачиваемся отсутствием реалтайма (в случае императивного шарпа например, в ерланге, как я уже писал, все получше - софтреалтайм там имеется, впрочем софтреалтайм это таки не реалтайм ;-) ).

[Geniepro]

Хотя, с лябдами вообще печально если есть мутабельные переменные, ибо получается лямбда-изврат.

В F#, например, в лямбдах просто запрещено использовать мутабельные переменные.
В Хаскелле такие лямбды, использующие мутабельные переменные, автоматически причисляются к действиям ввода/вывода.
Иак что всё таки есть решения этой проблемы...

[alexus]

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

У меня довольно интенсивно используется перезагрузка данных, необходимости в сборщике мусора не возникало... Overlay в типовом программировании сейчас используется очень редко (уже и не припомню, когда в последний раз применял загрузку/выгрузку кода). То есть, это тоже сомнительный аргумент за использование сборщика мусора.
В программах я использую свой менеджер памяти (по сути, обёртка над функциями ОС)... С переходом к 64-разрядным вычислениям, проблем с нехваткой (виртуальной/адресуемой) памяти просто не должно быть.

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

Лямбда - это отдельный разговор... для функциональщиков, а oberon императивный язык, насколько я понимаю.

В-третьих, предыдущие два это фигня на самом деле. Ну, то есть они объясняют зачем в ерланге сборщик мусора, но не объясняют зачем он скажем в XDS-Обероне. Так что вот главный довод - наличие в системе сборщика мусора позволяет массово использовать дешевых программистов, которые без сборщика мусора напишут ужас-ужас. А со сборщиком мусора будет вполне рабочий код.

Те, которые не умеют работать без сборщика мусора, рано или поздно, но всё равно породят "ужас-ужас", поскольку это не вопрос наличия мозгов, а вопрос культуры программирования. Некультурный программист нагадит, не в этом углу, так в другом. Опять же культуру надо прививать в самом начале... (я так думаю)

[alexus]

А, ну забыл еще один пункт - система со сборщиком мусора В СРЕДНЕМ, работает быстрее чем программа со, скажем, подсчетом ссылок (shared_ptr и компания). Но это именно что в среднем. За скорость расплачиваемся отсутствием реалтайма (в случае императивного шарпа например, в ерланге, как я уже писал, все получше - софтреалтайм там имеется, впрочем софтреалтайм это таки не реалтайм ;-) ).

Так я о том, что... проектирование программы - это одно, программирование/реализация - другое. Количество реализаций, которые могут быть хуже данной - неограниченно ничем, кроме фантазии.
Вопрос не в том, как определять объект подлежащий уборке, а в том нужно ли/полезно ли вообще применять GC.

[valexey]

Ну, а такие экстремальные ситуации, как у Сергея, требуют нестандартных подходов...

Это не экстремальные ситуации на самом деле. Как-то так сложилось, что все задачи с которыми я сталкиваюсь делятся на две категории:
1) Простенькие "скриптовые" задачки. Сюда же входят эксперименты с алгоритмами и структурами данных. В этих задачах можно либо вообще не освобождать память (программа отработает много раньше чем память кончится), либо все держать на стэке, либо пользоваться стандартными, скажем stl, контейнерами, которые за меня сами все сделают. То есть задачи где думать о памяти не нужно вообще и без сборщика мусора.

2) Задачи где проблем со сборщиком мусора больше чем без сборщика мусора. То есть идет большая прокачка данных, требуется реалтайм. Со сборщиком мусора приходится бороться (шаманить с настройками, с логикой программы, создавать некие пулы объектов которые засовываются и удаляются из пула естественно вручную (привет malloc/free) - в общем, изврат похлеще чем  без него).

[valexey]

Те, которые не умеют работать без сборщика мусора, рано или поздно, но всё равно породят "ужас-ужас", поскольку это не вопрос наличия мозгов, а вопрос культуры программирования.

Есть ряд задач где программист просто не успевает пострадать от того ужаса который он наворотил - задача оказывается решена раньше, чем все это рухнет. Таким образом, с одной стороны имеем быстро и дешево решенную задачу (хорошо для бизнеса), с другой стороны программист не имеет шанса научиться хотя бы на своих ошибках, появляется некая самоуверенность что "могу все". При этом вырабатывается зависимость от конкретного языка, IDE и сборщика мусора ;-)

Если программисту встретится задачка более масштабная, то проект будет погребен под кучами написанного мусора.

Некультурный программист нагадит, не в этом углу, так в другом. Опять же культуру надо прививать в самом начале... (я так думаю)

Согласен. Самое смешное, что все (или почти все) учебные задачки входят как раз в то множество задач, где при небрежном программировании задача оказывается решена раньше, чем программист успевает пострадать от чудовищ им порожденных.

Поэтому первым языком должен быть какой-нибудь (возможно слегка упрощенный) ужас вроде чистого Си, где можно легко пострадать при отсутствии культуры программирования. Паскаль уже подходит хуже - он навязывает некую культуру программирования, при этом человек так и не поймет ЗАЧЕМ она вообще нужна, эта культура. Оберон подходит еще меньше, ибо там до кучи еще и сборщик мусора, который спасет обучающегося от злых утечек памяти (в учебных программах) и не спасет в реальных задачах.

[DIzer]

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

Скорее проблемы  возникают с замыканиями (если они есть в языке) - точнее, с освобождением "захваченных" ресурсов - к ним же нет глобального доступа.

[valexey]

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

Видимо сборщик мусора таки мешается под ногами людям, ну и необходимости в нем народ не видит.

[DIzer]

У меня довольно интенсивно используется перезагрузка данных, необходимости в сборщике мусора не возникало... Overlay в типовом программировании сейчас используется очень редко (уже и не припомню, когда в последний раз применял загрузку/выгрузку кода). То есть, это тоже сомнительный аргумент за использование сборщика мусора.
В программах я использую свой менеджер памяти (по сути, обёртка над функциями ОС)... С переходом к 64-разрядным вычислениям, проблем с нехваткой (виртуальной/адресуемой) памяти просто не должно быть.

Вообще говоря ДА - ПРИНЦИПИАЛЬНО без мусорозборки, работая в чисто императивной парадигме,  обойтись ВОЗМОЖНО. Но давайте вспомним что состояние замкнутой системы  в императивной парадигме ПОЛНОСТЬЮ описывается набором  значений переменных на каждом шаге выполнения программы - т.е в общем случае -вы должны контролировать значения ВСЕХ переменных - по этому, чем их больше(и они структурно сложнее)  и.или программа содержит большое число исполняемых инструкций - тем сложнее эта задача. По факту, эта способность зависит -от уровня программиста, ЯП, инструментария, сложности задачи. Исходя из этого, очевидно , что мусорозборник позволяет  УСПЕШНО решать БОЛЕЕ сложные задачи конкретному программисту (либо простые но за меньшее время). Отдельная песня программирование СЛОЖНЫХ систем с использованием СТОРОННИХ компонентов, это тот случай , когда вы ПРИНЦИПИАЛЬНО не можете контролировать ВСЕ (компоненты идут в бинарном виде) - каждый из них может содержать до сотни тысяч строк кода (пример - современные GRIDы).

[alexus]

Самое смешное, что все (или почти все) учебные задачки входят как раз в то множество задач, где при небрежном программировании задача оказывается решена раньше, чем программист успевает пострадать от чудовищ им порожденных.

Увы... да.

Поэтому первым языком должен быть какой-нибудь (возможно слегка упрощенный) ужас вроде чистого Си, где можно легко пострадать при отсутствии культуры программирования.

Лучше уж сразу... ассемблер.  Простые учебные задачки... позволяют. Опять же сформируется представление о памяти, вводе-выводе, принципах работы процессора... Вообще, мне всегда казалось, что для обучения лучше всего подходит именно тот путь, которым прошла цивилизация (ламповые вычислительные устройства и программирование перемычками в рассмотрение включать не будем...  ).

Паскаль уже подходит хуже - он навязывает некую культуру программирования, при этом человек так и не поймет ЗАЧЕМ она вообще нужна, эта культура. Оберон подходит еще меньше, ибо там до кучи еще и сборщик мусора, который спасет обучающегося от злых утечек памяти (в учебных программах) и не спасет в реальных задачах.

Паскаль надо давать на следующем этапе сразу после Фортрана/Си... Тогда он смотрится просто здорово!.. Вообще Паскаль - самый успешный проект Н. Вирта. Самым красивым, я бы назвал Модула2, а самым бесперспективным Оберон/Оберон2... IMHO, разумеется. И GC - это частный пример тотальной неудачи.

[DIzer]

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

Видимо сборщик мусора таки мешается под ногами людям, ну и необходимости в нем народ не видит.

Тут опять идет речь об области эффективного и использования ЯП - задачи решаемые  с помощью него СЕЙЧАС, вероятно, вполне могут обходиться без мусорозборника (и есть подозрение , что расширение области его эффективного использования не предвидится) -если это так , то в D мусорозборник можно будет считать ошибкой дизайна ЯП.
Кстати, господа, подспудно возникает мысля - что идея Вирта , о успешном совмещении в одном императивном ЯП качеств системного и высокоуровневого ЯП не очень успешна (получается ни рыба, ни мясо) - хотя Илья Ермаков, вроде говорил преимуществах такого подхода  в своих системных задачах...

[Vartovyj]

Паскаль надо давать на следующем этапе сразу после Фортрана/Си... Тогда он смотрится просто здорово!.. Вообще Паскаль - самый успешный проект Н. Вирта. Самым красивым, я бы назвал Модула2, а самым бесперспективным Оберон/Оберон2... IMHO, разумеется. И GC - это частный пример тотальной неудачи.

Чем Си с точки зрения низкоуровневого программирования принципиально лучше Модулы-2 и в чем безперспективность Оберон/Оберон2?

[Vartovyj]

Сборщик мусора можно было бы заменить каким-нибудь анализатором кода, который бы облегчал программисту правильно организовать этот процесс.

[alexus]

Паскаль надо давать на следующем этапе сразу после Фортрана/Си... Тогда он смотрится просто здорово!.. Вообще Паскаль - самый успешный проект Н. Вирта. Самым красивым, я бы назвал Модула2, а самым бесперспективным Оберон/Оберон2... IMHO, разумеется. И GC - это частный пример тотальной неудачи.

Чем Си с точки зрения низкоуровневого программирования принципиально лучше Модулы-2 и в чем безперспективность Оберон/Оберон2?

В моём сообщении не говорилось о том, что Си лучше Modula-2, в том числе, не говорилось и с точки зрения низкоуровневого программирования.
Перспективность любого средства, и языка программирования, конечно, имеет несколько ключевых критериев:

• Важные, с точки зрения пользователей, преимущества перед аналогами, при успешном решении основной задачи/предназначения;
• Доступность (не только ценовая, но и понятность, документированность и пр.);
• Нацеленность на будущее (возможность развития, в частности, как сбережение инвестиций пользователей... опять же не только денежных, но и времени на изучение, создание собственных и чужих наработок и пр.)

С моей точки зрения ни по одной из перечисленных позиций Oberon не блещет.