В Go есть ООП, а в C нет?

Smalltalk. это демонстрация для студентов, а не реальный пример из жизни.

А что превратило Unix из «демонстрации для студентов» в «реальный пример из жизни»?

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

Я не думаю, что использование слова “memset” вместо “update table set …” сделает программу эффективнее. Чуть-чуть быстрее — может быть. Намного быстрее — разве что потенциально, сделает возможным, но за большую цену временем на разработку и сопутствующих потерь в ресурсах. А реалистично подавляющее большинство программ на языке С — излишнее перекидывание байтов, со всеми недостатками и без единого преимущества. Однажды посмотрел код какого-то драйвера Wi-Fi адаптера — лучше бы это было написано на PHP.

Об этой теме, кстати, Строуструп говорил. Перемножение матриц можно сделать на C++ эффективнее, чем на C.

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

даже на ассемблере код получается не намного менее жирным, чем сишный.

Об этой теме, кстати, Строуструп говорил. Перемножение матриц можно сделать на C++ эффективнее, чем на C.

сказки венского леса для неумеющих писать на Си. втирайте до полного удовлетворения.

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

Я не думаю, что использование слова «memset» вместо «update table set ...» сделает программу эффективнее.

Для начала стоит взять БД на PHP, а не на С.

Перемножение матриц можно сделать на C++ эффективнее, чем на C.

Я не эксперт в перемножении матриц, но в реализациях BLAS обычно ассемблер и кодогенерация, а не С++. В FFTW обошлись генерацией С. В С++ можно сделать более удобной работу с матрицами, а быстрее? За счет чего?

и там «байтики» никуда лишний раз не «перекидываются»

Я имею ввиду, что вся эта возня с байтами—здесь выделяем, сюда записываем, для такого-то вызова делаем копию—когда единицей мышления является байт, память, выравнивание, указатель, то это не обязательно приводит к хорошим, оптимизированным программам. Большинство программистов используют эти операции не задумываясь об эффективности.

Ну вот, например, как сделать окно текстового редактора? Может массив строк, char**? Уверен, что большинство текстовых редакторов именно так и делают. Но это неэффективно, ибо файлы могут быть большие, быть открыты через сеть на медленном железе. И смысл от того, что мы заменили нормальные понятия из других языков на байты, память, указатели?

не знаю, о каком «большинстве» ты говоришь. но я не наблюдаю вокруг «большинства программистов, пишуших на Си». хотя пишу на нём уже много лет.

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

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

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

Вот цитата:

And so people have written such a matrix multiplications and have actually gotten code that ran faster than Fortran, because once you had the right abstraction, you can eliminate you can eliminate temporaries and you can do a loop fusion and other good stuff like that. That's quite hard to do by hand and in a low level language. And there's some really nice examples of that.

00:45:14, транскрипт здесь.

я математик по образованию и программист. и хорошо владею английским. и написана там абсолютная чушь.

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

Я тоже не эксперт в перемножении матриц, я просто слепо верю Строуструпу. Надеюсь, он не врёт.

Не врёт это точно, но вполне может заблуждаться (имеет мнение).

Перемножение матриц можно сделать на C++ эффективнее, чем на C.

сказки венского леса для неумеющих писать на Си.

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

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

Именно это я наблюдаю в случае с языком С. Я не говорю, что это плохой язык. Я говорю, что он не единственный, есть другие подходы, не обязательно хуже.

Ну вот, например, как сделать окно текстового редактора? Может массив строк, char**?

Это с позиции байтоперекладывания плохая идея, постоянный realloc.

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

Ну вот если говорим о графических приложениях, посмотри на GUI которые были написаны на С, они не работают с байтиками и сырыми структурами.

WinAPI (1985) - Классы, объекты

GTK - Классы, объекты, подсчет ссылок, интроспекция, возможность сгенерировать биндинги для любого скриптового язычка автоматически через XML описание за счет всей этой системы. Можно даже генерировать автоматически DBus привязки, что бы работать с удаленными объектами, как будто они локальные.

Xv - Старый GUI от Sun, API имеет вроде бы меньше 10 функций, тоже объектный, есть xv_set, xv_get, xv_destroy, xv_create, и еще несколько функций, похоже чем то на идею Tcl.

Vulkan - Идея не в том что бы побыстрее отослать байты, есть абстракции для синхронизации которые на самом деле работают на GPU а не на процессоре. Вместо быстрой генерации комманд, строится, компилируется, оптимизируется конвеер из настраиваемых этапов, который потом исполняется.

Много проектов используют интересные, смелые абстракции, и это я не про ООП и динамику из примеров выше.

Он видимо говорит про динамическое программирование, оно конечно затруднительно в Fortran, я думаю он говорит про 90е, а долгое время в Fortran даже структур не было, неудивительно что на С++ получилось быстрее. Но на С проблем с реализацией умных алгоритмов нету, FFTW я упоминал, есть еще GraphBLAS где на MATLAB генерируются ядра на С, и потом они выбираются для матриц, или даже компилируются во время исполнения новые.

