Языки, программы и так далее, Вынос из БН-800 Опции

[Syndroma]

Ещё раз упомяну слова Страуструпа про C++11: "I find a higher-level style of programming more natural than before and as efficient as ever."
То есть, на C++11 можно писать в высокоуровневом стиле, но без каких либо потерь в скорости.
Да и, всё те же unique_ptr/shared_ptr/weak_ptr заставляют задуматься, зачем вообще нужны простые поинтеры. Конечно, пока что ещё нужны, для non-owning применений. Но и это когда-нибудь изменится.
Кстати, я нисколько не утверждаю, что управляемые языки плохи. Чем ближе к пользователю, тем выше уровень языка должен быть.

[Syndroma]

Нас всех забанят.

[alex_bykov]

Я тут вас почитал, сижу, недоумеваю, как у меня система в 3 млн.строк кода на С++ вообще работает...

[VBVB]

Я тут вас почитал, сижу, недоумеваю, как у меня система в 3 млн.строк кода на С++ вообще работает...

Александр, если не тайна сколько времени эта система в 3 млн.строк кода на С++ писалась и отлаживалась.
Интересно мнение от реального разработчика.
А то пишут часто, что с отладкой пары миллионов строк кода C++ можно больше времени потерять, чем потратить на написание.

Сообщение отредактировал VBVB - 6.12.2016, 22:46

[armadillo]

можно больше времени потерять, чем потратить на написание.

это верно для любого языка

[Татарин]

Я тут вас почитал, сижу, недоумеваю, как у меня система в 3 млн.строк кода на С++ вообще работает...

Да нормально работает, я полагаю.

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

[alex_bykov]

Александр, если не тайна сколько времени эта система в 3 млн.строк кода на С++ писалась и отлаживалась.
Интересно мнение от реального разработчика.
А то пишут часто, что с отладкой пары миллионов строк кода C++ можно больше времени потерять, чем потратить на написание.

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

[Superwad]

Вы повторяетесь, не аргументируя. И опять мешаете в кучу С и С++. По Вашей ссылке намешано вообще всё подряд: от претензий к реализации некоторых механизмов в С и претензий к ООП в принципе до анекдотов и чьих-то высказываний. По стилю - это больше похоже на политическую пропаганду в форме листовки "для своих", чем на обсуждение какого-то технического вопроса.
До кучи Вы, похоже, полагаете, что Паскаль каким-то чудом не подпадает _под ту же самую_ критику и почему-то думаете, что он пригоден для реализации современных больших проектов и/или как замена С++.

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

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

Подытоживая свою... гм... точку зрения:
а) почти вся критика С/С++ переносима и на Паскаль/его наследников (добавляясь к их собственным недостаткам), разумеется не мешая всё в кучу: С - к Паскалю, а С++ - всё же сравниваем с его наследниками;
б) у С++ - была/есть масса сильных сторон, которых Вы не видите и/или не понимаете(и которых у того же Паскаля нет), он быстро стал индустриальным стандартом вовсе не просто так (и это НЕСМОТРЯ на то, что Паскаль для многих язык первичного обучения, выбор и усилия по переходу люди принимали сознательно);
в) С++ понемногу уходит из индустрии, времена меняются; например, сейчас во многих случаях дешевле платить накладные расходы рантайм того же сборщика мусора, чем мучаться с потенциальными проблемами аллокации памяти, и это лишь один пример из очевидного.

