Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

Форум AtomInfo.Ru _ Разные стороны атома _ Языки, программы и так далее

Автор: Татарин 1.12.2016, 20:34

Цитата(AtomInfo.Ru @ 1.12.2016, 8:23) *
Мы специально дали возможность Е.Ф. высказаться по поводу матначинки эксплуатационного комплекса.
Потому что иногда приходится слышать: "Ну, на станциях диффузия, разве это круто? Прошлый век!".

Действительно, для начинки комплексов, которыми пользуется эксплуатация (именно эксплуатация! не конструктора, например), должен быть выбран оптимум между требованиями по быстродействию и точности и вычислительными возможностями. Физику на станции не нужен код, который один вариант будет просчитывать неделями на суперкомпьютере smile.gif В том числе, и потому, что далеко не всегда такой суперкод даст результаты точнее, чем инженерная программа.

Вот этот момент мне показался самым... странным в интервью.
Мощность машин быстро растёт.

Кроме того, большинство массивных расчётов замечательно выносится в спецвычислители - ну хоть CUDA/OpenCL. Я не уверен насчёт именно видеокарт именно в вашем случае, но суперкомпьютер суперкомпьютеру рознь - может, тот же результат можно получить чем-то вроде Knight'а или спецядро на ПЛИС запилить?

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

Никто ж не требует суперкомпа (в традиционном понимании) для установки в РЛС с АФАР? А там числодробилки нужны приличной производительнсти, причём, в реальном времени и с (кое-где) ограничениями по массе, теплу и потреблению.
Или - другой пример - никто ж не удивляется суммарной мощности сети Биткойна? Там ASIC'и. МНОГО ASIC'ов, сколоченных в фермы... обычному компу (или суперкомпу) там уж лет десять как делать нечего.

Поэтому, если уже известен некий стержень вычислений, вокруг которого всё крутится/будет крутиться в обозримом будущем, почему именно "суперкомпутер"?

Автор: armadillo 1.12.2016, 20:52

а сертифицировать переложенный с фортрана код кто будет?

Автор: Татарин 1.12.2016, 20:57

Цитата(armadillo @ 1.12.2016, 20:52) *
а сертифицировать переложенный с фортрана код кто будет?

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

Переписать на С (лучше - чистом, дабы снять все тулчейн-зависимости) таким образом, чтобы вынести вычислительно-ёмкие вещи в аппаратно-зависимые функции/методы/классы. И наслаждаться затем "вездеходностью" кода. Это помимо скорости.

Аппаратные ускорители - они же не только на станции полезны. Худо ли, если _точный_ код у расчётчика на столе будет в разы и на порядки быстрее бежать?

Автор: Syndroma 1.12.2016, 22:15

Да, современное железо уже подбирается к уровню, когда становится возможным использовать Монте-Карло для трёхмерной графики в реальном времени:
http://www.youtube.com/watch?v=BpT6MkCeP7Y

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

Автор: alex_bykov 1.12.2016, 22:58

