Большой Воронежский Форум Mobile

Вы ребяты редкосные мозгоебы (без обид, сам почти такой же), из-за частностей готовы друг другу глотку рвать. Ну что ну asm ну ц ну вижуал ц ну как там этот ваш как его... блин... ".нет". Ессно при усложнении задач приходится постоянно переходить на новые уровни абсракции (пардон...абасракции) при сохранении среднего уровня затрат человеко-часов на задачу. И это ни как не говорит о улучшеении отказоустойчивости нового программного комплекса - это вроде даже практически не связанные друг с другом вопросы. И что опять получается банальность типа "нет предела совершенству - и не надо". [Ответ]

Абыр

Сообщение от :
Вы ребяты редкосные мозгоебы (без обид, сам почти такой же)

Ну, какие тут обиды. При случае оторвем голову, и всех делов

Сообщение от :
Ессно при усложнении задач приходится постоянно переходить

А задачи-то не всегда усложняются сами по себе. Я думаю, усложняется непонимание между заказчиком и исполнителем. То есть все чаще приходится начинать работу без ясного представления того, что должно получиться в конце. ИМХО, разумеется, но не только на личном опыте основываюсь.

Сообщение от :
при сохранении среднего уровня затрат человеко-часов на задачу.

Ну, брат, это как считать. Мне кажется, трудоемкость растет.

Сообщение от :
И это ни как не говорит о улучшеении отказоустойчивости нового программного комплекса

Как это не сказывается? Чем сложнее система, тем больше вероятность отказа. [Ответ]

А задачи-то не всегда усложняются сами по себе. Я думаю, усложняется непонимание между заказчиком и исполнителем. То есть все чаще приходится начинать работу без ясного представления того, что должно получиться в конце. ИМХО, разумеется, но не только на личном опыте основываюсь.
Ну дык это всегда так , не может разработчик знать что нужно заказчику сразу , ведь сам заказчик это понимает в общих чертах (в лучшем случае)
ДЛя этого и используют итерационный метод разработки .

Как это не сказывается? Чем сложнее система, тем больше вероятность отказа
НЕ все так просто .
Очевидно что значительная программа на асме будет гораздо менее надежна чем аналогичная на С . [Ответ]

Абыр
Улучшение отказоустойчивости происходит за счет использования кода стандартных библиотек, которые используются миллионами программеров и соответсвенно ошибки в них находят очень быстро и оперативно исправляют. [Ответ]

zic

Сообщение от :
Ну дык это всегда так , не может разработчик знать что нужно заказчику сразу

Конечно, это так и есть, и всегда было, но сейчас ситуация ухудшается. ИМХО, разумеется.zic

Сообщение от :
Очевидно что значительная программа на асме будет гораздо менее надежна чем аналогичная на С .

Да, но ведь программа на асме будет СЛОЖНЕЕ, именно потому и менее надежна

Alex__G
Я бы сказал - "в том числе".
Еще и квалификация программистов, правильно построенный процесс разработки и тестирования, сложность самой задачи... То есть факторов-то много. Разумеется, использование стандартных библиотек и подходов улучшает качество. [Ответ]

Абыр
бред... [Ответ]

zss_vrn

Сообщение от :
Да, но ведь программа на асме будет СЛОЖНЕЕ, именно потому и менее надежна

Программа остаётся той же самой вне зависимости от того на каком языке программирования её писать. Те же алгоритмы, те же структуры данных и т. п.
Программа на асме менее надёжна вовсе не из-за своей "сложности". [Ответ]

информативная тема [Ответ]

Rabbit

Сообщение от :
Программа остаётся той же самой вне зависимости от того на каком языке программирования её писать.

Не согласен. На асме программа будет содержать БОЛЬШЕЕ количество строк текста, значит, будет сложнее и менее надежна. [Ответ]

Rabbit
Может быть она такой и остается, но попробуй вернуться к этому коду месяцев через 9 чтобы внести исправления. А если придется разбирать чужой код?

Кроме того есть такая очень важная характеристика maintainability. Ее значение у большой программы на ассемблере ниже плинтуса.

zss_vrn
Согласен. Причем синтаксис у ассемблера хорошо "закрывает" собой алгоритм. [Ответ]

zss_vrn
Alex__G

А почему вы считаете, что это сложность именно ПРОГРАММЫ? Может для вас "исходный код"="программа? А я тогда возьму и напишу три проги на си, ассемблере и дельфи, так чтобы внешний вид был одинаков и функции выполняли одни и те же. Исходники разные, и для асма даже размером будут больше, но любой пользователь скажет, что это одна и та же программа - они же не отличаются...
В общем, прежде чем начинать спор, надо определиться с терминами, а там может и спорить не о чем будет. [Ответ]

Rabbit

Сообщение от :
надо определиться с терминами

Согласен

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

