Языки, программы и так далее, Вынос из БН-800 |
Здравствуйте, гость ( Вход | Регистрация )
Языки, программы и так далее, Вынос из БН-800 |
10.12.2016, 7:08
Сообщение
#81
|
|
Частый гость Группа: Haunters Сообщений: 341 Регистрация: 18.3.2011 Из: Калифорния Пользователь №: 32 567 |
Обсуждая C++ и C.
Ну во первых, удивительно но языки эти переносимы неплохо. На том же C даже на БЭСМ-6 умудрились компилятор сделать. Во вторых, тут выше совершенно верно замечено, КАК надо писать сложные системы на C++ - небольшая команда ОЧЕНЬ квалифицированных специалистов должна создать фреймворк и внутренние стандарты. После чего уже даже и быдлокодеры смогут свои куски добавлять. Основной отличие жабы в том, что там быдлокодеры могут писать изначально, причем оно даже работать будет (но как крокодил, низенько - низенько). А если кто помнит, то Пентагон ведь озадачился как-то проблемой _сделать такой язык, чтобы был сам себе фреймворком - заставлял писать надежно_. И породил он язык Ада. И... не вышел каменный цветок, хотя как я понимаю, многие встроенные системы на нем пишутся или пытались писать. В общем, подход с _фреймворк делает небольшая команда, все пользуются_ и _язык С++_ крайне правильный. Потому что - ну например, на JAVA написать надежный код - к сожалению, почти невозможно. То есть все абсолютно коды на JAVA которые я например когда то видел - имеют кучу ошибок, но самое главное - они крайне зависят от интерпретатора, и никто не гарантирует того, что через год программа не сломается. У нас (системщиков) есть правило - _все что написанно на JAVA - рано или поздно слопает память или зависнет, а потому его надо перевызывать регулярно_ (последняя история - у нас зависла карточка управления сервером, которая имела интерфейс на JAVA внутри себя - ну и как легко догадаться, через 2 года работы там что-то кончилось и она стала говорить что мол ошибка... А новые карточки идут со встроенным регулярным перевызовом, потому что авторы уже поняли, что невозможно обеспечить надежную многолетнюю работу, а эта штука работает всегда когда включен шнур питания. И поэтому встроенные системы писать на ней - очень сильно рисковать. На C++ - высокий порог вхождения, легко наляпать такое, что и бригада гуру не разберется, но зато при правильном фреймворке и внутренних стандартах - код будет крайне надежен, куда надежнее чем на JAVA или C#, потому что все ошибки вылезут сразу, а не как JAVA через полгода работы... Хотя кстати с Ada идея была неплоха. Сделать строгий язык для отвественного программирования. (Да, спасибо что лесник пришел. ) |
|
|
10.12.2016, 13:42
Сообщение
#82
|
|
Новичок Группа: Haunters Сообщений: 93 Регистрация: 16.3.2011 Из: Санкт-Петербург Пользователь №: 32 410 |
1) Претензии к утверждению, что с и с++ являются языками высокого уровня, коими они не являются Это вопрос религиозный, так что без меня. 2) Стандарт на С еще может и быть, а вот на С++ - какой это стандарт, если на выходе код работает как карта ляжет? Я это не теоретически говорю, а с практической точки зрения, ибо сам столкнулся. Ну а в чём проблема-то? Будет ли работать амперметр, если воткнуть его в 220? Ну, как карта ляжет. Да, некоторые конструкции C++ в некоторых случаях приводят к неопределённому поведению (undefined behavior). Например, выход за границы массива или двойное освобождение памяти. И что? Обычно неопределённое поведение возникает в ситуациях, когда на вход какой-то функции поданы некорректные данные, т.е. программа _уже_ работает неправильно. И в этой ситуации уже не важно, что будет дальше: ошибка уже случилась, правильного результата уже не будет, на каком бы языке мы ни писали. 3) Для программирования критического кода инструмент должен быть прямой как железная дорога, а не плутать по лесным тропинкам по лесу. Т.е. логика должна просматриваться в одном файле, а не размазана по разным. Вы про .h/.cpp? Как правило, интерфейс компонента описан в h-файле, а реализация - в cpp. Исключение - шаблонные (template) классы и методы, которые всегда лежат в h-файле. Но если в проекте появился код с шаблонами, значит, Вы уже залезли на территорию, на которой конкурентов C++ можно пересчитать по пальцам. Претензия к С/С++ в том, что при компиляции получается неоднозначный код и результат (опять же в зависимости от настроек директив компилятора). Этого что мало? Этого уже достаточно, чтобы поставить крест на С++ как инструмента для написания критического программного обеспечения. Если Вам нужен однозначный результат, то зачем Вам вообще программа? Напишите константу. Про Паскаль, тот который FPC. Он развивается, выходят новые релизы. Мне он очень нравится. Я сейчас на нем пишу. Так как он делается на базе С , то в коде можно переключаться и делать вставки как на Асме, так и на чистом С. Но это, обратите внимание, нестандарт, и привязывает Вас к определённому компилятору. Это, конечно, снимает множество проблем, но в дискуссии о языках не спортивно. C++ использует несколько другой подход: 1. Из кода на C++ можно вызвать любую функцию, имеющую интерфейс, описанный на языке C. Независимо от того, на каком языке эта функция реализована: на C, на C++, на ассемблере или на фортране. 2. Функцию, описанную (declared) на языке C, можно без проблем реализовать на C++. 3. Функции с интерфейсом на C++, реализованные в разных компонентах, совместимы, если они скомпилированы одним и тем же компилятором с одними и теми же настройками. Почему пересел с Delphi на Lazarus? Переносимость кода на Линукс. Если пишешь на Паскале получаешь логически чистый код, ибо код читается и компилируется однозначно. Про эту однозначность уже анекдоты сложены. :-) Анекдот такой: Цитата Винни Пух говорит Пятачку: - Кристофер Робин прислал нам $10: тебе $8 и мне $8. - Но Винни... По-моему, если сложить $8 и $8, $10 не получится... - Ну как же... Я и программу написал, чтобы проверить. На паскале: Цитата program HelloWorld; begin if($8+$8=$10) then writeln('$8+$8=$10'); end. В общем, ты как хочешь, а я свои $8 уже потратил. ДА, может нет того богатого инструментария - а он нужен для прикладников? Нужен. Вот на соседнем форуме ещё один любитель паскаля жалуется: в России сейчас внедряется ГИС ЖКЖ, данные в неё надо передавать по протоколу SOAP (т.е. подписать XML по ГОСТ и отправить по протоколу HTTP). И выясняется, что подходящих инструментов для этого на паскале нет (хотя и HTTP, и XML, и ГОСТ существуют давным-давно), а подтянуть существующие из других мест он не может. А то, что вместо С++, начинают использовать Java и С# - это признак того, что не всё так сладко с С++. Просто те преимущества, которые этот язык предоставляет, нужны не всем и не всегда. |
|
|
14.12.2016, 10:31
Сообщение
#83
|
|
Ветеран форума Группа: Patrons Сообщений: 1 211 Регистрация: 24.8.2016 Пользователь №: 34 367 |
Не готов обсуждать достоинства и недостатки именно языков. Однако вчера расчётное ядро нашей СВРК получило паспорт Ростехнадзора... Ну и референтный опыт на 20+ блоках чего-то стоит, наверное. Поздравляю. Честно. То что люди делают - это хорошо, и результат впечатляет. Что могу сказать - ни ошибки ни бага! |
|
|
14.12.2016, 10:45
Сообщение
#84
|
|
Ветеран форума Группа: Patrons Сообщений: 1 211 Регистрация: 24.8.2016 Пользователь №: 34 367 |
Леснику - большое спасибо за отдельную поляну
|
|
|
14.12.2016, 11:24
Сообщение
#85
|
|
Ветеран форума Группа: Patrons Сообщений: 1 211 Регистрация: 24.8.2016 Пользователь №: 34 367 |
А теперь по существу.
Анекдот про дятла - увы это уже не шутка, а суровая реальность, констатация факта. Качество программного кода сейчас - ниже плинтуса в основной своей массе. Использование С++ - это поездка на авто без тормозов и систем безопасности (защиты). Вы когда нибудь ездили по общественным дорогам без тормозов? А мне приходилось, и не одну тысячу км отмахал с одним ручником (машина такая - образец гиганта французской мысли, потому ручник у неё на передние колеса и является стояночно-аварийным тормозом), что уже на уровне рефлексов иногда рука тянется к ручнику затормозить вместо ножного тормоза, особенно на светофорах. И если уж коснулись автомобильной тематики, то для написания исполнительного кода для критически важных систем управления реального времени используют специально заточенный С, в котором нет освобождения памяти под переменными и прочие ограничения. Но даже применяя специализированный софт, умудряются допускать ошибки. Так и тут - а есть ли нормальный специализированный софт, который позволяет на корню пресечь многие ошибки, какие можно опустить на ровном месте на С++. И не надо про правильно приготовленные программы и высокую квалификацию программистов - залететь можно на элементарном. ( Правило Мэрфи еще никто не опроверг - "Если деталь может быть вставлена неправильно - то неправильно она будет и вставлена". Если может быть допущена глупая случайная ошибка на ровном месте - то она обязательно будет. Пример - да есть тут один, прочитал на одном форуме -авиадвигатель для пассажирского боинга, прошел капремонт на сертифицированном предприятии, прошел обкатку (причем люди то опытные были, профи) - заметили на складе лишние трубочки - резко тормознули отгрузку - забыли установить после разборки, а если бы поставили на самолет ). Сообщение отредактировал Superwad - 14.12.2016, 11:25 |
|
|
14.12.2016, 13:16
Сообщение
#86
|
|
Новичок Группа: Novices Сообщений: 96 Регистрация: 26.12.2014 Из: Москва, Россия Пользователь №: 34 077 |
Не удержался. Качество программного продукта определяется в первую очередь методологией, что включает корректным подходом к тестированию (во всех видах), review кода и использования правильных стандартов разработки (в частности тем, какие языковые конструкции можно использовать и какие нельзя). При правильном применении этого подхода – язык разработки глубоко вторичен. При нарушениях в этом процессе (проблемы с тестированием, отсутствие review кода и так далее) – у проекта уже такие проблемы, что выбор "правильного" языка здесь мало поможет. Если критичный код не покрыт 100% тестами, то рано или поздно проблема выстрелит вне зависимости от языка.
|
|
|
14.12.2016, 15:28
Сообщение
#87
|
|
Опытный Группа: Haunters Сообщений: 143 Регистрация: 30.12.2014 Из: Беларусь Пользователь №: 34 079 |
Качество программного продукта определяется в первую очередь методологией, что включает корректным подходом к тестированию (во всех видах), review кода и использования правильных стандартов разработки (в частности тем, какие языковые конструкции можно использовать и какие нельзя). На самом деле это касается не только программных продуктов, но и практически любой деятельности. Если сразу правильно "огородить" участок и потом не выходить за пределы, как бы ни хотелось, то вероятность наткнуться на грабли уменьшается на порядки. По поводу покрытия тестами. Строго говоря даже 100% покрытие тестами не гарантирует отсутсвие багов, если ошибка в логике. |
|
|
14.12.2016, 15:43
Сообщение
#88
|
|
Новичок Группа: Novices Сообщений: 96 Регистрация: 26.12.2014 Из: Москва, Россия Пользователь №: 34 077 |
По поводу покрытия тестами. Строго говоря даже 100% покрытие тестами не гарантирует отсутсвие багов, если ошибка в логике. Это разумеется – но это уже валидация требований и другие виды тестирования. Речь же изначально шла про "стрельбу в ногу" в "неправильных" языках. |
|
|
14.12.2016, 15:59
Сообщение
#89
|
|
Эксперт Группа: Уровень доступа - 2 Сообщений: 3 885 Регистрация: 9.6.2007 Из: Обнинск-Москва Пользователь №: 89 |
По поводу покрытия тестами. Строго говоря даже 100% покрытие тестами не гарантирует отсутсвие багов, если ошибка в логике. Именно. По факту имеем, например, редкие переходные процессы, сочетание параметров и сигналов для которых заранее предусмотреть не удаётся. В этих экзотических ситуациях система не падает, но вот отдельные параметры расчёта могут быть неадекватными. На этот случай спасает запись всех входящих сигналов в автоматическом режиме и возможность проигрывания ситуации на архиве таких сигналов - есть на чём тестировать откорректированные алгоритмы/логику. -------------------- С уважением
Александр Быков |
|
|
15.12.2016, 0:09
Сообщение
#90
|
|
Постоянный участник Группа: Patrons Сообщений: 2 427 Регистрация: 16.3.2011 Пользователь №: 32 318 |
Это разумеется – но это уже валидация требований и другие виды тестирования. Речь же изначально шла про "стрельбу в ногу" в "неправильных" языках. Выстрелить в ногу можно где угодно. Но одно дело - автоматом ступню отстрелить, и совсем другое - три литра нитроглицерина уронить на ту же ногу. Бегать, конечно, после такого в любом случае не выйдет, да и выживаемость в первом случае тоже под вопросом. Но... короче, есть таки разница, бежать под дождём с автоматом на ремне или стеклянной трёхлитровой банкой того же нитроглицерина. |
|
|
11.9.2017, 10:54
Сообщение
#91
|
|
Ветеран форума Группа: Patrons Сообщений: 1 211 Регистрация: 24.8.2016 Пользователь №: 34 367 |
Вот тут опять выплыл С++
Почему никому не нравится язык программирования C++ ? Краткая выдержка: 1) Язык С имеет четкую постановку задачи и цель, для чего он заточен. У С++ вообще ничего нет. (Даже у Object Pascal который сейчас развивают и то есть конкретные цели - и его под это затачивают) 2) Очень сложный язык - высокий порог вхождения. 3) Неоднозначность кода и получения результата - эдакая обезьяна с гранатой. 4) Писать можно - но для получения нормального результата надо ввалить огромное количество ограничений 5) Долго не могли довести до ума компиляторы - слишком сложный язык и отлавливание всех ситуаций - крайне гемморойный и неблагодарный процесс (да еще и супер трудоемкий). И все это для того, чтобы написать программы, которые пишутся на других языках с меньшими затратами??? И нафига, спрашивается??? |
|
|
Текстовая версия | Сейчас: 26.4.2024, 17:09 |