Ну, Монте-Карло или нет, вопрос десятый - там свои ограничения и источники ошибок есть. А вот с чем Татарина поддержу, так это с "достругиванием" кода.
У нас в SVC "сидит" чутка лучшее приближение, чем диффузионка (http://www.myshared.ru/slide/260336/). Когда стало нужным "допилить" для увеличения скорости счёта, был эффект и от перехода на C++ - примерно 2 порядка, и от применения современных методов решения разреженных систем большой размерности (2-3 раза). Правда, в онлайн мы его пока не утрамбовали, но пока и не занимались всерьёз распараллеливанием. А всего лишь возникла задача допилить до возможности использования отдельных расчётов в существующей системе на АЭС...
Правда, код БНы не считает - групп маловато.

Автор: LAV48 2.12.2016, 0:30

Одно из направлений мысли - программно программируемые матрицы. С современными техпроцессами необходимую расчётную мощность можно поместить в "банальный смартфон". Другое дело, когда требуется большой объём ввода-вывода (не в плане исходных/конечных, а работа с большим объёмом данных), например брутфорс такими "ускорителями" не форсировать.

Автор: Татарин 2.12.2016, 9:04

Цитата(alex_bykov @ 1.12.2016, 22:58) *
Ну, Монте-Карло или нет, вопрос десятый - там свои ограничения и источники ошибок есть.

Понятия не имею, нужен ли там в расчётах Монте-Карло, ибо в нейтронных расчётах разбираюсь примерно как свинья в живописи. smile.gif

О чём говорил - о том, что если алгоритм определён и у него выделены критичные к скорости операции (как прямое/обратное Фурье для ЦОС, к примеру или тригонометрия/квадратный корень для 3д-рендера), то скорость - это не есть проблема.
Ну или точно не есть проблема, которая решается именно и только установкой суперкомпов; суперкомпы или вообще процессоры общего назначения нужны как _универсальное_ вычислительное средство. Ведь суперкомпы дают рост производительности на порядки - три-пять порядков максимум. Того же роста в массивных вычислениях можно несоизмеримо дешевле получить аппаратным ускорением. А реакторные штуки - нейтроника или теплотехника выглядят именно как нечто поддающееся параллелизации.

Для таких спецалгоритмов есть всякие весёлые платки с дополнительными процессорами, с GPU, с ПЛИС.
Их немножко мучительно программировать, но результат в смысле скорость/количество железа или скорость/ватты отличается радикально. Но и выносятся туда после профилирования лишь критичные по скорости функции числодробления, то есть, не нужно же весь алгоритм под железо перепиливать. Только конкретные формулы/операции.

А если, как Вы говорите, ещё и компиляторы Фортрана такие убогие в отрасли используются, что переход на нормальную компиляцию С/С++ даёт выигрыш на два порядка, то о чём вообще речь?

Автор: asv363 2.12.2016, 10:40

Во-первых, интервью отличное.
Во-вторых, если кто-нибудь сходу вспомнил по коду 90Н команду (семейство 8086, asm) - то пусть напомнит. И, заодно, можно написать код для запрещения прерываний. В интернет грязными руками не лазить!

Тем временем, я сделаю вид, что ничего не помню.

Автор: Syndroma 2.12.2016, 11:16

Цитата(asv363 @ 2.12.2016, 12:40) *
Во-вторых, если кто-нибудь сходу вспомнил по коду 90Н команду (семейство 8086, asm) - то пусть напомнит.


Слишком просто — это универсальная операция над любыми данными.

Ещё в порядке оффтопа, 99 строк на C++, полностью реализующие Монте-Карло для трёхмерной графики:
http://www.kevinbeason.com/smallpt/

Автор: generalissimus1966 2.12.2016, 12:18

QUOTE(asv363 @ 2.12.2016, 11:40) *
Во-первых, интервью отличное.
Во-вторых, если кто-нибудь сходу вспомнил по коду 90Н команду (семейство 8086, asm) - то пусть напомнит.

Процессор 8086 был знаменит тем, что у него не было отдельной команды NOP. В качестве неё использовалась команда XCHG AX, AX.
QUOTE(asv363 @ 2.12.2016, 11:40) *
И, заодно, можно написать код для запрещения прерываний. В интернет грязными руками не лазить!

Тем временем, я сделаю вид, что ничего не помню.

Ну, на ассемблере 8086 я довольно много программировал вплоть до 1995 года. Но коды не помню. Коды я помнил от 8080, довольно долго. Да и сейчас помню больше половины таблицы. А вот от 8086 коды уже не помнил, не было смысла - команды у него ну очень переменной длины smile.gif и один и тот же байт мог значить совсем разные вещи, в зависимости от начального смещения. Больше того, есть такая программа, которая играет музыку на PC Speaker-е, у неё этот трюк используется - переход посредине команды, после чего исполняется совсем другая последовательность. А ещё у неё в тексте COPYRIGHT было написано одними большими буквами. Потому что это место тоже исполнялось.

Автор: Superwad 2.12.2016, 13:14

Тех кто тянет С/С++ языки в критические области - пристрелить на дальнем подступе. И никак иначе! А лучше пристрелить вообще!
Только проверенные и только НАДЕЖНЫЕ языки высокого уровня! С и С++ не является языком высокого уровня - он застрял на серединке, в нем нет ГЛАВНОГО - в нем нет ЧИТАБЕЛЬНОСТИ КОДА! Все приплыли, и проект F-35 как бы на это намекает, много АДА с примесью С. Вот и до сих пор кувыркаются. Так что только Паскаль, Ада и Фортран. Ну еще можно ассемблер, где это нужно.

Автор: Superwad 2.12.2016, 13:18

Насчет спец. процессора. Сколько было эйфории по поводу Java и что появится куча спец. процессоров поддерживающие Java на уровне железа. И хде они? Все крутиться на обычных серийных процессорах.

Автор: Syndroma 2.12.2016, 13:39

Цитата(Superwad @ 2.12.2016, 15:18) *
Все крутиться на обычных серийных процессорах.

Неправда. Современный компьютер состоит из нескольких серийных процессоров и нескольких тысяч параллельных процессоров. Это радикально отличается от того, что было 20 лет назад.
Программа, требующая для выполнения только один универсальный процессор, использует возможности современного компьютера от силы на 10%.

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

Автор: VBVB 2.12.2016, 14:19

QUOTE(Татарин @ 2.12.2016, 10:04) *
А если, как Вы говорите, ещё и компиляторы Фортрана такие убогие в отрасли используются, что переход на нормальную компиляцию С/С++ даёт выигрыш на два порядка, то о чём вообще речь?

Интересно еще узнать, что конкретно за машины используются на БАЭС для работы с ГЕФЕСТом.

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

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

Да чего там говорить, у меня дома на своих трех компьютерах (один ноут и две специализированные PC) вычислительных мощностей больше, чем в исследовательском центре университета нашего, где работаю. Где компьютеры стоят еще лохматых 2009-2011 годов.

Автор: Татарин 2.12.2016, 15:01

Цитата(Superwad @ 2.12.2016, 13:14) *
Тех кто тянет С/С++ языки в критические области - пристрелить на дальнем подступе. И никак иначе! А лучше пристрелить вообще!
Только проверенные и только НАДЕЖНЫЕ языки высокого уровня! С и С++ не является языком высокого уровня - он застрял на серединке, в нем нет ГЛАВНОГО - в нем нет ЧИТАБЕЛЬНОСТИ КОДА! Все приплыли, и проект F-35 как бы на это намекает, много АДА с примесью С. Вот и до сих пор кувыркаются. Так что только Паскаль, Ада и Фортран. Ну еще можно ассемблер, где это нужно.

Если Вы не любите кошек, Вы просто не умеете их готовить.

...
С++ по читаемости зависит почти исключительно от программиста. Возможно всё.

Автор: asv363 2.12.2016, 16:20

QUOTE(Superwad @ 2.12.2016, 13:14) *
Тех кто тянет С/С++ языки в критические области - пристрелить на дальнем подступе. И никак иначе! А лучше пристрелить вообще!

Необоснованная критика, полагаю.

QUOTE(Superwad @ 2.12.2016, 13:14) *
Только проверенные и только НАДЕЖНЫЕ языки высокого уровня! С и С++ не является языком высокого уровня - он застрял на серединке, в нем нет ГЛАВНОГО - в нем нет ЧИТАБЕЛЬНОСТИ КОДА! Все приплыли, и проект F-35 как бы на это намекает, много АДА с примесью С. Вот и до сих пор кувыркаются. Так что только Паскаль, Ада и Фортран. Ну еще можно ассемблер, где это нужно.

"Читабельность кода" зависит от документирования процесса и опыта и квалификации читающего. Как сугубо личное мнение - чем выше по уровню язык, тем менее контролируется аппаратная архитектура.

Автор: Татарин 2.12.2016, 16:20

Цитата(Superwad @ 2.12.2016, 13:18) *
Насчет спец. процессора. Сколько было эйфории по поводу Java и что появится куча спец. процессоров поддерживающие Java на уровне железа. И хде они? Все крутиться на обычных серийных процессорах.

А какая тут связь? Ява-процессоры просто никому не нужны.

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

Автор: Татарин 2.12.2016, 16:22

Цитата(VBVB @ 2.12.2016, 14:19) *
Интересно еще узнать, что конкретно за машины используются на БАЭС для работы с ГЕФЕСТом.

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

Автор: AtomInfo.Ru 2.12.2016, 16:54

QUOTE(Татарин @ 1.12.2016, 20:34) *
Вот этот момент мне показался самым... странным в интервью.
Мощность машин быстро растёт.


Несмотря на то, что растёт, требование станции (одна кампания за рабочую смену) еле-ели выполняется с Гефестом, то есть, с уравнением диффузии. Впритык. Так что пока недостаточно выросла.

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

Автор: arcanist 3.12.2016, 2:44

Цитата(Татарин @ 2.12.2016, 15:01) *
Если Вы не любите кошек, Вы просто не умеете их готовить.

...
С++ по читаемости зависит почти исключительно от программиста. Возможно всё.

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

Автор: MVS 3.12.2016, 12:39

QUOTE(arcanist @ 3.12.2016, 2:44) *
по читаемости возможно. но я думаю, вы не будете спорить, что в той же яве возможностей выстрелить себе в ногу куда меньше, чем в С++. Я думаю, автор именно это имел в виду, говоря о низкоуровневых языках


И как это компутеры вообще работают? Ведь все операционки - Виндоус, Линукс и все остальные Юниксы, включая проприетарные - написаны, о ужас! на С++ rolleyes.gif

Может дело не в языках, а в квалификации программистов?

Автор: arcanist 3.12.2016, 12:50

Цитата(MVS @ 3.12.2016, 12:39) *
И как это компутеры вообще работают? Ведь все операционки - Виндоус, Линукс и все остальные Юниксы, включая проприетарные - написаны, о ужас! на С++ rolleyes.gif

Может дело не в языках, а в квалификации программистов?

вот так и работают. Вы список патчей для windows видели?
Несовершеннен человек, к сожалению. Даже у самых лучших программистов ( а это ешё вопрос, где этих самых хороших программистов найти и сколько им потребуется платить ) есть норма ошибок на количество строк кода.

Автор: MVS 3.12.2016, 15:38

QUOTE(arcanist @ 3.12.2016, 12:50) *
вот так и работают. Вы список патчей для windows видели?


Видел. И что дальше? Ни одной ОС написанной на Яве нет. Как и все крупные программы типа БД или САПР - написаны на С++. Вычислительные с плавающей точкой - в основном Фортран, целочисленные - С++.

По опыту 8 лет работы в суперкомп. отделе Интела не видел ни одной вычислительной программы, написанной на чем-либо, кроме Фортрана и С-С++ (иногда на смеси этих языков). А на контроллерах и ускорителях вообще даже Фортрана нет, сплошной С.

Я блин, даже нормального сишника не могу найти в свой отдел, в hh сплошной ширпотреб - ява, C# да веб-программисты.


Автор: MVS 3.12.2016, 15:46

И еще. Что мне толку,что эти Явы спасают от глупых ошибок, если люди на собеседованиях даже формат числа с плавающей точкой не знают? Вырастили блин, поколение пепси среди инженеров.

Автор: AtomInfo.Ru 3.12.2016, 15:58

Уважаемые участники, не оффтопьте, пожалуйста. Вернусь из командировки, перенесу отдельно в новую тему. - Модератор

Автор: Татарин 3.12.2016, 18:11

Цитата(AtomInfo.Ru @ 2.12.2016, 16:54) *
Несмотря на то, что растёт, требование станции (одна кампания за рабочую смену) еле-ели выполняется с Гефестом, то есть, с уравнением диффузии. Впритык. Так что пока недостаточно выросла.

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

У меня был упор на то, что мощность "при желании растет". Без суперкомпьютеров.
НЯП, диффузия - это массивно-параллельные вычисления. Там при реальном желании/требовании скорости (реальном - это подкрепленном оплатой) можно очень многое придумать без покупки многопроцессорного монстра. Монте-Карло немного хуже в смысле аппаратного/спецвычислительного ускорения, но лишь немного.

Я видел, как подобные задачи решаются для 3д-рендеринга, там где коммерческие интересы реально упираются в скорость вычисления. Напихать в стойку побольше лезвий - это не всегда самое дешевое. Про майнинг криптовалют я вообще молчу. Там вычмоща отдельно взятой фермы бывает такая, что и рекордные суперкомпы отдохнут.
Если на АЭС есть _реальная_ потребность (то есть, практическая выгода, а не абстрактное "хорошо бы") от более сложных алгоритмов, то эти алгоритмы можно заставить бегать сильно быстрее на относительно дешевом железе.

Автор: Татарин 3.12.2016, 18:19

Цитата(arcanist @ 3.12.2016, 2:44) *
по читаемости возможно. но я думаю, вы не будете спорить, что в той же яве возможностей выстрелить себе в ногу куда меньше, чем в С++. Я думаю, автор именно это имел в виду, говоря о низкоуровневых языках

Ни в коем случае не буду.
У автора - вообще мухи и котлеты в одном супе с гайковертом.
Если С++ - "низкоуровневый", то каким боком лучше столь же низкоуровневый, но более примитивный и убогий Паскаль? И каким боком в список желательных языков вообще попал ассемблер? smile.gif

Ну и Фортран при всем моем уважении к Традиции и накопленной невероятно мощной базе научного кода - никак не назовешь современным высокоуровневым языком, помогающим избежать ошибок. Да, я знаю про Фортран-99, наверняка есть и дальнейшие продвижки, но все-таки, нужно признать, что единственная причина ему жить сейчас - наследие и совместимость (в широком смысле, включая много привыкших к нему людей).
Поскольку язык в таких делах сильно вторичен, выгод от перехода на ту же Яву не сильно много или вообще нет. Но это же не значит, что Фортран чем-то хорош. smile.gif

Автор: Татарин 3.12.2016, 18:25

Цитата(MVS @ 3.12.2016, 12:39) *
И как это компутеры вообще работают? Ведь все операционки - Виндоус, Линукс и все остальные Юниксы, включая проприетарные - написаны, о ужас! на С++ rolleyes.gif

Может дело не в языках, а в квалификации программистов?

Квалификация - она само собой. Конечно, на С++ можно и нужно писать качественный код.
Просто на С++ (С, Паскале) ошибке легче иметь катастрофические для программы/системы последствия, чем такой же ошибке на Яве: прямой доступ к памяти, не-манагед код.

Автор: MVS 3.12.2016, 19:52

QUOTE(Татарин @ 3.12.2016, 18:25) *
Квалификация - она само собой. Конечно, на С++ можно и нужно писать качественный код.
Просто на С++ (С, Паскале) ошибке легче иметь катастрофические для программы/системы последствия, чем такой же ошибке на Яве: прямой доступ к памяти, не-манагед код.


Конечно проще, кто спорит. На Яве, на бейсике. Как школьники. Только потом не надо ныть, что у нас кодов нет, и никто их писать не умеет.

Автор: Syndroma 3.12.2016, 20:43

Цитата(Татарин @ 3.12.2016, 20:11) *
Монте-Карло немного хуже в смысле аппаратного/спецвычислительного ускорения, но лишь немного.

Монте-Карло по сути своей очень хорошо параллелится. Трудно представить алгоритм, который параллелился бы лучше.

Господа программисты, а почему в тему никто ещё не вкинул слово "C++11"?

Автор: Alexll 4.12.2016, 2:52

Цитата(arcanist @ 3.12.2016, 12:50) *
вот так и работают. Вы список патчей для windows видели?
Несовершеннен человек, к сожалению. Даже у самых лучших программистов ( а это ешё вопрос, где этих самых хороших программистов найти и сколько им потребуется платить ) есть норма ошибок на количество строк кода.


Согласен.

Кому любопытно - обновления последней оси от дяди Билла (Windows 10) - это поэма! Идет постоянное лихорадочное исправление косяков. На нормальных компьютерах это не так заметно,хотя временами напрягает, а вот на смартфонах - исправляют одно, косячат другое, у мну смарт Microsoft Lumia 650 - задолбался обновлять и перегружать...

Вот, можете сами поглядеть:

https://support.microsoft.com/ru-ru/help/22880/1607-windows-10-update-history?ocid=1607

rolleyes.gif

Автор: Татарин 4.12.2016, 9:08

Цитата(Syndroma @ 3.12.2016, 20:43) *
Монте-Карло по сути своей очень хорошо параллелится. Трудно представить алгоритм, который параллелился бы лучше.

Господа программисты, а почему в тему никто ещё не вкинул слово "C++11"?

Монте-Карло содержит условные переходы, плохо влазит под SIMD и требует полноценного (с условным исполнением) процессора на каждую ветку вычислений, НЯП.

А зачем и почему именно 11?

Автор: Татарин 4.12.2016, 9:11

Цитата(MVS @ 3.12.2016, 19:52) *
Конечно проще, кто спорит. На Яве, на бейсике. Как школьники. Только потом не надо ныть, что у нас кодов нет, и никто их писать не умеет.

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

Автор: Syndroma 4.12.2016, 10:12

Цитата(Татарин @ 4.12.2016, 11:08) *
Монте-Карло содержит условные переходы, плохо влазит под SIMD и требует полноценного (с условным исполнением) процессора на каждую ветку вычислений, НЯП.

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

Цитата(Татарин @ 4.12.2016, 11:08) *
А зачем и почему именно 11?

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

Автор: Татарин 4.12.2016, 20:57

Цитата(Syndroma @ 4.12.2016, 10:12) *
Зато каждый элемент выборки абсолютно независим от всех остальных. Применительно к графике это означает, что цвет одного пикселя может вычисляться одновременно на ста процессорах.
C++11 отличается от C++ так же, как C++ от C. Совсем другой подход к программированию. Страуструп вообще говорит, что это новый язык.

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

А С++03 не отличался от С++ версии 1989-го? smile.gif

Отличия стандарта 11-го года от 3-го - точно такая же эволюция, а не революция.
Просто со временем фич набирается немало.

Автор: Superwad 5.12.2016, 8:16

Спасибо админу за его терпение, за наш флуд. Да эту тему нужно выделить в отдельную ветку.
А теперь отвечу по порядку:
1) С/С++ отнес к языкам среднего уровня - так как это и не язык низкого уровня (Асм), но и не язык высокого уровня - он не "читается" как обычный текст (именно это имел ввиду Вирт, когда давал обоснование языку высокого уровня - он должен восприниматься человеком как обычный текст (например, как читать литературу). С языки не читабельны, не воспринимаются человеком.
2) по статистике (не мной замечено, а буржуями! за бугром) - 70 % времени уходит на отладку и вылавливание логических ошибок (самые дорогие ошибки!). Поэтому читабельность и восприятие логики программы на первом месте при отладке. А восстанавливать логику программы читая с и h фалы и составляя в мозгу логику кодера - психушка обеспечена!!!
3) А еще приведите мне довод о великолепной стандартизации С/С++! Это миф!!! Блин, из-за этого я потерял целый месяц, ковыряясь в с++ исходнике одного драйвера для контроллера на Линуксе. Это было жесть!!!!!!!!!!!! Мне надо было из Паскаля (Lazarus), получить из динамической библиотеки данные. Агась, держи карман пошире. Все было написано так красиво, и (кстати, это работало, НО! только исключительно на си angry.gif ). Использовались шаблоны и перегруженный вызов функции. Т.е. стандартные вещи. Угу. Так вот, все дело в том что перегруженные функции не работала как положена, вызывалась только первая в цепочке, а мне надо была вторая. При разборе в интернете нашел инфу что это сильно зависит от разработчика конкретной версии компилятора.
Короче, проблему то я решил, все заработало красиво и как положено. А самое прикольное в том, что процесс считывания, буферизации и сохранения данных был многопоточным, распараллеленым - и это все на Паскале. Так можно писать хорошие и нужные вещи и на Паскале, с меньшими затратами.
ЗЫ. Хотя мой любимый FPC использует компилятор с/с++ что и установленный в системе был.
Та что я сужу не по наслышке, я столкнулся с глубинами ада по самое нехочу. Потому с/с++ не хочу. Серьезно. Потому и не хотят идти в С/С++ кодеры - зачем напрягать извилины там, где не надо. Потому С/С++ нельзя близко допускать к критическим областям - пристреливать за горизонтом!!!!!!! Ибо выловить логические ошибки в таком коде практически нереально!!! Поэтому и взлетел проект Буран, а F-35 летает низэнько низэнько, как крокодилы над землей. wink.gif