При прочих равных условиях программа на асме будет СЛОЖНЕЕ программы на С++. Хотя бы потому, что ООП на асме - дело довольно экзотическое

Кстати, программа для меня - все же исходный текст, а не исполняемый модуль. [Ответ]

Rabbit
А что еще можно вложить в понятие программа? (другое дело программный продукт)
Давай будем рассматривать понятие сложность с позиции программистов. Потому что сколько пользователей - столько и мнений. С программистами все более менее одинаково.

В понятие сложность предлагаю включить:
-функциональность
-maitainability. [Ответ]

Alex__G

Сообщение от :
А что еще можно вложить в понятие программа?

Например: "программа - последовательность действий конечного автомата"; "программа - это набор определенных действий, приводящий к определенному необходимому результату".
Исходный код - это не набор(последовательность) действий, это их(действий) описание. Уже компилятор или интерпретатор эти описания переводят собственно в действия.
Хотя, можно привести такое определение программы, что она окажется исходным кодом. Но я с этим категорически не согласен.

Да, кстати, нашёл вот на www.glossary.ru:

Сообщение от :

Программа - согласно ГОСТ 19781-90 - данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.

Сообщение от :

Программа для ЭВМ - по законодательству РФ - объективная форма представления совокупности данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств с целью получения определенного результата, включая подготовительные материалы, полученные в ходе разработки программы для ЭВМ, и порождаемые ею аудиовизуальные отображения

Сообщение от :
В понятие сложность предлагаю включить:
-функциональность

Ну и какая у исходников функциональность? Какие функции выполняют исходники? А вот если под программой понимать, "последовательность машинных команд"...

zss_vrn

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

Допустим у нас есть два байта в памяти. Необходимо их обменять.
Что делает программист на асме?
Пишет комманду xchg и в качестве операндов указывает два адреса. Размер такой программы одна строка(один оператор). Связей 0(два байта между собой никак не связаны).

Что делает программист на с++? Резервирует память под временное хранилище, копирует туда первый байт, на место первого пишет второй и, наконец, на место второго копирует байт из временного хранилища. Размер программы - три строки(три оператора). Связей по прежнему 0.

Вывод: программа обмена двух байт на с++ сложнее.
А на самом деле?
Я считаю, что сложность одинакова, ибо обе программы выполняют одинаковые функции. То есть по поводу определения сложности мне легче согласиться с Alex__G.
Сложность определяется функциональностью, стоимостью поддержки/развития. Можно ещё добавить сложность распростронения(раскрутки)...

Сообщение от :
При прочих равных условиях программа на асме будет СЛОЖНЕЕ программы на С++. Хотя бы потому, что ООП на асме - дело довольно экзотическое

Говоря про ООП ты искусственно ограничиваешь класс программ. Не все программы состоят из объектов.

Сообщение от :
Кстати, программа для меня - все же исходный текст, а не исполняемый модуль.

А почему? [Ответ]

Rabbit

Сообщение от :
"программа - последовательность действий конечного автомата"; "программа - это набор определенных действий, приводящий к определенному необходимому результату".

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

В конечном счете программа это набор инструкций, просто инструкии могут быть низкоуровневые (ассемблер), а могут быть высокоуровневые (си, паскаль, ява).

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

Alex__G

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

Инжинер такого слова, как "определение" вообще знать не должен. Его задача делать а не думать.. думают пусть учёные

В конечном счете программа это набор инструкций, просто инструкии могут быть низкоуровневые (ассемблер), а могут быть высокоуровневые (си, паскаль, ява).

А перфорации - это инструкции ? Высокоуровневые или низкоуровневые ? [Ответ]

Rabbit

Сообщение от :
Я считаю, что сложность одинакова, ибо обе программы выполняют одинаковые функции

Это понятно, почему такая неразбериха с понятиями. У кого что болит, тот о том и говорит. Конечно, любое определение имеет право на жизнь. Все теории стоят одна другой

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

Сообщение от :
Резервирует память под временное хранилище, копирует туда первый байт, на место первого пишет второй и, наконец, на место второго копирует байт из временного хранилища.

x = ((x & 0x00FF)<<8) + ((x & 0xFF00)>>8);

Че там резервировать... Не проверал, но, скорее всего, будет работать. Если X - 16 битный int. Сколько здесь операторов? Я 7 насчитал. Но есть еще библиотечные функции, которые это одним оператором делают - не стал искать.

Асм - язык операторный, С - структурный, С++ - ОО. Для разных целей они.

Сообщение от :
А вот если под программой понимать, "последовательность машинных команд"

Тогда лучше писать на асме.

Сообщение от :
Говоря про ООП ты искусственно ограничиваешь класс программ. Не все программы состоят из объектов.

