don’t pay for what you don’t use

Java например, GC сам решает за что ты платишь и сам решает что тебе нужно. Нэ?

Языки без GC щас используют либо системщики, либо мазохисты, нэ?

Все языки в которых производится проверка выхода за границы массива. Если эта проверка тебе не нужна you'd pay for what you don't use.

мазохисты

Правильно, а за что тогда иначе погромистам платить, что на жопе сидят перед мониторами да кофий прихлёбывают?

ЯП с исключениями, GC.

Исключения могут обрабатываться несколькими способами. Плюсовый — ненагружающий.
Проверка диапазонов массива — зачем?! Кто вообще придумал такой бред? Я предлагаю ещё перед каждый оператором проверять что все переменные равны сами себе.
Сборщик мусора — вообще странная штука, живущая чтобы портить кровь и путаться под ногами.
Просто линковка — при статической линковке в результирующем бинарнике не будет неиспользуемого кода.

Так что этот девиз не на ровном месте появился.

Например написал ты на пайтоне print «Hello world». А он тебе и виртуальную машину подключил, и сборщик мусора подключил и всю многомегабайтную стандартную библиотеку подключил, десятки милллисекунд стартует. Вот это и называется pay for what you don't use.

написал ты на пайтоне print «Hello world»

и всю многомегабайтную стандартную библиотеку подключил

Какой-то необычный пайтон.

Так каким образом питон подключает свою стандартную библиотеку в хелловорлды?

import sys
print "Hello, World!"
print len(sys.modules), sys.modules

Языки без GC щас используют либо системщики, либо мазохисты, нэ?

Любые задачи с кучей вычислений, от игр до фотошопа.

C++ позволяет вообще отключить RTTI если он тебе не нужен, а какой-нить C# тащит всю метаинформацию в рантайм. Ссылки в C++ по сути просто указатели, а в других языках они могут содержать, например, счетчик или еще какую информацию, нужную GC. Если тот же счетчик ссылок потребуется в C++, ты его сделаешь сам (или возьмешь готовый). Это так, пара примеров, что сразу пришли мне в голову, тут можно продолжать довольно долго.

Java например, GC сам решает за что ты платишь и сам решает что тебе нужно. Нэ?

Нэ, ибо

1. Ты платишь за то, что используешь (возможности автоматического управления памятью).

2. ГЦ не соберет больше мусора, чем ты наделал.

3. ГЦ в JVM очень гибко настраивается.

Любые задачи с кучей вычислений, от игр до фотошопа.

С разморозкой вас, игры давно уже на C# (Unity) успешно пишут.

В фотошопах тоже по уму только ядро и GUI имеет смысл писать на системных язычках, а все алгоритмы - на нормальных скриптовых (Ф)ЯП.

Почти все остальные языки.

В C++ если ты создал класс без виртуальных функций(и их нет в базовых классах), то ничего дополнительного для твоего класса не будет сделано. Никаких виртуальных таблиц, никаких ссылок на них в объектах и пр. Почти все языки ведут себя иначе. Если в крестах ты не сделал функцию виртуальной, то вызов будет определён на этапе компиляции, т.е. в рантайме это будет обычный вызов функции(почти как в си). Никаких GC, если ты не подключил какие-то библиотеки для этого и не использует их. Никаких подсчётов ссылок, если ты сам не используешь соответствующие типы указателей. Никаких тредов, если ты не просил их. Никаких проверок выхода за границы массивов, пока ты не захотел их. И т.д.

Т.е. фичи проектируются так, что в случае их отсутствия в коде, ты не платишь за них ничем, как-будто их и не было.

Так же в Си(но там фичей практически и нет, а добавляются они плохо, нет средств для построения абстракций). В Rust стараются, но не уверен, что у них получается. D более-менее соответствует(но там без GC тяжело работать). В остальных языках ты будешь платить за сборку мусора, виртуальность вызовов, проверку выхода за массив и пр. и пр., хотя в твоей задаче это может быть не нужно или будет как из пушки по воробьям.

Ты платишь за то, что используешь (возможности автоматического управления памятью).

Почему я должен платить за возможность? Это уже нарушает принцип. Я хочу платить за использование, а не возможность ;)