Автор: AtomInfo.Ru 5.12.2016, 16:44

QUOTE(Superwad @ 5.12.2016, 8:16) *
Спасибо админу за его терпение, за наш флуд. Да эту тему нужно выделить в отдельную ветку.


Это гостиничному интернету спасибо в далёких краях, точнее его "скорости" biggrin.gif

Вернусь - выделю.

Автор: arcanist 5.12.2016, 17:35

Цитата(Superwad @ 5.12.2016, 8:16) *
1) С/С++ отнес к языкам среднего уровня - так как это и не язык низкого уровня (Асм), но и не язык высокого уровня - он не "читается" как обычный текст (именно это имел ввиду Вирт, когда давал обоснование языку высокого уровня - он должен восприниматься человеком как обычный текст (например, как читать литературу). С языки не читабельны, не воспринимаются человеком.

Тогда надо срочно переносить ваш паскаль код на КОБОЛ. Он ещё более близок к человеческому восприятию, чем паскаль

Автор: Татарин 5.12.2016, 21:01

Цитата(Superwad @ 5.12.2016, 8:16) *
Спасибо админу за его терпение, за наш флуд. Да эту тему нужно выделить в отдельную ветку.
А теперь отвечу по порядку:

Ваш пост сводится к следующему: Вы любите Паскаль и не умеете читать сишный код. Ну и что с того? Почему Вы решили, что это распространяется на всех? smile.gif

Меня вот Паскаль раздражал - своей бессмысленной и тупой многословностью и необходимостью вместо программирования постоянно бороться с убогостью языка, так я ж не делаю из личных предпочтений глобальных выводов. Нравится кому-то писать "begin" вместо простой открывающей скобки - да барабан в руки, флаг на шею (ну, как в Паскале принято smile.gif)
На самом деле, если убрать в сторону мелкие неудобства и общую убогость Паскаля, с С они близнецы-братья, благо писаны в одно и то же время в одной и той же парадигме процедурного программирования. Ваше удивление и торжествующее доказательство того, что на Паскале, оказывается, если помучаться, тоже можно что-то путное написать - странно, ибо конечно можно!

Паскаль - вполне адекватный своему времени функциональный язык с достаточно развитыми средствами.
Си он проиграл из-за раздражающих нелогичностей и мелочей. Миллионы программистов могли выбирать, но при прочих равных, мелочи оказались решающи Си был просто удобнее.
Отвлекитесь на секунду от личных предпочтений и посмотрите глобально: абсолютное большинство софта Человечества (в том числе - почти весь системный, критичный к ошибкам, лежащий в основе нашей цивилизации) написано на С и его наследниках. Индустрия выбрала его как стандарт не просто так, и Паскаль остался маргинальным - тоже не без причин.
Да, проиграл. Из-за мелочей. Да, мелочи - это мелочи. Но проиграл. 40-50 лет назад.

Но С++ ставить на одну доску с С/Паскалем? Это, простите, дикость. Ибо это уже смена парадигмы - первый объектно-ориентированный язык, принятый индустрией. Это уже другой век софтовой индустрии.

И даже этот век - тоже уже ушёл; С++, как и С в своё время ушёл в свою нишу, которая постоянно сужается.
Преимущества для большинства проектов managed кода настолько велики (не говоря уж о гигантском рывке новых языков в синтаксисе, функционале и общей выразительности), что нужно иметь очень, очень веские основания, чтобы выбирать С++ для нового проекта.
Посмотрите С#, посмотрите, насколько много рутинной работы может брать на себя язык, насколько коротко и понятно можно записывать сложные вещи, которые в тех же С/Паскале требовали бы чуть ли не страницы сложно читаемого кода. И это я ещё стороной обхожу специализированные для своей области скрипты. А ведь накладные расходы даже на интерпретацию с общим ростом мощности сильно убавили в процентном отношении!
Сравнимы ли С/Паскаль в удобстве в обращении с матрицами с Матлабом? Или при работе с текстами с Ruby? Да там пропасть необозримой ширины! smile.gif


___
...прошло 50 лет, космические корабли бороздят просторы Вселенной, нейросети водят машины, а вычмощь телефона у Вас в кармане превышаем суммарную вычмощь всей Земли того времени (включая всё население с арифмометрами)...
...и тут выходите Вы и вспоминаете, что когда-то в прошлом веке был такой очень полезный транзистор МП-39 и такой язык - Паскаль, и на нём тоже что-то писали. smile.gif

Что тут можно сказать?

Оглянитесь вокруг.
Вокруг появилось много нового и полезного.
Я не призываю Вас выкинуть, наконец, эту палку-копалку (мало ли, и она в нужный момент сойдёт за инструмент), но блин! Оглянитесь вокруг, наконец!

Автор: MVS 5.12.2016, 22:39

QUOTE(Татарин @ 4.12.2016, 9:11) *
Как-то, мягко говоря, странно ставить Яву в один ряд с Бэйсиком - языки из разных миров.
Точно так же, как странно определять квалификацию расчетчика по тому, каким языком он пользуется. Алгоритмы можно потом хоть на ассемблер и Лего-язык перевести, то набота кодеров. Были б алгоритмы.


Вы контроллеры программировали? На каком языке там пишут, знаете? А на суперкомпах? Список кодов из spec.org или top500 смотрели?

О чем вообще говорить, элементарной грамотности нет.

Автор: MVS 5.12.2016, 22:50

QUOTE(Татарин @ 4.12.2016, 9:11) *
Алгоритмы можно потом хоть на ассемблер и Лего-язык перевести, то набота кодеров. Были б алгоритмы.


О, вот это мне знакомо! Дофига гениев, придумывающих "алгоритмы". Только вот кодеров нет. Инженеров то есть.

А так каждый дурак может рассуждать про монте-карло и simd.

Автор: Татарин 5.12.2016, 22:57

Цитата(MVS @ 5.12.2016, 22:39) *
Вы контроллеры программировали? На каком языке там пишут, знаете? А на суперкомпах? Список кодов из spec.org или top500 смотрели?

О чем вообще говорить, элементарной грамотности нет.

Сейчас именно их я и программирую. smile.gif

У кого? smile.gif

Автор: MVS 5.12.2016, 23:01

QUOTE(Татарин @ 5.12.2016, 22:57) *
Сейчас именно их я и программирую. smile.gif


Поздравляю. rolleyes.gif Нашу отечественную программистскую промышленность.

Надеюсь, теперь наши граждане смогут ловить покемонов и внутри ВВЭР smile.gif

Автор: Татарин 5.12.2016, 23:13

Цитата(MVS @ 5.12.2016, 22:50) *
О, вот это мне знакомо! Дофига гениев, придумывающих "алгоритмы". Только вот кодеров нет. Инженеров то есть.

А так каждый дурак может рассуждать про монте-карло и simd.

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

А конкретно в расчётах (тему обсуждения ещё помните, да? smile.gif) - закодить это даже не 1/10 часть работы.
Это всё равно что электронику - к умению паять свести.

Вы, я вижу, полагаете, что умение кодить и знание WinAPI/TCP/IP стека/HAL/ассемблера х86/что там ещё по месту нужно - некая врождённая магия, данная богами?
Да нет... просто специфичные знания, которые приобретаются по мере надобности.

Дурак, конечно, может о монте-карло и simd рассуждать. Только вот к чему это сказано? smile.gif

Автор: Татарин 5.12.2016, 23:16

Цитата(MVS @ 5.12.2016, 23:01) *
Поздравляю. rolleyes.gif Нашу отечественную программистскую промышленность.

Надеюсь, теперь наши граждане смогут ловить покемонов и внутри ВВЭР smile.gif

Вы программируете покемонов?

Вы вообще чем занимаетесь? Что-то кроме С++ видели?

Автор: Superwad 6.12.2016, 7:41

Цитата(Татарин @ 5.12.2016, 21:01) *
Ваш пост сводится к следующему: Вы любите Паскаль и не умеете читать сишный код. Ну и что с того? Почему Вы решили, что это распространяется на всех? smile.gif

Меня вот Паскаль раздражал - своей бессмысленной и тупой многословностью и необходимостью вместо программирования постоянно бороться с убогостью языка, так я ж не делаю из личных предпочтений глобальных выводов. Нравится кому-то писать "begin" вместо простой открывающей скобки - да барабан в руки, флаг на шею (ну, как в Паскале принято smile.gif)
На самом деле, если убрать в сторону мелкие неудобства и общую убогость Паскаля, с С они близнецы-братья, благо писаны в одно и то же время в одной и той же парадигме процедурного программирования. Ваше удивление и торжествующее доказательство того, что на Паскале, оказывается, если помучаться, тоже можно что-то путное написать - странно, ибо конечно можно!

Паскаль - вполне адекватный своему времени функциональный язык с достаточно развитыми средствами.
Си он проиграл из-за раздражающих нелогичностей и мелочей. Миллионы программистов могли выбирать, но при прочих равных, мелочи оказались решающи Си был просто удобнее.
Отвлекитесь на секунду от личных предпочтений и посмотрите глобально: абсолютное большинство софта Человечества (в том числе - почти весь системный, критичный к ошибкам, лежащий в основе нашей цивилизации) написано на С и его наследниках. Индустрия выбрала его как стандарт не просто так, и Паскаль остался маргинальным - тоже не без причин.
Да, проиграл. Из-за мелочей. Да, мелочи - это мелочи. Но проиграл. 40-50 лет назад.

Но С++ ставить на одну доску с С/Паскалем? Это, простите, дикость. Ибо это уже смена парадигмы - первый объектно-ориентированный язык, принятый индустрией. Это уже другой век софтовой индустрии.

И даже этот век - тоже уже ушёл; С++, как и С в своё время ушёл в свою нишу, которая постоянно сужается.
Преимущества для большинства проектов managed кода настолько велики (не говоря уж о гигантском рывке новых языков в синтаксисе, функционале и общей выразительности), что нужно иметь очень, очень веские основания, чтобы выбирать С++ для нового проекта.
Посмотрите С#, посмотрите, насколько много рутинной работы может брать на себя язык, насколько коротко и понятно можно записывать сложные вещи, которые в тех же С/Паскале требовали бы чуть ли не страницы сложно читаемого кода. И это я ещё стороной обхожу специализированные для своей области скрипты. А ведь накладные расходы даже на интерпретацию с общим ростом мощности сильно убавили в процентном отношении!
Сравнимы ли С/Паскаль в удобстве в обращении с матрицами с Матлабом? Или при работе с текстами с Ruby? Да там пропасть необозримой ширины! smile.gif
___
...прошло 50 лет, космические корабли бороздят просторы Вселенной, нейросети водят машины, а вычмощь телефона у Вас в кармане превышаем суммарную вычмощь всей Земли того времени (включая всё население с арифмометрами)...
...и тут выходите Вы и вспоминаете, что когда-то в прошлом веке был такой очень полезный транзистор МП-39 и такой язык - Паскаль, и на нём тоже что-то писали. smile.gif

Что тут можно сказать?

Оглянитесь вокруг.
Вокруг появилось много нового и полезного.
Я не призываю Вас выкинуть, наконец, эту палку-копалку (мало ли, и она в нужный момент сойдёт за инструмент), но блин! Оглянитесь вокруг, наконец!

Сколько времени тратиться на написание кода? 17 %?! Это что такая офигенная трудоемкость? Так что это не аргумент. Не убедили. Никак. Я работал с С/С++ и с Паскалем. Да,я признаю, что мне нравится Паскаль тем, что он четкий язык и так как я пишу программы для работы себе (т.е. это не основная моя задача), то тратить много времени на отладку у меня нет. Специфика работы. Посему я выбираю более практичнее и менее затратное решение. Себестоимость разработки на С/С++ и Паскале РАЗНАЯ - на Паскале трудоемкость ниже. Просто программисты которые пишут на С/С++ - это просто бесконечная золотая жила на поддержке и обновлениях. Ибо писать качественный софт - это не выгодно!!! Это бизнес, ничего личного. К сожалению это мировой тренд не только в программировании, но и в технике (например одноразовые авто, электротехника, телефоны, смартфоны планшеты и т.д.). Вот поэтому в критических областях С/С++ нужно пристреливать на дальних подступах. Ибо нужен инструмент не позволяющий допускать делать ошибки на ровном месте. С подобные языки это не гарантируют и не обеспечивают.
По поводу стандарта - ха и много раз ха. Да нету этого стандарта на практике. В теории - да, на практике - как карта ляжет у разработчика. я уже это приводил выше. НЕТУ на практике. Особенно расскажите мне стандарт на М$ оффис, как его выполняет сама компания в своих продуктах ? Ответ - да никак.
Да и вообще есть мнение (не моё), что С/С++ надо пристрелить - ибо это язык для диверсантов. Крайне нехороший язык.
ЗЫ. Ну не скажу что Паскаль такой уж древний язык. Вы путаете классический Виртовский от того на чем пишут сегодня. Delphi/FPC - очень сильно ушли от него, много хорошего появилось в нем благодаря С/С++ (не без этого) - это и дополнительные операторы при работе с циклами (Break, Continue - не нужно Goto), это и перегруженные процедуры и функции, дженерики, работа с потоками. Чего ещё то нужно?

Автор: Superwad 6.12.2016, 11:03

А чтобы больше не писать про все минусы языков С, дам ссылку - там все изложено предельно четко и ясно https://ru.wikiversity.org/wiki/%D0%9A%D1%80%D0%B8%D1%82%D0%B8%D0%BA%D0%B0_C%2B%2B . Там достается и чистому С.

Автор: Татарин 6.12.2016, 11:13

Цитата(Superwad @ 6.12.2016, 7:41) *
Себестоимость разработки на С/С++ и Паскале РАЗНАЯ - на Паскале трудоемкость ниже. Просто программисты которые пишут на С/С++ - это просто бесконечная золотая жила на поддержке и обновлениях. Ибо писать качественный софт - это не выгодно!!!

Нет, стоимость С++ проектов ниже.
В общем-то в истории индустрии известна только одна фирма, которая делала крупные, серьёзные проекты на Паскале: Борланд с их компиляторами и средой. Вроде, и они перешли на С++, НЯЗ.
Ну и глупости же говорите очевидные про специально написанный криво софт.

Цитата(Superwad @ 6.12.2016, 7:41) *
Да и вообще есть мнение (не моё), что С/С++ надо пристрелить - ибо это язык для диверсантов. Крайне нехороший язык.

Ну, есть мнение, что нами правят рептилоиды с Нибиру, так что с того?
Тут вопрос что с чем сравнивать. Конечно, С/С++ - небезопасные языки. Но Вы же решили сравнивать с Паскалем, который в этом смысле либо там же, либо хуже.

Цитата
ЗЫ. Ну не скажу что Паскаль такой уж древний язык. Вы путаете классический Виртовский от того на чем пишут сегодня. Delphi/FPC - очень сильно ушли от него, много хорошего появилось в нем благодаря С/С++ (не без этого) - это и дополнительные операторы при работе с циклами (Break, Continue - не нужно Goto), это и перегруженные процедуры и функции, дженерики, работа с потоками. Чего ещё то нужно?

Почему же "путаю"? Дельфи я сам в своё время пользовал для in-situ поделок и оболочек - для 90-х годов инструмент был потрясающий, пожалуй, на тот момент, почти не отставал (как язык) от альтернатив, а уж среда на тот момент была и вовсе исключительной.
Но в целом ветка Паскалей отстаёт в развитии на 10-30 лет, что в программировании - эпоха. Ну вот как тот самый элементарный break, который был в С с рождения.

Что нужно? Как обычно - десятки полезных вещей и избавление от сотни неудобств. Нормальная перегрузка операторов, нормальные делегаты, аттрибуты - мало ли что. Покажите мне, как выглядит в Паскале класс-итератор, а особенно - его использование? Ну вот то-то и оно.
И появляется мешанина кода, логика в которой просто теряется. И появляются ошибки. Ну, точнее, появлялись бы, если б на Паскале продолжали писать достаточно сложные проекты. Наследники Паскаля - та же Ада - страдают тем же самым (да, Ф-35 тут пример).

Код истребителей Сухого написан на С++.
Летают.

Автор: LAV48 6.12.2016, 11:21

Кажется этот спор мне http://bash.im/quote/442483 напоминает:
softwarer> ...... Ваши выкладки построены на ложном сопоставлении "рабочего" из КБ/опытного производства и "рабочего" с конвейера (серийного производства). Разумеется, это даёт нелепые результаты. Примерно так же Вы могли бы судить, не видя разницы между деятельностью художника и маляра: кустарщина, мол, каменный век. Хреновый ты работник, Рембрандт, учись у Малевича - краскопульт взял и вперёд, в промышленное производство.

Автор: Татарин 6.12.2016, 11:50

Цитата(LAV48 @ 6.12.2016, 11:21) *
Примерно так же Вы могли бы судить, не видя разницы между деятельностью художника и маляра: кустарщина, мол, каменный век. Хреновый ты работник, Рембрандт, учись у Малевича - краскопульт взял и вперёд, в промышленное производство.

:_

Это на самом деле великолепное сравнение, потому что Рембранту по сути ВСЁ РАВНО, чем работать. Мастер может использовать для шедевра кусок камня, шмат глины или рисовать по бумаге древесным углем - качество работы определяется не инструментом. На стене туалета тоже можно чем угодно рисовать, там важен больше смысл, чем чёткость линий.

Точно так же те же расчёты можно писать на скрипте Матлаба, и они всё равно будут иметь огромную ценность как расчёты.
Или поделка для лаборатории, считывающая данные с АЦП-карты и что-то там пишущая в файл может быть написана на чём угодно, хоть на Паскале, в самом деле.

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

Автор: generalissimus1966 6.12.2016, 12:10

QUOTE(Татарин @ 6.12.2016, 0:13) *
Вы кодера с инженером-то не мешайте.
Гениев, придумывающих алгоритмы (подразумевая _новые_ и _полезные_ алгоритмы), - очень мало. Вот просто-таки дико мало, один на тысячу.

Я знаю одного, его ник в ЖЖ nabbla1. Он придумал взвешенное симметричное троичное БПФ. Оно на доли процента медленнее классического БПФ с основанием 2^N, но, при этом, гораздо лучше работает при расчёте антенн - У НЕГО ЕСТЬ ЦЕНТРАЛЬНАЯ ТОЧКА.
QUOTE(Татарин @ 6.12.2016, 0:13) *
И сидят они, как правило, на позициях принципалов, и даже не сеньоров.

А он, между тем, даже пока не кандидат наук.

Автор: Superwad 6.12.2016, 16:27

Это плохо. что критический код пишут на с++. Ибо результат работы непредсказуем. Я сам с этим столкнулся. А разбирать код какой получиться из-за условной компиляции из разных файлов - я не мазохист, увольте с этой должности. Я предпочту "ленивый" качественный однозначный код.
По поводу многословности Паскаля (да хотя бы FPC) - я просто не понимаю, про что говорите. Язык вполне устоявшийся, команды практически стандартизированы, необходимые вещи появляются, если надо. А вот С++ четкого набора команд нет. Я уже привел ссылку, где все разобрано по полочкам. Для написания приложений (а тем более критических приложений), нужен точный ясный инструмент, который выдает ОДНОЗНАЧНЫЙ код и результат. С/С++ таким похвастаться не может. В это ссылке, что привел С/С++ не относят к языкам высокого уровня. Потому что он язык чуть выше ассемблера.
Кстати, ракеты летают не на С/С++. Российские. А на собственном коде, к коду вопросов нет, есть вопросы к железу. Так и тут. НЕЛЬЗЯ использовать С/С++ для критических приложений. НЕЛЬЗЯ. Даже заведомо отлаженный и протестированный С/С++ код может содержать баг, который вылезет в самый неприятный момент. Сам на это натыкался. Баг был в сторонней библиотеке.

Автор: Татарин 6.12.2016, 16:44

Цитата(generalissimus1966 @ 6.12.2016, 12:10) *
Я знаю одного, его ник в ЖЖ nabbla1. Он придумал взвешенное симметричное троичное БПФ. Оно на доли процента медленнее классического БПФ с основанием 2^N, но, при этом, гораздо лучше работает при расчёте антенн - У НЕГО ЕСТЬ ЦЕНТРАЛЬНАЯ ТОЧКА.

А он, между тем, даже пока не кандидат наук.

Ссылку можно?

Я уже по ЖЖ вижу, что человек мыслит нестандартно. smile.gif

Автор: generalissimus1966 6.12.2016, 17:06

QUOTE(Татарин @ 6.12.2016, 17:44) *
Ссылку можно?

На что ссылку, у него же тег в ЖЖ есть "Уравновешенное троичное БПФ", нажимай, всё покажут!

Автор: Татарин 6.12.2016, 17:30

Цитата(Superwad @ 6.12.2016, 16:27) *
НЕЛЬЗЯ использовать С/С++ для критических приложений. НЕЛЬЗЯ.

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

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

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

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



Автор: Татарин 6.12.2016, 17:38

Цитата(generalissimus1966 @ 6.12.2016, 17:06) *
На что ссылку, у него же тег в ЖЖ есть "Уравновешенное троичное БПФ", нажимай, всё покажут!

Уже читаю. Он хорошо объясняет БПФ _вообще_. smile.gif

Автор: Syndroma 6.12.2016, 17:48

Цитата(Татарин @ 6.12.2016, 19:30) *
например, сейчас во многих случаях дешевле платить накладные расходы рантайм того же сборщика мусора, чем мучаться с потенциальными проблемами аллокации памяти, и это лишь один пример из очевидного.

C++11 успешно решает эту проблему. delete становится ненужным, а у new появляются серьёзные альтернативы.

Автор: Татарин 6.12.2016, 17:58

Цитата(Syndroma @ 6.12.2016, 17:48) *
C++11 успешно решает эту проблему. delete становится ненужным, а у new появляются серьёзные альтернативы.

Не догнал, что тут нового?
Смарт поинтеры с перегрузкой new/delete - не предлагать. Не вчера придумано, и проблемы в полной мере не решает.

Возможность по гнилому поинтеру тихо изменить уже освобождённый кусок памяти у нас осталась. А что нам нужно ещё для полного счастья?
Манагед код в этом смысле всё-таки даёт возможность прибить такое на месте преступления (и баг, и программиста). С++ - нет.

Автор: Syndroma 6.12.2016, 18:01

Цитата(Татарин @ 6.12.2016, 19:58) *
Не догнал, что тут нового?

Например, emplace. Конструирование объекта по месту хранения в контейнере. В таком сценарии new просто не нужен. Невероятно удобно, между прочим.

Автор: Татарин 6.12.2016, 18:07

Цитата(Syndroma @ 6.12.2016, 18:01) *
Например, emplace. Конструирование объекта по месту хранения в контейнере. В таком сценарии new просто не нужен. Невероятно удобно, между прочим.

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

Автор: Syndroma 6.12.2016, 18:18

Ещё раз упомяну слова Страуструпа про 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 6.12.2016, 18:28

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

Автор: alex_bykov 6.12.2016, 20:19

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

Автор: VBVB 6.12.2016, 22:45

QUOTE(alex_bykov @ 6.12.2016, 21:19) *
Я тут вас почитал, сижу, недоумеваю, как у меня система в 3 млн.строк кода на С++ вообще работает... wink.gif

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

Автор: armadillo 6.12.2016, 22:53

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


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

Автор: Татарин 6.12.2016, 23:18

Цитата(alex_bykov @ 6.12.2016, 20:19) *
Я тут вас почитал, сижу, недоумеваю, как у меня система в 3 млн.строк кода на С++ вообще работает... wink.gif

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

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

Автор: alex_bykov 6.12.2016, 23:46

QUOTE(VBVB @ 6.12.2016, 22:45) *
Александр, если не тайна сколько времени эта система в 3 млн.строк кода на С++ писалась и отлаживалась.
Интересно мнение от реального разработчика.
А то пишут часто, что с отладкой пары миллионов строк кода C++ можно больше времени потерять, чем потратить на написание.

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

Автор: Superwad 7.12.2016, 11:12

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

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

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

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

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

Автор: alex_bykov 7.12.2016, 11:44

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

Автор: Татарин 7.12.2016, 15:04

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

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

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

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


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

Автор: pappadeux 7.12.2016, 23:20

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

Автор: armadillo 7.12.2016, 23:24

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

Автор: aprudnev 8.12.2016, 0:38

Цитата(pappadeux @ 7.12.2016, 13:20) *
скорее бы пришел лесник...


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

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

Лесник, АУ?

Автор: armadillo 8.12.2016, 0:41

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

Автор: arcanist 8.12.2016, 2:10

Цитата(pappadeux @ 7.12.2016, 23:20) *
скорее бы пришел лесник...

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

Автор: Superwad 8.12.2016, 12:20

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

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

Автор: sch 8.12.2016, 20:50

Цитата(Superwad @ 8.12.2016, 13:20) *
1) Я писал, что логика в С++ размазана по двум файлам .с и .h. Чтобы восстановить логику нужно анализировать сразу два файла. Это хорошо для диверсантов - тот кто будет анализировать - психушка обеспечена wink.gif

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

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