Разумеется, не все. Поэтому и существует куча языков программирования разных классов. И говоря о пригодности языка, можно говорить только о его пригодности к решению задач определенного класса. И сложности это тоже касается. Стоимость сопровождения - правильный критерий. Если мы договоримся, что такое сопровождение Поддержка системы, которая эксплуатируется у 10 пользователей и у 10 000 пользователей - это совсем разные вещи.

Кстати, программа в сопровождении не нуждается вообще - в сопровождении нуждается программный продукт.

Сообщение от :
А почему?

Потому что мне так проще понимать этот мир и управлять его частью. Во сказал, сам не до конца понял То есть, я еще как то могу повлиять на поведение программы, если у меня есть исходный текст. И мои возможности равны почти 0, если есть только исполняемые модули. Зачем же я буду иметь дело с тем, чем не смогу управлять? Мне проще думать, что программа - это набор исходников. И сопровождать -то приходится именно исходники. И тратим мы 99% времени на возню с исходниками и другой документацией - схемами, графиками и т.д. А приложение - ну, закатали на болванку, в коробку упаковали - и привет. С глаз долой - из сердца вон
LSL

Сообщение от :
Его задача делать а не думать..

Не согласен. Инженер - это ОЧЕНЬ много. Главная его задача - как раз думать. Конечно, я говорю о хорошем инженере.

Сообщение от :
А перфорации - это инструкции

Это код. Исполняемый код, самый обычный. Одна строка перфоленты - один байт. В начале перфоленты идет программа-загрузчик, которая весь остальной код размещает в памяти определенным образом.
Alex__G

Сообщение от :
низкоуровневые (ассемблер), а могут быть высокоуровневые (си, паскаль, ява).

оператор - для асм
процедура - для паскаля
сообщение объекту - для явы. [Ответ]

сообщение объекту - для явы
А в смалталке это уже как то по другому называется ?

А например что такое + ,=+ ? это операторы даже в спер обьекториентированных языках [Ответ]

zss_vrn

Это код.

А инструкции это не код ? [Ответ]

zic

Сообщение от :
А в смалталке это уже как то по другому называется

Почему? Так же.

Я имел в вииду то, что асм, бейсик, фортран - языки операторные, С, паскаль, алгол - процедурные, С++, ява, C# - объектные. Но это - НАПРИМЕР, я не перечислял все языки, я их просто не знаю.

В объектных языках есть оператроы и процедуры, но сама парадигма ООП - "обмен сообщениями между объектами". Парадигма процедурных языков - "выполнение процедур", операторных - "выполнение операторов". Чего не так? [Ответ]

Alex__G

Сообщение от :
В конечном счете программа это набор инструкций, просто инструкии могут быть низкоуровневые (ассемблер), а могут быть высокоуровневые (си, паскаль, ява).

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

Сообщение от :
Что касается распростронения(раскрутки), то это относится скорее к программному продукту, чем просто к программе.

Пожалуй да. Я был не прав.

LSL

Сообщение от :
Инжинер такого слова, как "определение" вообще знать не должен. Его задача делать а не думать.. думают пусть учёные

Теперь мы знаем как ты пишешь программы...

zss_vrn

Сообщение от :
Обмен двух байтов в памяти - ну, я всеж не назвал бы это программой. Конечно, на асме это сделать проще

=:E Ты недавно говорил, цитирую, "программа для меня - все же исходный текст". Конец цитаты. Я щаз напишу два исходника для обмена двух байт и по-твоему это будет программой... Вернее было бы... Сейчас, вероятно, твоё мнение изменилось.

Сообщение от :
x = ((x & 0x00FF)<<8) + ((x & 0xFF00)>>8);

Че там резервировать... Не проверал, но, скорее всего, будет работать

Во-первых работать не будет(во втором слагаемом сдвиг лишний), а во-вторых это программа для обмена двух СОСЕДНИХ байт.

Сообщение от :
quote:
--------------------------------------------------------------------------------
А вот если под программой понимать, "последовательность машинных команд"
--------------------------------------------------------------------------------
Тогда лучше писать на асме

А вот и нет. Можно писать на чем угодно, а потом с помощью компилятора получить машинные команды. Сейчас так и делают.

Сообщение от :
То есть, я еще как то могу повлиять на поведение программы, если у меня есть исходный текст.

Сообщение от :
Мне проще думать, что программа - это набор исходников.

Мне кажется, что эти два утверждения противоречат друг другу. Надо либо "исходники"="программа", либо "исходники" отдельно, "программа" отдельно. [Ответ]

Rabbit

Теперь мы знаем как ты пишешь программы...

Я думаю ты понял что это был сарказм

Хотя бывает и такое. Напишешь бред, а он работает ! И работает правильно ! И не поймёшь, как он может так работать ! Но такое бывает редко, потому-что пишу для себя а не для других [Ответ]

Rabbit