1) Претензии к утверждению, что с и с++ являются языками высокого уровня, коими они не являются
2) Стандарт на С еще может и быть, а вот на С++ - какой это стандарт, если на выходе код работает как карта ляжет? Я это не теоретически говорю, а с практической точки зрения, ибо сам столкнулся.
3) Для программирования критического кода инструмент должен быть прямой как железная дорога, а не плутать по лесным тропинкам по лесу. Т.е. логика должна просматриваться в одном файле, а не размазана по разным. Претензия к С/С++ в том, что при компиляции получается неоднозначный код и результат (опять же в зависимости от настроек директив компилятора).
Этого что мало? Этого уже достаточно, чтобы поставить крест на С++ как инструмента для написания критического программного обеспечения.
Про Паскаль, тот который FPC. Он развивается, выходят новые релизы. Мне он очень нравится. Я сейчас на нем пишу. Так как он делается на базе С , то в коде можно переключаться и делать вставки как на Асме, так и на чистом С. Почему пересел с Delphi на Lazarus? Переносимость кода на Линукс. Если пишешь на Паскале получаешь логически чистый код, ибо код читается и компилируется однозначно. ДА, может нет того богатого инструментария - а он нужен для прикладников? Может это наоборот благо, а не беда. Если смотреть на объем кода, который генерирует Lazarus (которым так любят хвастаться Сишники), если это очень критично, то вместо LCL библиотек можно задействовать KOL, тем более, что Lazarus это позволяет. Так что Lazarus/FPC очень даже современный мощный инструмент высокого уровня, который может спокойно заменить С++, без ущерба (а то и где-то даже обставив) за счет меньшей трудоёмкости при отладке.
А то, что вместо С++, начинают использовать Java и С# - это признак того, что не всё так сладко с С++.

[alex_bykov]

Superwad, простите, от директив компиллятора будет зависеть генерация любого кода из исходников. По поводу "логики в одном файле" - бейте код на элементарные функции с обвязкой при падении, выдерживайте логику проекта и будет Вам счастье.
Сам пишу на Паскале, но я то пишу коротенькие программки, состоящие из пары модулей и десятка функций максимум. В код в логике проекта переводят уже программисты, и вот как раз их код вполне читаем, хотя я на С++ и не пишу...
И ещё одно. По поводу исполнения стороннего кода. Мы сознательно в проекте отказались от использования большей части сторонних API - именно там зарыта неоднозначность исполнения, ребята пишут всё сами. Зато это даёт очень неплохую кроссплатформенность - система работает под несколькими версиями Винды и Линукса. Частичное использование "сторонних" dll остаётся, в основном, потому, что "наука" пишет преимущественно на фортране и переучить её очень сложно, приходится жёстко оговаривать директивы компиллятора фортрана, чтобы dll-ка подхватывалась без сбоев. Но и тут мы потихоньку приходим к общему знаменателю, когда практически все входные/выходные параметры передаются в качестве параметров функций, а не через коммон-блоки, а ребята генерят исполняемый код для разных сортов топлива уже в двух вариациях: в фортрановский и сишный исходники (для математики это оказалось совсем не сложно)...

[Татарин]

1) Претензии к утверждению, что с и с++ являются языками высокого уровня, коими они не являются
2) Стандарт на С еще может и быть, а вот на С++ - какой это стандарт, если на выходе код работает как карта ляжет? Я это не теоретически говорю, а с практической точки зрения, ибо сам столкнулся.
3) Для программирования критического кода инструмент должен быть прямой как железная дорога, а не плутать по лесным тропинкам по лесу. Т.е. логика должна просматриваться в одном файле, а не размазана по разным. Претензия к С/С++ в том, что при компиляции получается неоднозначный код и результат (опять же в зависимости от настроек директив компилятора).
Этого что мало? Этого уже достаточно, чтобы поставить крест на С++ как инструмента для написания критического программного обеспечения.
Про Паскаль, тот который FPC. Он развивается, выходят новые релизы. Мне он очень нравится. Я сейчас на нем пишу. Так как он делается на базе С , то в коде можно переключаться и делать вставки как на Асме, так и на чистом С. Почему пересел с Delphi на Lazarus? Переносимость кода на Линукс. Если пишешь на Паскале получаешь логически чистый код, ибо код читается и компилируется однозначно. ДА, может нет того богатого инструментария - а он нужен для прикладников? Может это наоборот благо, а не беда. Если смотреть на объем кода, который генерирует Lazarus (которым так любят хвастаться Сишники), если это очень критично, то вместо LCL библиотек можно задействовать KOL, тем более, что Lazarus это позволяет. Так что Lazarus/FPC очень даже современный мощный инструмент высокого уровня, который может спокойно заменить С++, без ущерба (а то и где-то даже обставив) за счет меньшей трудоёмкости при отладке.
А то, что вместо С++, начинают использовать Java и С# - это признак того, что не всё так сладко с С++.