Автор: alex_bykov 9.12.2016, 11:34

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

Автор: AtomInfo.Ru 9.12.2016, 11:45

QUOTE(alex_bykov @ 9.12.2016, 11:34) *
Не готов обсуждать достоинства и недостатки именно языков. Однако вчера расчётное ядро нашей СВРК получило паспорт Ростехнадзора... Ну и референтный опыт на 20+ блоках чего-то стоит, наверное.


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

Автор: alex_bykov 9.12.2016, 12:43

QUOTE(AtomInfo.Ru @ 9.12.2016, 11:45) *
Давно пора! Поздравляю smile.gif

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

Автор: aprudnev 10.12.2016, 7:08

Обсуждая C++ и C.

Ну во первых, удивительно но языки эти переносимы неплохо. На том же C даже на БЭСМ-6 умудрились компилятор сделать.

Во вторых, тут выше совершенно верно замечено, КАК надо писать сложные системы на C++ - небольшая команда ОЧЕНЬ квалифицированных специалистов должна создать фреймворк и внутренние стандарты. После чего уже даже и быдлокодеры смогут свои куски добавлять. Основной отличие жабы в том, что там быдлокодеры могут писать изначально, причем оно даже работать будет (но как крокодил, низенько - низенько).

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

В общем, подход с _фреймворк делает небольшая команда, все пользуются_ и _язык С++_ крайне правильный. Потому что - ну например, на JAVA написать надежный код - к сожалению, почти невозможно. То есть все абсолютно коды на JAVA которые я например когда то видел - имеют кучу ошибок, но самое главное - они крайне зависят от интерпретатора, и никто не гарантирует того, что через год программа не сломается. У нас (системщиков) есть правило - _все что написанно на JAVA - рано или поздно слопает память или зависнет, а потому его надо перевызывать регулярно_ (последняя история - у нас зависла карточка управления сервером, которая имела интерфейс на JAVA внутри себя - ну и как легко догадаться, через 2 года работы там что-то кончилось и она стала говорить что мол ошибка... А новые карточки идут со встроенным регулярным перевызовом, потому что авторы уже поняли, что невозможно обеспечить надежную многолетнюю работу, а эта штука работает всегда когда включен шнур питания. И поэтому встроенные системы писать на ней - очень сильно рисковать. На C++ - высокий порог вхождения, легко наляпать такое, что и бригада гуру не разберется, но зато при правильном фреймворке и внутренних стандартах - код будет крайне надежен, куда надежнее чем на JAVA или C#, потому что все ошибки вылезут сразу, а не как JAVA через полгода работы...

Хотя кстати с Ada идея была неплоха. Сделать строгий язык для отвественного программирования.

(Да, спасибо что лесник пришел. smile.gif smile.gif)

Автор: sch 10.12.2016, 13:42

Цитата(Superwad @ 7.12.2016, 12:12) *
1) Претензии к утверждению, что с и с++ являются языками высокого уровня, коими они не являются