Сообщение от :
=:E Ты недавно говорил, цитирую, "программа для меня - все же исходный текст". Конец цитаты. Я щаз напишу два исходника для обмена двух байт и по-твоему это будет программой...

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

А если в общем брать - без всякого практического смысла - то исполняемый модль и исходный текст - два представления одной сути.

Вот, гусеница и бабочка - это одно и то же? ))

Сообщение от :
Во-первых работать не будет(во втором слагаемом сдвиг лишний), а во-вторых это программа для обмена двух СОСЕДНИХ байт.

Блин, всеж пришлось проверить - работает и сдвиг не лишний, без него не работает.

x = ((x & 0x00FF)<<8) + ((x & 0xFF00)>>8);

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

А вот сами маскировки можно и убрать:
x = (x <<8) + (x >>8);
Но я не уверен, что без маскировки будет работать при любых свойствах оптимизатора/компилятора.

Соседних, конечно. А как надо было?

Сообщение от :
А вот и нет. Можно писать на чем угодно, а потом с помощью компилятора получить машинные команды. Сейчас так и делают

Не логично. Если результатом должна быть последовательность команд, значит, и надо писать эти команды. Зачем всякие разные компиляторы и т.д.? Открываем бинарным редактором пустой файл и начинаем : 4D 5A ...

Сообщение от :
Мне кажется, что эти два утверждения противоречат друг другу.

А мне не кажется. [Ответ]

еще раз. все решается конкретно.
пример номер раз:
имеем скажем конвейр и наш комп управляет автоматом,
который скажем выполняет ряд технологических операций.
1) ассемблер
прога сложная при написании, но делается 1 раз.
Надежность супер ибо в принципе прога простая по выполняемым действиям,
можно отказаться от от всех устройств типа винчестеров итд
и прошить прогу скажем рядом с биосом.
2) Си. красиво, наглядно, но за собой потянулись библиотеки,
библиотеки потянули OS. Итого стоит обычный комп с винтом, OS и тд.

пример второй:
любимая бюсгалтерия
1) ассемблер - с трудом пишем прогу но просто зашиваемся
в во всяких дополнениях и изменениях (как вы там обзываетесь? maintainability? ну да тянет на ноль с плюсом :-) )
2) си куча библиотек, быстрое изменение визуальных компонент итд.

Резюме: помойму ясно? в примере номер 1 ассемблер сам просится. можно ставить даже однокристалку. А вот пример
номер 2 на ассемблере писать даже ярый садомазохист не будет :-)

P.S. хотя как странно началось обсуждение ? :-)
начали с мозго... и закончили мерянием пиписек у сей и ассемблера :-) [Ответ]

Конечно все зависит от задачи. Давайте будем говорить на примере задач близких к примеру 2. Все мною вышесказанное относиться именно к таким задачам. [Ответ]

zss_vrn

Сообщение от :
Вот, гусеница и бабочка - это одно и то же? ))

Конечно нет. А вот у тебя да. Заметь, я не спорю, что из одного получаеться другое, но это всё же разные вещи...

Сообщение от :
Блин, всеж пришлось проверить - работает и сдвиг не лишний, без него не работает.

Да, действительно. Я потом тоже проверил - работает...

Сообщение от :
Соседних, конечно. А как надо было?

Ну... В условии ничего не было сказано о расположении этих байт.

Сообщение от :
Не логично. Если результатом должна быть последовательность команд, значит, и надо писать эти команды. Зачем всякие разные компиляторы и т.д.?

Чтобы описывать большие последовательности команд на языке хотя бы немного похожем на естесвенный.

Лучше всего(в идеале) было бы произнести описание программы на русском. В таком случае "исходником" была бы произнесённая фраза(описание). И программа получалась бы из этих исходников с помощью суперпродвинутого компилятора.

Устроить что ли голосование, по поводу определения слова "программа", а то мы так и не выясним кто прав...

Const

Сообщение от :
начали с мозго... и закончили мерянием пиписек у сей и ассемблера :-)

Ещё не закончили...
Кстати, твои примеры ещё раз показали, что сложность программ одинакова вне зависимости от языка, а вот сложность создания таких программ, зависит от задачи. [Ответ]

Соблюдайте правила, тема дискуссии "Надёжность и трудоёмкость программ" [Ответ]

Rabbit

Сообщение от :
Конечно нет. А вот у тебя да.

И оба правы - открой энциклопедию

Сообщение от :
Да, действительно. Я потом тоже проверил - работает...

Без теста никогда не скажешь, работает или нет

Сообщение от :
Ну... В условии ничего не было сказано о расположении этих байт.

Выходит, на усмотрение исполнителя...

Сообщение от :
Лучше всего(в идеале) было бы произнести описание программы на русском.

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

И потом, КАКИХ команд? Если машинных, то на машинном языке и надо писать. [Ответ]