OberonCore

В начале девяностых многие из нас полагали, что главная битва произойдет между процедурным и объектно-ориентированным стилем программирования, и воспринимали объектно-ориентированное программирование как средство резкого повышения продуктивности программистов. Я тоже так думал. Некоторые до сих пор так думают. Получается, мы ошибались. Объектно-ориентированное программирование прикольная штука, но не повышает продуктивность, как это обещалось. Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или «сборка мусора», это может быть Java, Lisp, Visual Basic (даже 1.0), Smalltalk или любой язык написания скриптов. Если ваш язык программирования позволяет выделять кусок памяти без раздумий о его последующем освобождении, то вы используете язык с управляемой памятью, и вы будете значительно эффективней программиста, использующего язык, где управление памятью производится в явном виде. Всякий раз, когда вы слышите чье-то хвастовство о том, насколько продуктивен их язык, вероятно, большую часть продуктивности они достигают за счет автоматического управления памятью, даже если не признаются в этом.

Врезка
Почему автоматическое управление памятью значительно улучшает вашу продуктивность? 1) Потому что вы можете написать f(g(x)) не беспокоясь о том, как освободить память, занятую возвращаемым значением функции g, значит вы можете использовать функции, которые возвращают интересные сложные типы данных и функции, трансформирующие интересные сложные типы данных, что в результате позволяет вам работать на более высоком уровне абстракции. 2) Потому что вам не надо тратить время на код, освобождающий память или отслеживать утечки памяти. 3) Потому что вам не надо аккуратно координировать точки выхода из ваших функций, чтобы убедиться, что память освобождена должным образом.

Языки со сборкой мусора дают не то что описал Спольски, а совсем другое -- невозможность запороть память (герметичность типов).
1) От утечки памяти это не спасает.
2) От необходимости следить за тем когда какой объект уже можно "удалить" (т. е. использовать повторно для других целей) не избавляет тоже.
3) Сложные структуры можно передавать и без сборщика мусора.

Короче, нет порчи памяти - и на этом уже большое спасибо, остальное всё по старинке в рукопашную.

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

Ниче не понял... Поставлю закладочку -- жара спадет, попробую перечитать...

Для прикладников, пишущих настольные приложения

2) Иногда приходится следить за "удалением" объектов чтобы их потом повторно использовать, а не выбрасывать в мусор и лишний раз напрягать GC. Это из-за того, что GC (каким бы крутым он ни был) всё равно работает значительно медленнее случая ручного управления памятью.

Разжую:

Ну вот разве что для них только, местами.

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

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

Четто Илья Евгеньевич пренебрежительно стал отзываться об настольных приложениях

2) Иногда приходится следить за "удалением" объектов чтобы их потом повторно использовать, а не выбрасывать в мусор и лишний раз напрягать GC. Это из-за того, что GC (каким бы крутым он ни был) всё равно работает значительно медленнее случая ручного управления памятью.

Ну почему. Для прикладников, пишущих настольные приложения, дают, в общем-то, всё.
Ну а про остальное, конечно, нам понятно

2) Иногда приходится следить за "удалением" объектов чтобы их потом повторно использовать, а не выбрасывать в мусор и лишний раз напрягать GC. Это из-за того, что GC (каким бы крутым он ни был) всё равно работает значительно медленнее случая ручного управления памятью.

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

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

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

Короче, рабочая сила и деньги есть - и не таких оптимизаций наворотят Доверять буим, или лучше сами? )

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

всё равно они потоки морозят. Вроде бы.

от современных x86 бежать надо как от чумы.