ГЦ не соберет больше мусора, чем ты наделал.

А если я его не наделал? ГЦ ведь все равно запустится, да? А если я не хочу собирать мусор(для моей задачи это не имеет смысла)?

ГЦ в JVM очень гибко настраивается

Я могу его выключить? И если да, то могу ли я вручную управлять памятью? А организовать полуавтоматический детерминированный сбор(типа подсчёта ссылок)?

игры давно уже на C# (Unity) успешно пишут.

Мало и под мобильные платформы, в основном. И игры соответствующие.

В фотошопах тоже по уму

Ну это ваше мнение, пока не совсем так.

только ядро

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

Этот девиз верный, но кресты, высранные недоумком и двоечником страусом ему не соответсвуют. Проверка выхода за границы массива обязательно должна быть в языке (и согласно этому девизу отключаемой ключом компиляции). GC может и должен быть частью любого нормального языка (опять же отключаемым). Но недоносок страус очевидно ниасилил всего этого и поэтому все 30 лет вешает лапшу на уши своим девизом.

Нет. Проблема в тебе.

GC может и должен быть частью любого нормального языка (опять же отключаемым).

Т.е. ключик компилятора превращает язык из нормального в ненормальный? Прэлесно.

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

Я хочу платить за использование, а не возможность

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

А если я не хочу собирать мусор(для моей задачи это не имеет смысла)? Я могу его выключить? И если да, то могу ли я вручную управлять памятью? А организовать полуавтоматический детерминированный сбор(типа подсчёта ссылок)?

Ты по-моему не понял, в чем мой пойнт. Я не говорил, что на яве можно делать то же, что на цпп. Я спорил с утверждением, что в яве ты платишь за то, что не используешь. Еще раз. Когда ты выбираешь, на яве или на плюсах тебе решать задачу, у тебя два варианта сочетаний «фича/кост»:

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

2) либо ты используешь полностью (плюс-минус) автоматическое выделение и освобождение памяти под свои объекты и почти не думаешь о том, где там что потечет, резко улучшается сопровождаемость и уменьшается количество багов, связанных не с логикой работы приложения, и твой кост за это - определенное увеличение потребляемой памяти, ресурсов, тормоза и паузы при плохо настроенном ГЦ и т.д.

В любом случае есть то, что ты используешь, и то, что ты за это платишь.

С проверкой выхода за границы массива можно поспорить.

Массив == указатель, а обращение по индексу это сложение индекса с указателем — это импринт C(++)-утят.

В языках с проверкой ты соглашаешься на проверку указывая размер массива.

Тут вопрос в том, что называть массивом. И если в разных языках массивом называют немного разное, то это ещё не значит что ты платишь за то, что не используешь.

И если да, то могу ли я вручную управлять памятью?

Могу я в C++ передавать this в EDX, а не ECX?

если в разных языках массивом называют немного разное, то это ещё не значит что ты платишь за то, что не используешь

Что-то я вообще не понимаю о чём ты. На самом деле всё просто - в некоторых языках за тебя давно решили что тебе нужна проверка выхода за границы массива и соответственно ты платишь за неё даже если она тебе не нужна. При этом как там называются массивы неважно. В Си/С++ нет, если не нужна можешь ничего не платить и выстрелить себе в ногу ничего не проверять. Что не понятно то?

C# тащит всю метаинформацию в рантайм

Подозреваю, что это особенность платформы .NET.