Это вопрос религиозный, так что без меня.

Цитата(Superwad @ 7.12.2016, 12:12) *
2) Стандарт на С еще может и быть, а вот на С++ - какой это стандарт, если на выходе код работает как карта ляжет? Я это не теоретически говорю, а с практической точки зрения, ибо сам столкнулся.

Ну а в чём проблема-то? Будет ли работать амперметр, если воткнуть его в 220? Ну, как карта ляжет. Да, некоторые конструкции C++ в некоторых случаях приводят к неопределённому поведению (undefined behavior). Например, выход за границы массива или двойное освобождение памяти. И что?
Обычно неопределённое поведение возникает в ситуациях, когда на вход какой-то функции поданы некорректные данные, т.е. программа _уже_ работает неправильно. И в этой ситуации уже не важно, что будет дальше: ошибка уже случилась, правильного результата уже не будет, на каком бы языке мы ни писали.

Цитата(Superwad @ 7.12.2016, 12:12) *
3) Для программирования критического кода инструмент должен быть прямой как железная дорога, а не плутать по лесным тропинкам по лесу. Т.е. логика должна просматриваться в одном файле, а не размазана по разным.

Вы про .h/.cpp? Как правило, интерфейс компонента описан в h-файле, а реализация - в cpp. Исключение - шаблонные (template) классы и методы, которые всегда лежат в h-файле. Но если в проекте появился код с шаблонами, значит, Вы уже залезли на территорию, на которой конкурентов C++ можно пересчитать по пальцам.

