Комментарии участников:
хакеры успешно атаковали сайты GNU 24 ноября при помощи SQL-инъекции в отношении приложения Savane, используемого для отслеживания уязвимостей в разрабатываемых программах.программа для отслеживания уязвимостей оказалась уязвима ))
На практике отличие математической функции от понятия «функции» в императивном программировании заключается в том, что императивные функции могут опираться не только на аргументы, но и на состояние внешних по отношению к функции переменных, а также иметь побочные эффекты и менять состояние внешних переменных. Таким образом, в императивном программировании при вызове одной и той же функции с одинаковыми параметрами, но на разных этапах выполнения алгоритма, можно получить разные данные на выходе из-за влияния на функцию состояния переменных.
А в функциональном языке при вызове функции с одними и теми же аргументами мы всегда получим одинаковый результат: выходные данные зависят только от входных. Это позволяет средам выполнения программ на функциональных языках кешировать результаты функций и вызывать их в порядке, не определяемом алгоритмом.
http://ru.wikipedia.org/wiki/Функциональное_программирование
в функциональном языке можно исключить одну из причин глюков, свойственных императивным языкам — изменение результата функции.
конечно, и на императивном языке можно писать в духе функционального, и тогда тоже можно избежать ошибок.
вы хоть раз пробовали писать реальный коммерческий проект на ФЯ?
и кто вас заставляет пользоваться в императивных языках глобальными переменными? (за такое руки отрубать надо)
и кто вас заставляет пользоваться в императивных языках глобальными переменными? (за такое руки отрубать надо)
я это к тому, что утверждение
неверно, и привел пример.
а тут все заминусовали.
ессно, офисный редактор ненадо писать на ФЯ, а вот прошивку для лунохода — вполне можно, ибо там стоимость ошибки невероятно велика, а кол-во вариантов работы программы хоть и большое, но проверяемое.
программ без уязвимостей не бывает.
неверно, и привел пример.
а тут все заминусовали.
ессно, офисный редактор ненадо писать на ФЯ, а вот прошивку для лунохода — вполне можно, ибо там стоимость ошибки невероятно велика, а кол-во вариантов работы программы хоть и большое, но проверяемое.
И даже более впечатляющий пример удаленной отладки произошел в миссии NASA "Deep Space 1" в 1998 году. Через полгода после запуска космического корабля, небольшой код на Lisp должен был управлять космическим кораблем в течении двух дней для проведения серии экспериментов. Однако, неуловимое состояние гонки (race condition) в коде не было выявлено при тестировании на земле и было обнаружено уже в космосе. Когда ошибка была выявлена в космосе (100 миллионов миль от Земли) команда смогла произвести диагностику и исправление работающего кода, что позволило завершить эксперимент15). Один из программистов сказал об этом следующее:
Отладка программы, работающей на оборудовании стоимостью 100 миллионов долларов, которая находится в 100 миллионах миль от вас, является интересным опытом. REPL, работающий на космическом корабле, предоставляет бесценные возможности в нахождении и устранении проблем.
это как пример про ошибки в ФЯ
пример интересный, спасибо, но он не доказывает, что программ без ошибок не бывает.
есть масса примеров из жизни, где используются программы без ошибок, потому что стиль написания их кода позволяет многие потенциальные ошибки избежать на этапе проектирования, а сам готовый код тщательно проверяется и отлаживается.
другое дело — это подходит для узкого класса программ, и не подходит для широкого.
имхо мы спорим об одном и томже говоря разными словами одно.
за пример по лисп — еще раз спасибо!
есть масса примеров из жизни, где используются программы без ошибок, потому что стиль написания их кода позволяет многие потенциальные ошибки избежать на этапе проектирования, а сам готовый код тщательно проверяется и отлаживается.
другое дело — это подходит для узкого класса программ, и не подходит для широкого.
имхо мы спорим об одном и томже говоря разными словами одно.
за пример по лисп — еще раз спасибо!
да я не против ФЯ (в частности lisp, язык всем языкам)
просто люди зачастую начитавшись в инете всякие вики и подобные агитационные материалы думают что ФЯ это решение всех проблем
сейчас программирование на таких языках как C/C++ дошло до такого уровня, что прежде чем писать какой либо проект нужно составить Code Style и прочие документы чего делать категорически нельзя в рамках проекта(использование библиотек, исключений, менеджеры памяти, уровень ошибок при компиляции), что избавляет от потенциальных ошибок в будущем
ну и набор библиотек существенно улучшил качество программ (boost, stlport, poco, qt)
как пример open source — chrome, linux-kernel, firefox(наверно не совсем удачный пример)), postgresql, etc
просто люди зачастую начитавшись в инете всякие вики и подобные агитационные материалы думают что ФЯ это решение всех проблем
сейчас программирование на таких языках как C/C++ дошло до такого уровня, что прежде чем писать какой либо проект нужно составить Code Style и прочие документы чего делать категорически нельзя в рамках проекта(использование библиотек, исключений, менеджеры памяти, уровень ошибок при компиляции), что избавляет от потенциальных ошибок в будущем
ну и набор библиотек существенно улучшил качество программ (boost, stlport, poco, qt)
как пример open source — chrome, linux-kernel, firefox(наверно не совсем удачный пример)), postgresql, etc
если мой коммент был воспринят как "все фуфло, ФЯ рулит" — приношу извинения, этого как раз не хотел.
именно про "правильный стиль" программирования я и хотел сказать, а не про "правильные языки".
именно про "правильный стиль" программирования я и хотел сказать, а не про "правильные языки".
если в программе нет ошибок — значит она никому не нужна (с)
со временем смысл этой фразы доходит ;)
со временем смысл этой фразы доходит ;)
есть программы для машин Тьюринга
в них нет ошибок
кому нужны такие машины — вопрос практики, а не теории.
в робототехнике, наверное, очень могут пригодится.
на десктопе — врядли.
в них нет ошибок
кому нужны такие машины — вопрос практики, а не теории.
в робототехнике, наверное, очень могут пригодится.
на десктопе — врядли.
не вижу противоречия.
программы для машины тьюринга это скорее автомат
для него действительно можно писать безглючные реализацию исключительно в силу того что можно охватить одним мозгом все в нем происходящее. на практике таких программ не существует — стабильность достигается многоразовыми итерациями багфиксинга-релиза. что не гарантирует
программы для машины тьюринга это скорее автомат
для него действительно можно писать безглючные реализацию исключительно в силу того что можно охватить одним мозгом все в нем происходящее. на практике таких программ не существует — стабильность достигается многоразовыми итерациями багфиксинга-релиза. что не гарантирует