«C++ использует стек для вызова функций, хотя я нигде в программе не создаю объект `стек'» — нельзя же это считать нарушением don’t pay for what you don’t use.

Проверка диапазонов массива — зачем?! Кто вообще придумал такой бред?

Интел даже подобное процессорное расширение пилит, так сильно индустрии это нужно.

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

Кто-нибудь знает языки, где ты платишь за то, что не используешь и как конкретно это проявляется?

PHP, там вся локальная область видимости забита (где-то 5000 слов) и чертова тонна ф-ций дублирующих себя

Считай JVM — это процессор.

Ты пользуешься внешним знанием о том, что JVM реализован на C/C++, а не в железе и поэтому считаешь проверку на выход за границы массива наружением don’t pay for what you don’t use.

Если относиться к JVM без оглядки на то, как оно реализовано, то считай что массивы с проверкой на выход за границы — это такой нативный тип данных процессора, для которого компилируется Java. В таком свете проверка не выглядит нарушением don’t pay for what you don’t use.

В любом случае есть то, что ты используешь, и то, что ты за это платишь.

Нет же. И дело не в «так же, как в крестах». Дело в том, что ты платишь за то, что тебе не нужно. Например, моя программа может не создавать мусора. Такое бывает, скажем, припостроении какой-нибудь аналитики, графов и пр. В яве я буду платить за сборщик, я не могу за него не платить. И это лишь один из примеров.

В таком свете проверка не выглядит нарушением don’t pay for what you don’t use.

Да, если вычисления проводятся с помощью огромных булыжников, катаемых рабами, то катание булыжников при расчётах не выглядит нарушением don’t pay for what you don’t use.

О-кей. Вот я в C++ вылез за границы массива и получил segfault, т.к. у меня страница не отображена в память. Почему я плачу за страничную память, когда я её в программе нигде не программировал?

Wheeee, C++ нарушил don’t pay for what you don’t use!!!111111111адынадын

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

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

C++ нарушил

Ок, давай теперь катать булыжники при расчётах. Нарушать так нарушать!

То есть ты согласен с тем, что проверка на выход за границы — это не нарушение принципа don’t pay for what you don’t use.

Следующий.

Ты говоришь о выборе языка, а тема о поддержке принципа в языке. Одном отдельно взятом языке. В C++ я не плачу за то, что не использую. В Java я плачу за все, вне зависимости от того, надо оно мне или нет.

В C++ нет понятия ecx и edx, равно как не описан способ передачи this.

Но это offtop. Смысл в том, что в java я вынужден платить за сборщик, вне зависимости от того, нужен он мне или нет, использую я его или нет.

В C++ нет понятия ecx и edx, равно как не описан способ передачи this.

В Java нет понятия «управление памятью, указатели», равно как не описан способ реализации ссылок.

Зато там описан сборщик мусора. А все остальное для темы не существенно.

Зато там описан сборщик мусора

Где — там?

«don’t pay for what you don’t use» - принцип С++ при добавлении новых фишек в С. Если рассматривать его (принцип) сам по себе, в отрыве от контекста (Си), то он и в правду двояко трактуется.

GC может и должен быть частью любого нормального языка

Братишка, а вот расскажи мне, чем GC лучше shared_pointer'a?

Исполняй свою программу напрямую на камне в режине noOS и не будешь платить за страницы памяти.

Подозреваю, что это особенность платформы .NET.

Это не особенность, это необходимость для reflection, которую разработчик может и не будет использовать в конкретном проекте.

Братишка, а вот расскажи мне, чем GC лучше shared_pointer'a?

shared_pointer это жалкая пародия на GC. страусиха должна была сначала реализовать нормальный опциональный GC и только потом хвастасться, что C++ не навязывает того, что программисту не нужно. то же самое с проверкой на выход за границы диапазона. а это вообще напрямую связано с безопасностью. то есть страус обосрался минимум дважды.

shared_pointer это жалкая пародия на GC

Братишка, а вот расскажи мне, чем GC лучше shared_pointer'a?

тебе уже сказали, что наличие самой проверки не нарушает принципа don’t pay for what you don’t use. нарушает принцип невозможность ее отключить, либо невозможность использовать другие способы прямой работы с памятью. в этом плане .NET соблюдает этот принцип. там можно работать с указателями напрямую, без контроля выхода за границы.

Ты нихрена не понял :(

продолжай дальше говнокодить дырявое ПО на ссах и крестах, потому что какие-то безмозглые ушлепки нагло присвоили, не понимая смысла, этот девиз. это да, плюсатные быдлокодеры не платят за то, что не используют. за это платят миллиарды другие, в очередной раз оказываясь жертвами переполнений буфера и use after free.

С разморозкой вас, игры давно уже на C# (Unity) успешно пишут.

Именно поэтому у игр на нём, видимо, репутация, СЛОУПОКОВ.