Цитата(Superwad @ 7.12.2016, 12:12) *
Претензия к С/С++ в том, что при компиляции получается неоднозначный код и результат (опять же в зависимости от настроек директив компилятора).
Этого что мало? Этого уже достаточно, чтобы поставить крест на С++ как инструмента для написания критического программного обеспечения.

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

Цитата(Superwad @ 7.12.2016, 12:12) *
Про Паскаль, тот который FPC. Он развивается, выходят новые релизы. Мне он очень нравится. Я сейчас на нем пишу. Так как он делается на базе С , то в коде можно переключаться и делать вставки как на Асме, так и на чистом С.

Но это, обратите внимание, нестандарт, и привязывает Вас к определённому компилятору. Это, конечно, снимает множество проблем, но в дискуссии о языках не спортивно. C++ использует несколько другой подход:
1. Из кода на C++ можно вызвать любую функцию, имеющую интерфейс, описанный на языке C. Независимо от того, на каком языке эта функция реализована: на C, на C++, на ассемблере или на фортране.
2. Функцию, описанную (declared) на языке C, можно без проблем реализовать на C++.
3. Функции с интерфейсом на C++, реализованные в разных компонентах, совместимы, если они скомпилированы одним и тем же компилятором с одними и теми же настройками.

Цитата(Superwad @ 7.12.2016, 12:12) *
Почему пересел с Delphi на Lazarus? Переносимость кода на Линукс. Если пишешь на Паскале получаешь логически чистый код, ибо код читается и компилируется однозначно.

