Бизнес, конечно, думает о прибыли и ему действительно проще докупить серверов, но у нас и десктопные приложения никуда не делись, как с этой проблемой быть?
А еще есть ощущение, особенно это касается веба, что замедление кода обгоняет ускорение железа в последнее время. Если такая тенденция будет продолжаться, то разница между хорошо и плохо написанной программой может стать настолько большой, что эффективно написанный код может стать конкурентным преимуществом.
А это не задача программиста, а задача оптимизирующего компилятора, на минуточку.
Если вы создадите список и достаточно долго будете добавлять и удалять элементы в него, то получите кашу в памяти и оптимизирующий компилятор с этим фактом ничего не сделает. Речь, очевидно, об этом.
Стоит также вспомнить про принципы пространственной и временной локальности - если выборка из памяти идет по одному адресу, то с большой вероятностью следующие выборки будут идти по соседним адресам. На этом, собственно, и построено считывание линейками.
Не совсем. Вы можете хранить список больших блоков разрозненно и такая структура данных удовлетворяет пространственной и временной локальности хорошо, если блоки достаточно большие и используются достаточно полно при каждом доступе. А если все это еще и лежит в массиве, то получаем некоторый бонус в виде идеального data prefetch.
Коэффициент попаданий в кэш сейчас - 96% или больше (ну, от размера кэша зависит, конечно).
И от эффективности маркетологов - положите данные в память неудобным для процессора образом и у вас и близко такой цифры не будет.
Да, почти всегда упрощает восприятие и сокращает расходы неимоверно. Особенно, когда есть большие размашистые деревья классов с 5-ю и более уровнями наследования, а если все это еще присыпать множественным наследованием, ухх... Настолько все упрощает, что в одной из компаний, в которой я работал, пришлось руками бедных программистов развязывать этот гигантский гордиев узел и переписывать все.
Вы, видимо, имеете ввиду динамический полиморфизм в Linux ядре. Но он есть и в Haskell и в Rust, но ни тот ни другой не поддерживает ООП (нет наследования).
Как минимум мы имеем инкапсуляцию(модули), полиморфизм(интерфейсы). (И с каждой версией все больше и больше накручивают, дженерики(параметрический полиморфизм), кастомные итераторы(перезагрузка операторов)).
Инкапсуляция и полиморфизм существуют не только в рамках ООП. И я не видел ни одного определения ООП в которое входил бы параметрический полиморфизм или уж тем более перегрузка операторов.
Какую серебряную пулю я продаю в статье?
ООП — это скам.
Серебрянная пуля - универсальный метод решения всех проблем. Скам - не метод решения проблем. Если используете клише, то хотя бы семантику не нарушайте, а то вдвойне тошно.
Хорошо, а если мы хотим не по всему контейнеру искать? У меня такая задача часто возникает. Можно конечно дублировать функцию, но зачем, если вариант с методом класса реализует частный случай и не обобщаем (без потери удобства)? Реализовывать весь набор основных алгоритмов для каждого контейнера - это куча бойлерплейт кода.
Очередная статья от человека, который не разобрался в современных возможностях языка, но который смело заявляет:
Честно говоря, я даже не могу вспомнить что там в последних версиях было. Просто какая-то тарабарщина, малоприменимая в моей реальности
Моя самая "любимая" древность в языке - это инклюды. Честно говоря это похоже на какое-то издевательство. Я понимаю как к этой идее пришли несколько десятков лет назад. Но почему это существует до сих пор?
Уже в C++20 появились модули, решающие многие проблемы инклудов. Да, поддержка не везде и неполная, но в GCC уже большая часть предложений реализована.
Лично для меня еще существенным минусом является вынесение общих функций наружу, вместо использования их как функций‑членов класса. Мне, например, гораздо проще и очевиднее вызвать myVector.find_if() через точку, чем вызывать ее как внешнюю функцию с передачей итераторов внутрь:
А если захотим написать свой stl-compliant контейнер и реализовать для него find_if? Писать с нуля?
необходимость передачи .begin()/.end() в большинстве случаев. Это удлиняет и засоряет синтаксис
См. std::ranges.
Далее, что касается SFINAE: значительная часть задач, решаемая этим, кхм, механизмом теперь решается концептами. Да, не полностью, но прогресс большой. Это же позволило улучшить и сообщения об ошибках.
Это отключаемая фича в С++, но по-дефолту она включена и многими используется. Многими программистами С++ она воспринимается как бесплатная, однако при включении RTTI постоянно происходит скрытая работа в рантайме.
Так это проблема программистов, а не языка получается? Отключаем RTTI и довольствуемся zero overhead.
Что-то в этой статье все напутано с модальностями will и to be going to.
— I will do my homework tomorrow. — Я сделаю домашнюю работу завтра.
Здесь will выражает спонтанно принятое решение сделать работу. Это достаточно твердое намерение (фактически обещание) и оно не эквивалентно
— I suppose I will do my homework tomorrow.
т.к. suppose вносит элемент неуверенности.
Далее:
— I’m going to do my homework tomorrow. — Я собираюсь сделать домашнюю работу завтра.
Здесь to be going to отражает то, что действие было запланировано до момента высказывания. При этом план может поменяться и поэтому намерение здесь не такое твердое, как в случае с will.
Мы не только не можем утверждать, что наш разум в целом (не мозг, а все сознание) работает по некоторым алгоритмам, но нет даже намека на понимание того, как его формализовать. Есть достаточно аргументов в пользу того, что этого сделать вообще не возможно, хотя кто знает.
Если нужны математически обоснованные аргументы, то можно почитать Пенроуза (Новый ум короля, Тени разума). А так и без математики видно, что сознание имеет какую-то принципиально иную природу, нежели материя, а значит и выразить его через классические алгоритмы вероятно нельзя, поскольку любой алгоритм предполагает наличие некоторого изменяющегося состояния, которое нужно где-то хранить (а где, если не в материи?). Даже если мы говорим о чистой функции, все вычисления происходят в некотором материальном объекте. При этом столь же очевидно, что оба феномена взаимосвязаны - материя, или скоре результаты взаимодействия с ней, проявляется в сознании, сознание проявляется через материю.
Теорема Гёделя о неполноте говорит, что любая достаточно богая мат. теория не может быть одновременно полна и непротиворечива. Поэтому если мы предположим непротиворечивость мат. реальности, то это означает лишь то, что мы лишь не сможем доказать все её истины, но существованию этих истин в согласованном виде и описывающих всё, эта теорема не мешает.
Бизнес, конечно, думает о прибыли и ему действительно проще докупить серверов, но у нас и десктопные приложения никуда не делись, как с этой проблемой быть?
А еще есть ощущение, особенно это касается веба, что замедление кода обгоняет ускорение железа в последнее время. Если такая тенденция будет продолжаться, то разница между хорошо и плохо написанной программой может стать настолько большой, что эффективно написанный код может стать конкурентным преимуществом.
Вот, кстати, пример того, что может современное железо, если с умом подходить:
https://www.youtube.com/watch?v=AtCMF8nUK7E
Если вы создадите список и достаточно долго будете добавлять и удалять элементы в него, то получите кашу в памяти и оптимизирующий компилятор с этим фактом ничего не сделает. Речь, очевидно, об этом.
Не совсем. Вы можете хранить список больших блоков разрозненно и такая структура данных удовлетворяет пространственной и временной локальности хорошо, если блоки достаточно большие и используются достаточно полно при каждом доступе. А если все это еще и лежит в массиве, то получаем некоторый бонус в виде идеального data prefetch.
И от эффективности маркетологов - положите данные в память неудобным для процессора образом и у вас и близко такой цифры не будет.
Я не говорил, что наследование нельзя реализовать в C. Но то, что оно используется в Linux Kernel - я не знал.
Да, почти всегда упрощает восприятие и сокращает расходы неимоверно. Особенно, когда есть большие размашистые деревья классов с 5-ю и более уровнями наследования, а если все это еще присыпать множественным наследованием, ухх... Настолько все упрощает, что в одной из компаний, в которой я работал, пришлось руками бедных программистов развязывать этот гигантский гордиев узел и переписывать все.
Вы, видимо, имеете ввиду динамический полиморфизм в Linux ядре. Но он есть и в Haskell и в Rust, но ни тот ни другой не поддерживает ООП (нет наследования).
Инкапсуляция и полиморфизм существуют не только в рамках ООП. И я не видел ни одного определения ООП в которое входил бы параметрический полиморфизм или уж тем более перегрузка операторов.
Серебрянная пуля - универсальный метод решения всех проблем. Скам - не метод решения проблем. Если используете клише, то хотя бы семантику не нарушайте, а то вдвойне тошно.
Первые три части Quake.
Хорошо, а если мы хотим не по всему контейнеру искать? У меня такая задача часто возникает. Можно конечно дублировать функцию, но зачем, если вариант с методом класса реализует частный случай и не обобщаем (без потери удобства)? Реализовывать весь набор основных алгоритмов для каждого контейнера - это куча бойлерплейт кода.
Очередная статья от человека, который не разобрался в современных возможностях языка, но который смело заявляет:
Уже в C++20 появились модули, решающие многие проблемы инклудов. Да, поддержка не везде и неполная, но в GCC уже большая часть предложений реализована.
А если захотим написать свой stl-compliant контейнер и реализовать для него find_if? Писать с нуля?
См. std::ranges.
Далее, что касается SFINAE: значительная часть задач, решаемая этим, кхм, механизмом теперь решается концептами. Да, не полностью, но прогресс большой. Это же позволило улучшить и сообщения об ошибках.
Так это проблема программистов, а не языка получается? Отключаем RTTI и довольствуемся zero overhead.
Здесь will выражает спонтанно принятое решение сделать работу. Это достаточно твердое намерение (фактически обещание) и оно не эквивалентно
т.к. suppose вносит элемент неуверенности.
Далее:
Здесь to be going to отражает то, что действие было запланировано до момента высказывания. При этом план может поменяться и поэтому намерение здесь не такое твердое, как в случае с will.
Мы не только не можем утверждать, что наш разум в целом (не мозг, а все сознание) работает по некоторым алгоритмам, но нет даже намека на понимание того, как его формализовать. Есть достаточно аргументов в пользу того, что этого сделать вообще не возможно, хотя кто знает.
Если нужны математически обоснованные аргументы, то можно почитать Пенроуза (Новый ум короля, Тени разума). А так и без математики видно, что сознание имеет какую-то принципиально иную природу, нежели материя, а значит и выразить его через классические алгоритмы вероятно нельзя, поскольку любой алгоритм предполагает наличие некоторого изменяющегося состояния, которое нужно где-то хранить (а где, если не в материи?). Даже если мы говорим о чистой функции, все вычисления происходят в некотором материальном объекте. При этом столь же очевидно, что оба феномена взаимосвязаны - материя, или скоре результаты взаимодействия с ней, проявляется в сознании, сознание проявляется через материю.
Теорема Гёделя о неполноте говорит, что любая достаточно богая мат. теория не может быть одновременно полна и непротиворечива. Поэтому если мы предположим непротиворечивость мат. реальности, то это означает лишь то, что мы лишь не сможем доказать все её истины, но существованию этих истин в согласованном виде и описывающих всё, эта теорема не мешает.