i = 2;
i = i++ * --i;
Software Engineering
Сейчас в области Software Engineering все движеться в направлении развития надежных средств тестинга для исправления создавшихся ошибок по в процессе разработки. А нет ли каких то наработок в обратном направлении : создание надежных средств разработки с жесткими правилами не допускающих ошибок (предотвращение вместо исправления).
Ну, как обычно: синтаксис языка (например, С благоприятствует ошибкам, Ada - нет), строгая типизация, обязательная обработка исключений. Есть еще такой язык Smalltalk (один из не многих полнстью объектно-ориентированных языков), в нем программа разрабатывается путем модификации начальной заготовки так, что программист создает (модифицирует) работающую программу в ней же самой.
Может быть, будет интересна эта мощнейшая разработка А.А. Шалыто: Автоматное программирование.
Более подробно можете почитать тут: http://ict.edu.ru/ft/001843/aut_prog.html
Кстати, поверхностно, но знаком с ним лично. Некоторые мои деловые и по учебе друзья общались с ним более плотно. Это пример того, как можно автоматизировать и практически избавить от ошибок процесс программирования.
Более подробно можете почитать тут: http://ict.edu.ru/ft/001843/aut_prog.html
Кстати, поверхностно, но знаком с ним лично. Некоторые мои деловые и по учебе друзья общались с ним более плотно. Это пример того, как можно автоматизировать и практически избавить от ошибок процесс программирования.
Эммм... Не знаю, что нового и мощнейшего открыл господин Шалыто, но конечные автоматы уже давно используются при описаниии поведения объектов (например, в VHDL). Декомпозиция задачи на состояния и события переходов только усложняет работу программиста (т.к. даже для не очень сложной задачи таких состояний и событий будет очень много), тем не менее уже давно существуют генераторы КА (например, парсеры), которые, однако, нисколько не повышают надежность выходных программ.
Не могу согласиться с тем, что ничего нового в автоматном подходе Шалыто нет. Думаю, Вам стоит подробно ознакомиться с его трудами и обратить внимание на то, что работы эти начались в 1991 году, если я не ошибаюсь.
Цитата:
Сейчас в области Software Engineering все движеться в направлении развития надежных средств тестинга для исправления создавшихся ошибок по в процессе разработки. А нет ли каких то наработок в обратном направлении : создание надежных средств разработки с жесткими правилами не допускающих ошибок (предотвращение вместо исправления).
Наличие жестких правил в средстве разработки вовсе не означает того, что при разработке будет меньше логических ошибок, которые отловить труднее всего.
Конечно, скажем, наличие типизации в языке, облегчает поиск некоторых ошибок, но это мелочи!
Цитата: Dolonet
Не могу согласиться с тем, что ничего нового в автоматном подходе Шалыто нет. Думаю, Вам стоит подробно ознакомиться с его трудами и обратить внимание на то, что работы эти начались в 1991 году, если я не ошибаюсь.
По крайней мере в работе http://is.ifmo.ru/download/turing.pdf не содержится никаких новых материалов. Описание систем конечными автоматами было предложено еще за долго до работ г.Шалыто. Так, в спецификации языка VHDL (разработанного в 1983 году) предложено описание поведения объектов с помощью конечных автоматов (наряду с традиционным "поведенческим" программным описанием). А работы г.Шалыто являются лишь переосмыслением известных методик и имеют местное значение (ни в коем случае не хочу никого обитеть т.о.).
Ни в коем случае Вы меня не обижаете. Скорее наоборот, посвящаете в вопрос с другой стороны, за что большое спасибо :)
Возможно, это действительно так, раз VHDL старше. О степени локальности "открытий" Шалыто я могу только поддержать.
Но это не мешает идее оставаться хорошей. Вернемся к сабжу. Да, автоматизация увеличивает количество человекочасов, но целостность, инкапсулированность имхо увеличивается, что приводит к меньшим затратам на отладку. Все имхо. Я на такие объемные проекты никогда не работал. Максимум 2500 человекочасов, да и те размазаны были почти на полгода.
Возможно, это действительно так, раз VHDL старше. О степени локальности "открытий" Шалыто я могу только поддержать.
Но это не мешает идее оставаться хорошей. Вернемся к сабжу. Да, автоматизация увеличивает количество человекочасов, но целостность, инкапсулированность имхо увеличивается, что приводит к меньшим затратам на отладку. Все имхо. Я на такие объемные проекты никогда не работал. Максимум 2500 человекочасов, да и те размазаны были почти на полгода.
Во избежании синтаксических ошибок и уменьшении времени на набор кода в языках уменьшают лексическую избыточность в токенах (т.е. количество символов на резервированное слово), а так же семантическую избыточность (количество токенов для построения языковой конструкции). Такие средства явно видны в языке C (автор этого языка, видимо, просто обожал краткость). Ускорить набор кода помогают интерактивные средства типа IntelliSense. Ну а устранить логические ошибки поможет простое предварительное моделирование - хотя бы средствами UML. Сам синтаксис языка никак не может способствовать уменьшению логических ошибок, т.к. не имеет сведений о природе решаемой задаче. Так же как гаечный ключ не может препядствовать его применению для ковыряния в носу, хоть и предназначен для закручивания болтиков. Хотя есть языки, в которых природа решаемых задач (специфика) определена довольно явно - LISP и Prolog.
Ну, вот, возьмем к примеру С:
Что получится в результате? Способствует-ли синтаксис языка устранению подобных неоднозначностей или наоборот - благоприятствует их появлению?
Код:
Что получится в результате? Способствует-ли синтаксис языка устранению подобных неоднозначностей или наоборот - благоприятствует их появлению?
Ребята, скажу я так. Для увеличения производительности отдельно взятого программиста ему надо выполнять несколько условий и действий.
Перед тем, как приступить к программированию, задача должна быть раздроблена на подзадачи, структура продумана и испробавана в уме. Потом, когда все раздроблено, надо писать каркасы функций и объектов, но сами функции ничем, кроме подробнейших комментариев не наполнять(!).
Ну а потом заполнять функции постепенно. Умея программировать при этом. Если в одной функции получается больше 20 строк, то ее надо дробить.
У меня ошибки в коде уже пару лет как появляются крайне редко. Думаю, у многих, кто читает этот пост, примерно то же самое. Это приходит, наверное, с опытом, ведь большинство ошибок легко предсказуемы и легко отлаживаются.. :)
Перед тем, как приступить к программированию, задача должна быть раздроблена на подзадачи, структура продумана и испробавана в уме. Потом, когда все раздроблено, надо писать каркасы функций и объектов, но сами функции ничем, кроме подробнейших комментариев не наполнять(!).
Ну а потом заполнять функции постепенно. Умея программировать при этом. Если в одной функции получается больше 20 строк, то ее надо дробить.
У меня ошибки в коде уже пару лет как появляются крайне редко. Думаю, у многих, кто читает этот пост, примерно то же самое. Это приходит, наверное, с опытом, ведь большинство ошибок легко предсказуемы и легко отлаживаются.. :)
Цитата: sealmu
Сейчас в области Software Engineering все движеться в направлении развития надежных средств тестинга для исправления создавшихся ошибок по в процессе разработки. А нет ли каких то наработок в обратном направлении : создание надежных средств разработки с жесткими правилами не допускающих ошибок (предотвращение вместо исправления).
Жесткие правила и надежные средства разработки от ошибок не избавят, программы пишут люди. Уже были подобные попытки, и именно они привели к появлению Си++ и других языков программирования :)
Цитата:
Может быть, будет интересна эта мощнейшая разработка А.А. Шалыто: Автоматное программирование.
Более подробно можете почитать тут: http://ict.edu.ru/ft/001843/aut_prog.htm
Разработка мошнейшая. только причём тут автор этой статьи, не понятно. Что такое конечный автомат знали люди и до него, и он совсем не пионер. Многие программисты пишут такие программы(а многие пишут так интуитивно), потому что это очень удобный принцип формализации. (цитата: "используются не флаги , а состояния" - флаги это и есть состояния, наверно автор хочет сказать, что состояние инкапсулирует флаг).
2 all
Причём тут вообще синтаксические ошибки ? Это же тривиальные ошибки, их просто избежать. а код, который вы привели про i++ ++i - ни один нормальный(подчекиваю) прог в коммерческом проекте так писать не будет. Давайте поговорим об избежании алгоритмических ошибок. И так - есть такой человек Бертран Мейер. Является автором книги "объектно ориентированное проектирование программных систем" и создателям языка Eifell (слышали о таком ? читается Эйфель). Так вот, суть там в том, что в язык встроена так называемая система контрактов, которая строго декларирует что должно быть на входе, на выходе и во время работы. с помощью предусловия, инварианта и постусловия. В целом - опять же ничего нового, т.к. это ничто иное, как верификация программ методом Хоара, но это действительно первая реализация метода на практике. Расскажу суть - что такое инвариант, я думаю многие знают - так вот , там берётся кусок куда и к нему цепляется инвариант, если условие нарушается -прога вываливается. В с++ есть кое что подобное - называется assertion, но это менее мощная штука. Подробности в следующих постах, если появятся вопросы.
Я сильно ошибусь, если задача поиска алгоритмических ошибок и, соответственно, их избегания, сводится к решению поиска выхода в лабиринте? Конечно, в гораздо более усложненном варианте.
Кстати, интересная ссылка
Кстати, интересная ссылка
Цитата: Dolonet
Я сильно ошибусь, если задача поиска алгоритмических ошибок и, соответственно, их избегания, сводится к решению поиска выхода в лабиринте? Конечно, в гораздо более усложненном варианте.
Кстати, интересная ссылка
Кстати, интересная ссылка
Извините, коллега, но если вы думаете, что я говорил про алгоритм дейкстры или алгоритм Хоара Quicksort, то вы плохо прочитали и не поняли мой пост. Если же вы имели в виду что-то другое, пожалуйста поясните.
Поясните, в таком случае, пожалуйста, поподробнее по поводу метода Хоара. Тогда я смогу понять сам, в тот ли огород я плюнул, или моя логика пошла не только издалека, но и не туда.
Кстати сказать, подобный "assertion" присутствует во всех языках со строгой типизацией. Например, если в Аде я напишу:
то при всяких манипуляциях с переменной value, автоматически будет генериться код проверки попадания в диапазон.
Код:
SUBTYPE NonNegFloat IS Float RANGE 0.0 .. Float'Last;
value : NonNegFloat;
value : NonNegFloat;
то при всяких манипуляциях с переменной value, автоматически будет генериться код проверки попадания в диапазон.
Цитата: Darien
а код, который вы привели про i++ ++i - ни один нормальный(подчекиваю) прог в коммерческом проекте так писать не будет.
с++ таки развращает конструкциями типа ++.
недавно поймал себя на том, что интуитивно написал подобную конструкцию: f(a[i++], a[i++], a[i++])
:) догадываетесь что получилось?
В стандарте четко написано, что произойдет, просто запомнить это нелегко :)
Цитата: oco
В стандарте четко написано, что произойдет, просто запомнить это нелегко :)
На самом деле то что произойдет зависит от компилятора.
Цитата: Dolonet
Поясните, в таком случае, пожалуйста, поподробнее по поводу метода Хоара. Тогда я смогу понять сам, в тот ли огород я плюнул, или моя логика пошла не только издалека, но и не туда.
Увы, не туда. Имелось в виду исчисление Хоара, и соотвествующий ему метод верификации программ. Это из теоретического программирования (computer science , формально говоря). Суть, в том, что мы получаем инструмент доказательства программ, где мы имеем специальные конструкции - тройки Хоара, (тройка состоит из предусловия , постусловия и программы) , а так же имеем множество правил вывода, и применяя эти правила мы можем верифицировать ПО, посредством инвариантов, в частности. Именно это и реализовано фактически Б.Мейером в языке Эйфель. Если интересует литература - то могу посоветовать почитать самого Хоара, а так же книжку по названием "Математическое введение в информатику", тут её качать
http://window.edu.ru/window/library?p_rid=24022 , предупреждаю, нужно знать математику.
Проги не деалют ошибок. Их создают програмисты.
На всем протяжениии програмирования, главное уследить размерность множества над которым сейчас возишся. И ошибки стают орфографическими. Подробно мысленно трасировать алгоритм, блокируюя ветки не нужные к обработке.
А для простоты, в множествах вариантов, идентифицировать первый, т.е. нулевой приравненым ко все тем что использованы не будут, причем на протяжени всего алгоритма. (Вроде "Неивестный" вариант). И соответсвенно просто достаточно вставить фильтр "если индекс варианта больше зарервированых, утрировать до нулевого", что бы не допускать в тело ошибочные значения. Не труден тогда и обработчик исключений (значение по умолчанию, перезапросы, вывод места претензии и т.п.). Тогда легко уследить в дальнейших апгрейдах откуда берется "нечистый" в вашем окне.
Запрограмируйте ошибку приемлимой изначально. :) грубо говоря, объсните священику нормальным стиль умеренного грешения.
Это главное. А остальное дело выбора.
Смысл всего выше сказаного.
На всем протяжениии програмирования, главное уследить размерность множества над которым сейчас возишся. И ошибки стают орфографическими. Подробно мысленно трасировать алгоритм, блокируюя ветки не нужные к обработке.
А для простоты, в множествах вариантов, идентифицировать первый, т.е. нулевой приравненым ко все тем что использованы не будут, причем на протяжени всего алгоритма. (Вроде "Неивестный" вариант). И соответсвенно просто достаточно вставить фильтр "если индекс варианта больше зарервированых, утрировать до нулевого", что бы не допускать в тело ошибочные значения. Не труден тогда и обработчик исключений (значение по умолчанию, перезапросы, вывод места претензии и т.п.). Тогда легко уследить в дальнейших апгрейдах откуда берется "нечистый" в вашем окне.
Запрограмируйте ошибку приемлимой изначально. :) грубо говоря, объсните священику нормальным стиль умеренного грешения.
Это главное. А остальное дело выбора.
Смысл всего выше сказаного.