Там написано: “eliminate temporaries,” “loop fusion.”

Я не математик, поэтому могу чего-нибудь проглядеть. Насколько я понял, temporary — он имеет ввиду временное представление таблицы в транспозиционном виде. В C нам придётся либо использовать временную память, либо усложнить алгоритм, встраивая транспозицию в алгоритм умножения.

loop fusion — вроде, распараллеливание. Опять же, довольно сложно сделать вручную.

Какие абстракции позволяют C++ это делать самому, без ручной работы — не знаю, самому интересно.

какие, нафиг, «правильные абстракции»

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

Например, можно сортирование массива представить в виде трёх функций: Len, Less, Swap. Можно написать алгоритм сортировки, не трогая никакие структуры данных, только вызывая эти функции. В результате мы сможем, например, переисользовать этот алгоритм, чтобы отсортировать матрицу по диагонали. Qsort по диагонали — разве не круто?

Насколько я понял, temporary — он имеет ввиду временное представление таблицы в транспозиционном виде.

Наверное устранение промежуточных, временных результатов? Было A + B + C и вместо t1 = add(A, B); t2 = add(t1, C) будет лишь один t1 = cpp::add(A, B, C). Этим Eigen занимается кстати, просто есть эвристика для замены выражения A+B+C на add3(A, B, C) вместо разбора этого как двух add2.

loop fusion — вроде, распараллеливание. Опять же, довольно сложно сделать вручную.

Разве это не слияние циклов? Было два цикла, стал один, их тело это комбинация предыдущих двух тел циклов. Такая оптимизация есть в gcc, clang. Можно ее соответственно реализовать и в своем коде.

я думаю, что сейчас всё бы просто упёрлось в оптимизации компилятора. если компилятор засунет эти данные в массивы, спихнёт в регистры и применит какие-нибудь векторные инструкции современных процов, то будет прямо максимальный профит. а странные намёки на выигрыши от «абстракций» - это что-то из ряда ненаучной фантастики. но учитывая древность данного текста, там может быть что угодно. в том числе и неудачные реализации того же Фортрана на каких-то платформах. вообще, на Фортране до сих пор написано предостаточно математики и никто не жужжит. не трогают, потому что просто работает и работает очень даже эффективно.

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

я в курсе, что такое абстракции. мне это разжёвывать не нужно.

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

в жизни - ещё может быть. и то далеко не везде. но программирование не существует в вакууме. софт работает с железом. это всегда конкретные вещи.

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

К примеру возьмем матрицу и два вектора, значения только 1 или 0. Хотим выполнить умножение матрицы на один и второй вектор, и поэлементное умножение векторов-результатов: (M*V1)*(M*V2)

Выгоднее вместо прямого выполнения, сконструировать в памяти такую же формулу, и запустить оптимизатор во время выполнения, который передалет ее в (V1*V2)*M, если в векторе всего 10 элементов ненулевых, а матрица огромная, то это будет в сотни, тысячи, миллионы раз быстрее, зависит от соотношения.

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

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

На C можно писать хорошие программы, бесспорно. Я и сам пишу на С за $0/час, чисто ради удовольствия. И приведённые примеры действительно очень хорошие. Я всего-лишь хотел сказать, что Си — не единственный системный язык, что ООП в языке не является препятствием, а ряд особенностей Си, включая работу с памятью, усложняет работу программиста там, где в другом языке этого усложнения могло бы не быть.

Всё это не для того, чтобы очернить Си, это не интересно, а чтобы убрать это бесполезное предубеждение «в настоящем мире только Си, а всё остальное игрушки».

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

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

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

в ассемблере никто рутинные действия не повторяет. там есть функции, макросы и всё прочее. на нём пишут точно так же, как и на других ЯП.

А чем результат на Smalltalk был бы хуже результата на C? В современных реалиях понятно, одно — копролит, другое — стандарт индустрии. Выбор очевиден. Но если бы Smalltalk получил тот же уровень инвестиций, исследований, интереса, оптимизаций, конкурирующих реализаций, то разница, вероятно, не была бы столь велика. Proof-of-concept был, не было развития.

Всё это к тому, что Smalltalk — теоретическая игрушка только потому, что люди не хотят, чтобы он был чем-то другим.

В своё время Си показал, что системы могут быть написаны независимо от Ассемблера. Системы того времени, которое давно ушло.

В своё время Си показал, что системы могут быть написаны независимо от Ассемблера.

Спустя 12 лет после того как появился вполне успешный B5000 с ОС на Алголе. Это как если бы сейчас кто то прикрутил JS к серверу, и сказал бы, что он первый доказал возможность применения JS на стороне сервера, когда уже давно существует Node.js (Я знаю что до node.js тоже были проекты)

Си это вообще довольно отсталый язык на момент своего появления. Это все повод подумать почему он все еще далек от возможностей ALGOL и PL/1, хотя прошло столько лет.

более того, я вроде даже где-то видела подобные библиотеки на Си на просторах интернетов.