1) Вы опровергаете мнение всего мира авторитетной ссылкой на самого себя. Методологически это очень неверный подход. В науке и технике это прокатывает исключительно редко и только при исключительно репутации человека в данной области.
2) О, блин... я-то думал, при каком-то сложном портинге вылезла какая-то нетривиальная разница между тулчейнами... А, оказывается, Вы обиделись на мир после того, как лично накосячили с опциями компиляции. Ну, что тут можно сказать? Не хочу Вас пугать, но если Вы выберетесь из своей песочницы, Вы можете столкнуться не только со своими косяками, но и с реальными проблемами. Даже это - не проблема _языков,_ но чтоб объяснить это, Вас нужно вытащить из песочницы и ваших игрушек к взрослым дядям с игрушками посложнее.
3) У Вас в руках три кубика стандартных библиотек и Вы можете их свободно переносить из песочницы в песочницу. Представьте себе, что мир не исчерпывается песочницами, а машины - состоят из частей сложнее, чем ровный гладкий кубик. Что Вы будете делать, если потребуется заставить Ваш код прямо завтра работать на MIPS или, блин, том же Эльбрусе-4? Выравнивание элементов? Внезапный big-endian? Процессор не поддерживает побайтовую индексацию, а у Вас всё построено на строках? Вы полагаете, что дяди за Вас решат ВСЕ проблемы так, чтоб Вы даже не задумывались о том, куда и что Вы компилируете?
Нет, вот тут и возникают всякого рода настройки и опции, кнопочки и переключатели, кои Вы, не разобравшись в том, зачем они, ничтоже сумняшися назвали недостатком и нестандартностью. Вы ударную дрель видели? Вот она, если ударник включить - тоже непредсказуемо мешает сверлить деревяшки. Нестандарт. Не то, что Вы от дрели ожидали.
Игры в песочнице подразумевают гладкие кубики с ровными гранями удобных размеров, для Вас их умные дяди вырезали и отполировали, подогнав соразмерно песочнице. Вы даёте советы дядям, о том, как нужно конструировать машины из этой песочницы на примере этих пирамидок. А у дядей кубики к друг другу не подходят, клей отваливается, и резьбу приходится нарезать самостоятельно по месту, и так, чтобы метрическая работала с дюймовой. Вы вообще представляете себе, на КАКОМ разнообразии машин и окружений работает С/С++? Нет? Ну что ж Вы говорите всякие глупости-то про то, что у Вас любые два кубика из трёх друг другу подходят один в один предсказуемо?

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

Конечно, с С++ всё не идеально. Далеко всё не идеально. Конечно, с# и Ява появились не просто так.
Но как я уже говорил, все проблемы неуправляемого кода применимы к наследникам Паскаля в полной мере.
По Вашим же словам, Вы с ними не сталкивались, и даже не представляете пока тех проблем, из-за которых люди переходят на c#.
Значит Ваши программы слишком простые и маленькие для этого - и это хорошо.


Но зачем тогда Вам "точка зрения" и votum separatum в вопросе, который перед Вами никогда даже не вставал? Вот это непонятно.

Сообщение отредактировал Татарин - 7.12.2016, 18:16

[pappadeux]

скорее бы пришел лесник...

[armadillo]

в кои-то веки я не влез в этот срач)

[aprudnev]

скорее бы пришел лесник...

Я вот подумал, что форумом ошибся...

Просьба это перенести куда нибудь, там с удовольствием продолжим. Обсуждение кодов, Паскаля и всего такого прочего. А тот тут вроде как БН обсуждают а не компиляторы.

Лесник, АУ?

[armadillo]

ждите терпеливо. ик

[arcanist]

скорее бы пришел лесник...

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

[Superwad]

