LINUX.ORG.RU

История изменений

Исправление eao197, (текущая версия) :

Разрежённый вектор - это вектор, у которого большинство элементов равны нулю, а ненулевых элементов очень мало. Это определение.

Это не мое определение. В моем случае это вектор, у которого большинства элементов нет вообще (ноль – это легальное значение для существующего элемента).

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

Эта подробность нехило так влияет на то, сможете ли вы вообще что-то сделать на обычном железе или вам потребуется терабайт ОЗУ (а то и не один).

Потому что я как раз таки поставил между ними знак неравенство.

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

А заодно и кучи других языков, у которых дженериков в ранних версиях тоже не было.

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

Зачем тащить в язык то, что нужно лишь в исчезающе малом проценте случаев?

Это можно переформулировать и так: нельзя давать большие пушки тем, кому достаточно возиться в песочнице.

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

Да и вообще, зачем все эти лучшие практики, которые обкатывали в других языках? Ну вот те же алгебраические типы данных и паттерн матчинг? Ведь можно же просто возвращать (x, err) всегда. А затем смотреть, задействовал ли программист err хоть как-то. Не, на у чё? Для 80% случаев прокатит.

Или зачем нужна константность? Или зачем следить за одновременным количеством ссылок на объект?

Большинству же это не нужно. А кому нужно, тот пусть тесты пишет.

Исходная версия eao197, :

Разрежённый вектор - это вектор, у которого большинство элементов равны нулю, а ненулевых элементов очень мало. Это определение.

Это не мое определение. В моем случае это вектор, у которого большинства элементов нет вообще (ноль – это легальное значение для существующего элемента).

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

Эта подробность нехило так влияет на то, сможете ли вы вообще что-то сделать на обычном железе или вам потребуется терабайт ОЗУ (а то и не один).

Потому что я как раз таки поставил между ними знак неравенство.

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

А заодно и кучи других языков, у которых дженериков в ранних версиях тоже не было.

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

Зачем тащить в язык то, что нужно лишь в исчезающе малом проценте случаев?

Это можно переформулировать и так: нельзя давать большие пушки тем, кому достаточно возиться в песочнице.

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

Да и вообще, зачем все эти лучшие практики, которые обкатывали в других языках? Ну вот те же алгебраические типы данных и паттерн матчинг? Ведь можно же просто возвращать (x, err) всегда. А затем смотреть, задействовал ли программист err хоть как-то. Не, на у чё? Для 80% случаев прокатит.

Или зачем нужна константность? Или зачем следить за одновременным количеством ссылок на объект?

Большинству же это не нужно. А кому нужно, тот пусть тесты пишет.