тролль - это не только ценный жир, но и 3-4 легкоусвояемых коммента ежедневно
взято оттуда, весьма доставило ))
Все программы Curiosity написаны на Си: с одной стороны, этот язык достаточно ёмкий по сравнению с ассемблером, с другой — отсутствие объектно-ориентированных конструкций C++ страхует от лишних ошибок. Программистов Curiosity специально попросили воздерживаться от всех сложностей: запрещены, к примеру, рекурсивные вызовы функций. В остальном программирование марсохода ничем не отличается от любого другого программирования.
Все программы Curiosity написаны на Си: с одной стороны, этот язык достаточно ёмкий по сравнению с ассемблером, с другой — отсутствие объектно-ориентированных конструкций C++ страхует от лишних ошибок. Программистов Curiosity специально попросили воздерживаться от всех сложностей: запрещены, к примеру, рекурсивные вызовы функций. В остальном программирование марсохода ничем не отличается от любого другого программирования.
-
-
12.10.2013 в 20:04А рубе-хипстерам и ФП-теоретикам не доверяют
работусерьёзный embedded в принципе, что делать будем?-
-
12.10.2013 в 20:59embedded-руби и ФП просто не существуют (по вполне разумным причинам - экономия ресурсов системы здесь важнее скорости кодописания)
а вот рекурсивные вызовы в embedded-Си реализованы, но Сишникам их не доверяют (какбэ наезд на прогеров)
-
-
12.10.2013 в 22:16какбэ наезд на прогеров
Это не наезд на программистов, а не в курсе предметной области. У таких embedded-проектов есть определённые (вполне конкретные) требования по надёжности и идёт серьёзная аналитика по рискам.
Чем проще код, тем проще его статический анализ и формальная верификация. Если с этой точки зрения (эффективность в языке C/сложность формальной проверки корректности, вероятность возникновения ошибок и пр.) оценить использование рекурсии, то вряд ли найдётся что-то смешное
-
-
12.10.2013 в 22:28однако нет автоматического способа эту надёжность проверить
какие бы термины тут не писали (типа "статистический анализ", "аналитика по рискам") - это всё равно не более чем напускной важный вид в вопросах, где нет реального инструмента для контроля
всё равно остаётся надеяться на безошибочность работы программиста
смешным здесь является то, что Сишникам запрещена фича, которая сама по себе не является ошибкообразующей (наоборот, делает логику кода прозрачнее), и вот этот жест отчаяния "ну давайте им хоть рекурсию запретим" вызывает улыбку, т.к. бросает тень на программистов
-
-
12.10.2013 в 22:33да, это рассматривалось как ошибка(!), наверное, тоже из-за недоверия к способностям программистов ))))
нам на практических занятиях в вузе приходилось обманывать фортран, вызывая процедуры друг из друга поочерёдно (А - Б - А и т.д.), это делало код трудночитаемым, но позволяло использовать преимущества рекурсии как действенного метода программирования
-
-
12.10.2013 в 22:46какие бы термины тут не писали
Я просто оставлю это здесь: http://en.wikipedia.org/wiki/Static_program_analysis, http://en.wikipedia.org/wiki/Formal_verification, раз уж к "терминам" особого доверия нету. Там и аргументы есть, и пдф-очки разные, и источники авторитетные, и т.п.
А что по поводу остального - я уж самоустранюсь, иначе это холивар будет. Может кто другой скажет.
-
-
12.10.2013 в 23:31таки вы считаете, что по части проверки правильности исходного кода программ более не нужно полагаться на веру в безошибочность программиста, а вместо этого можно использовать автоматические средства проверки, которые (для программы любой сложности) обязательно просигналят вам, если в коде имеется логическая ошибка? (ДА/НЕТ)?
мне казалось, что все рассуждения и доказательства об алгоритмах сами неалгоритмизуемы, кроме самых простейших случаев.
-
-
14.10.2013 в 12:41«Rule 4 (recursion)
There shallbe no direct or indirect use of recursive function calls. [MISRAC:2004 Rule 16.2; Power of Ten Rule 1]
The presence of statically verifiable loop bounds and the absence of recursion prevent
runaway code, and help to secure predictable performance for all tasks. The absence of
recursion also simplifies the task of deriving reliable bounds on stack use. The two rules
combined secure a strictly acyclic function call graph and control-flow structure, which
in turn enhances the capabilities for static checking tools tocatch a broad range of coding
defects.
One way to enforce secure loopbounds is to add an explicitupper-bound to all loops that
can have a variable number of iterations (e.g., code that traverses a linked list). When the
upper-bound is exceeded an assertion failure and error exit can be triggered. For standard
for-loops, the loop bound requirement can be satisfied by making surethat the loop
variables are not referenced or modified inside the body of the loop. »
-
-
14.10.2013 в 20:30"У нас довольно тупая система поиска ошибок в коде, которая не умеет работать с пред- и пост-условиями цикла, чтобы доказать гарантированность свойств цикла таких как максимальное кол-во итераций и размер съедаемого стека.
К тому же мы очень не доверяем нашим программистам.
Поэтому в предстоящих соревнованиях по плаванию бассейн заполнять водой не будем - вдруг кто утонет?"
-
-
15.10.2013 в 10:10-
-
15.10.2013 в 21:07ну а чем ваше рассуждение отличается от объяснения отсутствия воды в бассейне? те же яйца, вид сбоку
если кто не понял, я просто прикалываюсь над чрезмерными ограничениями.
я понимаю, что кто-то очень сильно ссытся и старается никому не доверять, особенно программистам )))
и, кстати, программисты уже не раз давали повод себе не доверять
вспоминается переворот самолёта при снижении его ниже 0 м над уровнем моря )))
кстати, а будет ли отловлена какая-нибудь аналогичная хрень, которую нарочно не придумаешь?
ведь никто и не подозревал, что программу можно испортить в этом неожиданном направлении ))