EFL. Смотрел я когда-то их сорцы, конкретно коллекции. И поклялся себе страшной клятвой, в полночь на перекрёстке отрезав кошке голову и окропив землю вокруг себя её кровью, что никогда не буду так извращаться, а буду писать на C++ где ООП уже сделан нормально на уровне языка.

Язык-языком, а для системного программирования, ИМХО, гораздо важнее инструмент системной разработки, т.е. компилятор, линковщик и генератор бинарного кода.

«ОС на Алголе», «ОС на JAVA» - это всё громкие маркетинговые слова.

Например, смотрим в простую википедию про B5000:

… all system software written in an extended variety of ALGOL 60 named ESPOL.

extended variety, т.е. расширенное на столько, что пришлось дать отдельное имя ESPOL.

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

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

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

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

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

На сколько понимаю в Linux, кроме Си, теперь будет еще и Rust. Если он там взлетит, то, вполне вероятно, что его начнут применять и в других компиляторах и системных программах.

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

Ну смотри, в классическом Basic даже циклов не было, но все их писали на условных переходах и все их читали не менее бегло, чем гламурный while.

А предки огонь трением добывали. Тоже наверняка вполне себе бегло.

правильное заполнение макросов для ООП тоже будет рутинными действиями. Их меньше, но они есть.
То что ошибиться можно везде - верно, но чем меньше вещей, за которыми надо следить вручную - тем меньше вероятность ошибки в итоге. Надо думать о корректности алгоритма, а не своей ручной реализации ООП.
Другое дело если готовая реализация не подходит по ресурсам - тут да, надо делать самому. Но вроде в треде речь не шла о ресрусах, раз речь идёт о Go и C++

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

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

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

взять какую-либо задачу, написать ее на языке высокого уровня. скомпилировать.
попутно получить ассемблерный низкоуровневый код. этот код дать «низкоуровневому» програмисту для оптимизации и он скорей всего найдет варианты оптимизаций, пропущенные компилятором, тем самым получив более эффективный код чем сгенеренный компилятором.
вариант2: написать задачу на С.
и сравнить результат.

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

Наверняка компилятор не панацея, но и программист то же.
Всё зависит от задачи и от объёмов обрабатываемых данных.

да даже не на ассемблере, а прямо в плюсах иногда можно подоптимизировать код так, чтобы он заработал существенно быстрее. много раз этим приходилось заниматься, подчищая код за математиками и чистыми плюсовиками. один раз удалось получить +30% к производительности чисто за счёт переделки циклов и обработки данных. вот вам и «абстракции». а там уже погромисты требовали срочно добавить им железа (а его пихать было некуда, место ограничено). отдали код на ревизию хардварным программистам и обошлось переделкой кода. стало хватать ресурсов, даже с запасом.

всё зависит от всего :) с этим согласен.

возьмем простейшие абстракции «функция» и «цикл» - проц такое не знает в приниципе.
это абстракция для упрощения человекочитаемости. и ООП из той же серии - для улучшения человекочитамости кода.
для проца все енти абстракции преобразуются в тупые JMP (goto) CALL (gosub) + RET и набора условных переходов J(cond).

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

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

Клоунам - быть!

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

Конечно ситуации могут быть разными и ИМХО лучше с неадекватами не вести диалоги.

ну, я рассматриваю клоунские рожи на ЛОРе как гримасничанье. как известно, приматы любят гримасничать. ничего не поделать :)

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

… - ну, пусть себе строят рожи. мне-то какое дело до этого.

Согласен, но в том треде хотят найти возможность оправдание своего неадекватного поведения.
А вот это - плохо!

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

для этого есть специальная реакция «клоун». это тривиальная логика.

Адекватный человек не позволит себе быть неадекватным в любой ситуации.

а тред вообще не про ЛОР. он просто показывает абсурдность и паноптикум реальности в этой стране. но хотя бы в положительном смысле, в данном случае. это редкость.

Если говорить о железе, то C быстрый только потому, что больше ничего другого нет. А сам C уже давно не соответствует железу, это иллюзия, которую компиляторы тяжёлым трудом создают, а железу приходится сохранять совместимость в ущерб производительности. ООП — это абстракция не более игрушечная, чем гарантии расположения памяти.

Подробности здесь, но tl;dr я уже написал.

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

… абсурдность и паноптикум реальности в этой стране. но хотя бы в положительном смысле, в данном случае. это редкость.

Лучше не пробовать на вкус разные сорта говна.
Тогда всегда настроение будет хорошее …

… сли у нас всё время оставаться серьёзным, можно и кукухой поехать.

Это да, но от пробования постоянно говна человек лучше не станет.
Видите ли этот продукт в любой ситуации всегда лишь вонь приносит, а не радость.

Чет я не вижу на какого клоуна вы отвечаете %)

Видите ли этот продукт в любой ситуации всегда лишь вонь приносит, а не радость.

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

Чет я не вижу на какого клоуна вы отвечаете %)

Это о треде в котором этот вопрос обсуждают.

именно так я и поступаю. я совсем перестала читать новости. это помогает сохранять спокойствие и хорошее настроение.