Про эту однозначность уже анекдоты сложены. :-) Анекдот такой:
Цитата
Винни Пух говорит Пятачку:
- Кристофер Робин прислал нам $10: тебе $8 и мне $8.
- Но Винни... По-моему, если сложить $8 и $8, $10 не получится...
- Ну как же... Я и программу написал, чтобы проверить. http://rextester.com/RRUOZ49518:
Цитата
program HelloWorld;
begin
if($8+$8=$10) then
writeln('$8+$8=$10');
end.

В общем, ты как хочешь, а я свои $8 уже потратил.


Цитата(Superwad @ 7.12.2016, 12:12) *
ДА, может нет того богатого инструментария - а он нужен для прикладников?

Нужен. Вот на http://forum.burmistr.ru/viewtopic.php?p=99687#p99687 ещё один любитель паскаля жалуется: в России сейчас внедряется ГИС ЖКЖ, данные в неё надо передавать по протоколу SOAP (т.е. подписать XML по ГОСТ и отправить по протоколу HTTP). И выясняется, что подходящих инструментов для этого на паскале нет (хотя и HTTP, и XML, и ГОСТ существуют давным-давно), а подтянуть существующие из других мест он не может.

Цитата(Superwad @ 7.12.2016, 12:12) *
А то, что вместо С++, начинают использовать Java и С# - это признак того, что не всё так сладко с С++.