Superwad, простите, от директив компиллятора будет зависеть генерация любого кода из исходников. По поводу "логики в одном файле" - бейте код на элементарные функции с обвязкой при падении, выдерживайте логику проекта и будет Вам счастье.
Сам пишу на Паскале, но я то пишу коротенькие программки, состоящие из пары модулей и десятка функций максимум. В код в логике проекта переводят уже программисты, и вот как раз их код вполне читаем, хотя я на С++ и не пишу...
И ещё одно. По поводу исполнения стороннего кода. Мы сознательно в проекте отказались от использования большей части сторонних API - именно там зарыта неоднозначность исполнения, ребята пишут всё сами. Зато это даёт очень неплохую кроссплатформенность - система работает под несколькими версиями Винды и Линукса. Частичное использование "сторонних" dll остаётся, в основном, потому, что "наука" пишет преимущественно на фортране и переучить её очень сложно, приходится жёстко оговаривать директивы компиллятора фортрана, чтобы dll-ка подхватывалась без сбоев. Но и тут мы потихоньку приходим к общему знаменателю, когда практически все входные/выходные параметры передаются в качестве параметров функций, а не через коммон-блоки, а ребята генерят исполняемый код для разных сортов топлива уже в двух вариациях: в фортрановский и сишный исходники (для математики это оказалось совсем не сложно)...

1) Я писал, что логика в С++ размазана по двум файлам .с и .h. Чтобы восстановить логику нужно анализировать сразу два файла. Это хорошо для диверсантов - тот кто будет анализировать - психушка обеспечена
2) Ссылку что я приводил, разные люди(не мое мнение!), пишут об очень большой сложности С++ и неоднозначности работы полученного кода. Язык С вообще пишут, что это низкоуровневый, создан для улучшения написания системных вещей вместо Асма.
3) Если начать бить код на блоки (ибо это разумно, т.н. unix-way принцип), то... получаем Паскаль с его модульной структурой.
4) Насчет сторонних библиотек - просто привел пример, как написанная на С++ библиотека неоднозначно вызывалась из Паскаля из-за неработающего механизма вызова из вне перегружаемых функций, ибо эта вещь не зависит от настроек компилятора (хотя и это тоже может зависит - я решил проблему через функцию-прокладку и директиву компилятора этой функции-прокладки использовать только чистый синтаксис С), а зависит от конкретной реализации С++ компилятора (привет стандартизации!). На бумаге все красиво, на деле как с забором - на заборе написано три буквы, а за ним дрова лежат. Так и тут ситуация.
5) Я стараюсь задачи выносить в разные программы - так удобнее и быстрее компилировать на старом компьютере (то что есть на работе). "Правильно готовить программу на С++" (с) Татарин - у меня просто нет на это лишнего времени, мне надо сразу нормально работающий код с минимальными затратами. Поэтому использую бритву Оккамы, я выбираю более простое решение, тем более что результат то получается один, а затраты то разные.
Вот, соприкоснувшись с таким поведением кода и расхлябанностью программистов с высоты своей колокольни и говорю, что с++ надо пристрелить на подступах, ибо нужны решения которые дадут однозначно правильный результат при ЛЮБЫХ условиях, а не только при "правильном" приготовлении.
ЗЫ. "Если бы программисты были строителями, то случайно залетевший дятел в город привел бы к гибели цивилизацию" (с) Народное.

[sch]

1) Я писал, что логика в С++ размазана по двум файлам .с и .h. Чтобы восстановить логику нужно анализировать сразу два файла. Это хорошо для диверсантов - тот кто будет анализировать - психушка обеспечена

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

Пока что лишь замечу, сознательно не конкретизируя, что многое из того, что Вы (и не только Вы) называете недостатками C++, является естественным и даже неизбежным продолжением его достоинств.

[alex_bykov]

Не готов обсуждать достоинства и недостатки именно языков. Однако вчера расчётное ядро нашей СВРК получило паспорт Ростехнадзора... Ну и референтный опыт на 20+ блоках чего-то стоит, наверное.

[AtomInfo.Ru]

Не готов обсуждать достоинства и недостатки именно языков. Однако вчера расчётное ядро нашей СВРК получило паспорт Ростехнадзора... Ну и референтный опыт на 20+ блоках чего-то стоит, наверное.

Давно пора! Поздравляю

[alex_bykov]

Давно пора! Поздравляю

Спасибо, Саша!
Весело быть первыми в своём роде