N>Ты отличный пример человека, который рассуждает о вкусе апельсинов, даже ни разу их не видев.
Окей, вижу, что уже второй человек не понял мной написанного. Значит, это я плохо мысль выразил.
На Фортране я написал тысячи строк, и еще больше переписал с Фортрана на С (годах в 96-98). Я отлично знаю его область применения (с тех пор она не претерпела изменений, КМК). Мысль, которую я пытался донести, проста: Фортран имеет определенную нишу. Там где его свойства действительно требуются. Причем даже не столько в силу языковых особенностей, сколько в силу преемственности — старые математики учат молодых "делай как я". В свое время я портировал (весьма зубодробильную, я так ее и не понял) модель полярных сияний с Фортрана на С/С++. Надо было научиться параллелить вычисления, что и было сделано с помощью MPI. Сначала физики поворчали, но когда оно стало считаться за минуты вместо недель, оценили. Больше Фортрану они никого не учили
Так вот, С++ в этом смысле аналогичен. На нем есть мегатонны строк кода. Если б не это, привлекательность языка была бы куда меньше, и позицию бы он занял ближе к Фортрану: инструмент для вполне конкретного назначения. Но когда на С++ начинают писать все подряд (включая микросервисы, общающиеся по HTTP + JSON, и занимаюшиеся парсингом чего-нибудь во что-нибудь), это уж точно не от того, что С++ лучший язык на данном поприще.
Здравствуйте, SkyDance, Вы писали:
S>>На счет сложности: сопромат -- это непростая дисциплина, но почему-то никому и в голову не приходит утверждать, что сопромат говно, патамушта сильнасложно, и на задачи по расчету прочности конструкций и элементов двигателей почему-то берут именно тех, кто сопромат смог освоить.
SD>А вот в софтостроении не так.
И вновь: отучаемся говорить за всех.
SD>Поэтому требуются более простые и дуракоустойчивые инструменты.
В 100% случаев?
SD>Более того, даже если брать только грамотных людей, более простые и комфортные инструменты ускоряют разработку. Меньше багов, быстрее релизы и т.п..
Да вы, прям, Капитан Очевидность. Ну кто бы мог подумать?!!!
А теперь добавляем в рассмотрение требования к производительности и ресурсоемкости. Хотя бы.
И обнаруживаем, что грамотные люди с комфортными инструментами начнут пердолиться с чистой Сишечкой чтобы развязать узкие места, завязавшиеся из-за более высокоуровневых и безопасных языков с GC.
Здравствуйте, SkyDance, Вы писали:
SD>Возвращаясь к сабжу: это как раз та причина, по которой дальнейшие вложения в С++ как технологию я бы предпочел ограничить.
Так ограничивайте. Вам кто-то мешает это сделать?
SD>>>Примерно как Фортран — он есть, там где нужно старый код гонять. S>>Говорят, что ученые, которым приходится заниматься вычислениями (математики, физики, химики и т.д.), гораздо лучше справляются с современным Фортраном, чем с C++. Так что, предположу, что и здесь вы сильно не правы.
SD>Именно про это я и написал: Фортран есть там, где нужно гонять старый [ментальный] код. Где конкретные математики и физики уже умеют работать с Фортраном — поэтому и продолжают с ним работать.
Во-первых, говорят, что Фортран сейчас с удовольствием изучает именно что молодежь. Просто потому, что Фортран позволяет им получать решение их задач быстрее и проще, чем тот же C++.
Во-вторых, люди вокруг не тупее вас (а по некоторым вашим высказываниям могу предположить, что гораздо умнее). Поэтому, если бы в их области было что-то существенно лучше Фортрана, то Фортран уже был бы давным давно отправлен туда же, где сейчас находится COBOL. Но нет, суть в том, что в своей нише Фортран успешно конкурирует со всем, что появилось сильно позже него.
И то, что Фортран живет там, "где нужно гонять старый [ментальный] код", сей факт никак не обесценивает. Как бы коннотацию лично вы бы не вкладывали в "старый [ментальный] код".
SD>Самое дорогое в нашей профессии — научиться, и научить других людей.
Здравствуйте, SkyDance, Вы писали:
SD>Но когда на С++ начинают писать все подряд (включая микросервисы, общающиеся по HTTP + JSON, и занимаюшиеся парсингом чего-нибудь во что-нибудь), это уж точно не от того, что С++ лучший язык на данном поприще.
Ну так, просто в качестве робкого предположения: а может это из-за того, что другое уже пробовали и оно тупо не потянуло?
Здравствуйте, SkyDance, Вы писали:
N>>Ты отличный пример человека, который рассуждает о вкусе апельсинов, даже ни разу их не видев.
SD>Окей, вижу, что уже второй человек не понял мной написанного. Значит, это я плохо мысль выразил. SD>На Фортране я написал тысячи строк, и еще больше переписал с Фортрана на С (годах в 96-98). Я отлично знаю его область применения (с тех пор она не претерпела изменений, КМК). Мысль, которую я пытался донести, проста: Фортран имеет определенную нишу. Там где его свойства действительно требуются. Причем даже не столько в силу языковых особенностей, сколько в силу преемственности — старые математики учат молодых "делай как я".
Нет. Ниша Фортрана не в преемственности, а в возможности максимально прямого изложения описания задачи с избавлением от ненужных и проблемных сущностей типа указателей (а, может быть, и ссылок).
Для нового поколения математиков эту нишу достаточно неплохо покрывает Python как запускалка всяких numpy/scipy/pandas/что-там-ещё-сегодня-актуально, но у него свои грабельки.
"Старые математики" могут быть специфически старыми только потому, что молодые таки чаще понимают чисто программистские сущности и понимают, зачем в ответ на new надо делать один и ровно один delete. Но это не значит, что им это критично или что они хотят ещё и это знание.
SD> В свое время я портировал (весьма зубодробильную, я так ее и не понял) модель полярных сияний с Фортрана на С/С++. Надо было научиться параллелить вычисления, что и было сделано с помощью MPI. Сначала физики поворчали, но когда оно стало считаться за минуты вместо недель, оценили. Больше Фортрану они никого не учили
MPI и OpenMP для Фортрана есть не хуже, а во многом и лучше. То, что вы его не использовали, говорит только об ограниченности или доступных средств, или знаний о них.
SD>Так вот, С++ в этом смысле аналогичен. На нем есть мегатонны строк кода. Если б не это, привлекательность языка была бы куда меньше, и позицию бы он занял ближе к Фортрану: инструмент для вполне конкретного назначения. Но когда на С++ начинают писать все подряд (включая микросервисы, общающиеся по HTTP + JSON, и занимаюшиеся парсингом чего-нибудь во что-нибудь), это уж точно не от того, что С++ лучший язык на данном поприще.
Это оттого, что
1) C++ вполне неплох на данных поприщах.
2) Унификация как в пределах одного средства сильно облегчает диагностику и отладку.
3) Унификация в пределах разных средств сильно облегчает перенос людей и опыта.
И, что критично для данной подветки, он в этом смысле в разы лучше C (который тут выдвигают некоторые оппоненты).
Здравствуйте, SkyDance, Вы писали:
N>>Зато, как правило, есть власть над принятием кода этих сотрудников.
SD>Могу только позавидовать. Что я вижу в реале, так это отсутствие оной власти. Конечно, можно прокомментировать на тему "наши гайдлайны говорят делать вот так, а не вот так". Но реальной власти ("не пилите свой лас-вегас с блекджеком, используйте готовый вот отсюда") по факту может и не быть. Говорю о том, что вижу сам.
Это странно. Я видел только такое. Чаще проблема в качестве контроля со стороны лидов, и крайне редко — в его невозможности.
Ну, значит, завидуйте
Здравствуйте, netch80, Вы писали:
N>MPI и OpenMP для Фортрана есть не хуже, а во многом и лучше.
Любопытно, что если покопаться в истории развития этих инструментов, то выясняется, что MPI появился изначально для Си и Фортрана, тогда как первая версия OpenMP была сделана именно (и только) для Фортрана, а на C/C++ OpenMP был перенесен спустя несколько лет.
Этот комментарий ни в коей мере не в пику тому, что говорилось выше. Просто в качестве дополнительных мазков в общую картину.
Здравствуйте, so5team, Вы писали:
SD>>Но когда на С++ начинают писать все подряд (включая микросервисы, общающиеся по HTTP + JSON, и занимаюшиеся парсингом чего-нибудь во что-нибудь), это уж точно не от того, что С++ лучший язык на данном поприще.
S>Ну так, просто в качестве робкого предположения: а может это из-за того, что другое уже пробовали и оно тупо не потянуло?
Может быть, был конфликт интересов. Например, взяли so5team, у которого наколки "За C++, отца его и святаго духа" и сказали, вот, пиши сервис на жаве. Тот и написал- да так, чтобы ни у кого сомнений не осталось, что только C++ спасет их проект от провала.
S>Ведь может же такое быть. Чисто теоретически?
Может.
Засада для фанатиков C++ в том, что их не подпускают до микросервисов на расстояние пушечного выстрела.
Здравствуйте, so5team, Вы писали:
Аё>>Засада для фанатиков C++ в том, что их не подпускают до микросервисов на расстояние пушечного выстрела.
S>Так а засада-то в чем?
Вот, это интересно и правильно. Садомазохистов-раскладывателей грабель с крестиками не подпускать к ядру на пушечный выстрел.
Цитата Линуса Торвальлса (создателя ядра линукс и git):
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
— infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
— inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.
- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
— any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
— you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.
In general, I'd say that anybody who designs his kernel modules for C++ is
either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
Сейчас, конечно, набежит so5steam и продолжит песню о "производительности" C++.
S>тогда как первая версия OpenMP была сделана именно (и только) для Фортрана
OpenMP — это не библиотека, а "стандарт", суть список функций API. Этот список вышел году, кажется, в 98 или около того. К этому времени уже несколько лет как существовал MPI. Причем не только в виде "стандарта" (ибн описаний функций), но и вполне рабочей библиотеки. Которая была частично совместима с Fortran — через FFI bindings. В 1996 оно нормально работало только с С (причем в нашем случае — только с Watcom C, если кто-то еще помнит, что это такое, плюс DOS/4GW — ибо нужно было много памяти).
OpenMPI — тоже на С (и тоже можно использовать через FFI). Она вышла лет на 10 позже, чем стоял вопрос о замене Фортрана на С. В общем, конечно, спорить можно до хрипоты, но на тот момент разница в скорости обсчета модели была достаточной причиной, чтоб физики научились писать математику на С.
Эх, ностальгия Прикольные были времена. Доступ в интернет был мало кому доступен. У меня модем был, Zyxel V.32bis (или как он там назывался, уж и не помню, скоро 30 лет этим воспоминаниям).
N>Это странно. Я видел только такое. Чаще проблема в качестве контроля со стороны лидов, и крайне редко — в его невозможности.
Возможно, специфика структуры incentives у определенных компаний. Когда основная масса бонусов идет за "time to market". В таком варианте любой контроль качества обходится фразой "весь мир насилья мы разрушим зарелизим вот эту фичу, и потом зарефакторим, отчистим от мусора, сделаем нормальный API, добавим тесты". Практика показывает, что "а потом" обычно не наступает. Разве что находятся герои, самоотверженно бросающиеся на амбразуру. Но они быстро сгорают, ибо в награду вместо финансовой благодарности получают низкий рейтинг в performance review, потому что "трижды обрушил систему, убирая неиспользуемый код, который играл важную роль для разогрева процессора с целью последующей прожарки сосисок на нем".
Аё>У C++ есть высокооплачиваемое применение в HFT, хотя по сплетням от инсайдеров, оттуда плюсников теснит FPGA.
Открою страшную тайну. Большиство языков по сути одинаковы. Разве что функциональщина vs императивщина чутка вырывает мозг. Но поняв оба класса языков, дальше уже совершенно неважно.
И платят не за С++ или Rust. А за умение выполнить задачу. С помощью подходящего инструмента. Так что все языки высокооплачиваемы (английский, КМК, самый высокооплачиваемый, на данный момент).
Аё>easier to generate total and utter crap with it. Quite frankly, even if Аё>the choice of C were to do *nothing* but keep the C++ programmers out, Аё>that in itself would be a huge reason to use C.
The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.” Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.
Сдается мне, Торвальдс не столько огорчен безумием в С++, сколько тем, что придется впустую продолбать год(ы) на изучение кишочков этих С++ стандартов, дебагом всей этой ненужной сложности и т.п..
Здравствуйте, Артём, Вы писали:
Аё>Цитата Линуса Торвальлса (создателя ядра линукс и git)
А ты внутрь гита то сам заглядывал? Там такое макаронное месиво что просто атас.
Rants этого ниасилятора попросту не интересны. Ну не шмог он, и теперь пыжится, выдавая нужду за добродетель.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