Просто те преимущества, которые этот язык предоставляет, нужны не всем и не всегда.

Автор: Superwad 14.12.2016, 10:31

Цитата(alex_bykov @ 9.12.2016, 11:34) *
Не готов обсуждать достоинства и недостатки именно языков. Однако вчера расчётное ядро нашей СВРК получило паспорт Ростехнадзора... Ну и референтный опыт на 20+ блоках чего-то стоит, наверное.

Поздравляю.
Честно. То что люди делают - это хорошо, и результат впечатляет. Что могу сказать - ни ошибки ни бага!

Автор: Superwad 14.12.2016, 10:45

Леснику - большое спасибо за отдельную поляну wink.gif

Автор: Superwad 14.12.2016, 11:24

А теперь по существу.
Анекдот про дятла - увы это уже не шутка, а суровая реальность, констатация факта.
Качество программного кода сейчас - ниже плинтуса в основной своей массе.
Использование С++ - это поездка на авто без тормозов и систем безопасности (защиты). Вы когда нибудь ездили по общественным дорогам без тормозов? А мне приходилось, и не одну тысячу км отмахал с одним ручником (машина такая - образец гиганта французской мысли, потому ручник у неё на передние колеса и является стояночно-аварийным тормозом), что уже на уровне рефлексов иногда рука тянется к ручнику затормозить вместо ножного тормоза, особенно на светофорах.
И если уж коснулись автомобильной тематики, то для написания исполнительного кода для критически важных систем управления реального времени используют специально заточенный С, в котором нет освобождения памяти под переменными и прочие ограничения. Но даже применяя специализированный софт, умудряются допускать ошибки.
Так и тут - а есть ли нормальный специализированный софт, который позволяет на корню пресечь многие ошибки, какие можно опустить на ровном месте на С++. И не надо про правильно приготовленные программы и высокую квалификацию программистов - залететь можно на элементарном. ( Правило Мэрфи еще никто не опроверг - "Если деталь может быть вставлена неправильно - то неправильно она будет и вставлена". Если может быть допущена глупая случайная ошибка на ровном месте - то она обязательно будет. Пример - да есть тут один, прочитал на одном форуме -авиадвигатель для пассажирского боинга, прошел капремонт на сертифицированном предприятии, прошел обкатку (причем люди то опытные были, профи) - заметили на складе лишние трубочки - резко тормознули отгрузку - забыли установить после разборки, а если бы поставили на самолет blink.gif ).

Автор: Lerm 14.12.2016, 13:16

Не удержался. Качество программного продукта определяется в первую очередь методологией, что включает корректным подходом к тестированию (во всех видах), review кода и использования правильных стандартов разработки (в частности тем, какие языковые конструкции можно использовать и какие нельзя). При правильном применении этого подхода – язык разработки глубоко вторичен. При нарушениях в этом процессе (проблемы с тестированием, отсутствие review кода и так далее) – у проекта уже такие проблемы, что выбор "правильного" языка здесь мало поможет. Если критичный код не покрыт 100% тестами, то рано или поздно проблема выстрелит вне зависимости от языка.


Автор: Archi 14.12.2016, 15:28

Цитата(Lerm @ 14.12.2016, 13:16) *
Качество программного продукта определяется в первую очередь методологией, что включает корректным подходом к тестированию (во всех видах), review кода и использования правильных стандартов разработки (в частности тем, какие языковые конструкции можно использовать и какие нельзя).

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

По поводу покрытия тестами. Строго говоря даже 100% покрытие тестами не гарантирует отсутсвие багов, если ошибка в логике.

Автор: Lerm 14.12.2016, 15:43

Цитата(Archi @ 14.12.2016, 15:28) *
По поводу покрытия тестами. Строго говоря даже 100% покрытие тестами не гарантирует отсутсвие багов, если ошибка в логике.


Это разумеется – но это уже валидация требований и другие виды тестирования. Речь же изначально шла про "стрельбу в ногу" в "неправильных" языках. smile.gif

Автор: alex_bykov 14.12.2016, 15:59

QUOTE(Archi @ 14.12.2016, 15:28) *
По поводу покрытия тестами. Строго говоря даже 100% покрытие тестами не гарантирует отсутсвие багов, если ошибка в логике.

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

Автор: Татарин 15.12.2016, 0:09

Цитата(Lerm @ 14.12.2016, 15:43) *
Это разумеется – но это уже валидация требований и другие виды тестирования. Речь же изначально шла про "стрельбу в ногу" в "неправильных" языках. smile.gif

Выстрелить в ногу можно где угодно. Но одно дело - автоматом ступню отстрелить, и совсем другое - три литра нитроглицерина уронить на ту же ногу.
Бегать, конечно, после такого в любом случае не выйдет, да и выживаемость в первом случае тоже под вопросом.

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

Автор: Superwad 11.9.2017, 10:54

Вот тут опять выплыл С++
https://www.kv.by/post/1051918-pochemu-nikomu-ne-nravitsya-yazyk-programmirovaniya-c?utm_source=weekly_letter
Краткая выдержка:
1) Язык С имеет четкую постановку задачи и цель, для чего он заточен. У С++ вообще ничего нет. (Даже у Object Pascal который сейчас развивают и то есть конкретные цели - и его под это затачивают)
2) Очень сложный язык - высокий порог вхождения.
3) Неоднозначность кода и получения результата - эдакая обезьяна с гранатой.
4) Писать можно - но для получения нормального результата надо ввалить огромное количество ограничений
5) Долго не могли довести до ума компиляторы - слишком сложный язык и отлавливание всех ситуаций - крайне гемморойный и неблагодарный процесс (да еще и супер трудоемкий).
И все это для того, чтобы написать программы, которые пишутся на других языках с меньшими затратами???
И нафига, спрашивается???

Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)