Вот задача из жизни: нужно парсить данные и сосчитать суму по одному из столбцов:

Код

#!/usr/bin/perl $sum=0; while (<STDIN>){ /([^ \t]+)[ \t]+([^ \t]+)[ \t]+([^ \t]+)[ \t]+([^ \t]+)[ \t]+([^ \t]+)[ \t]+([^ \t]+)[ \t]+([^ \t]+)/; $sum+=$6; } print "\ntrafik=".$sum;

Зачем мне ООП?
Написать 6 строчек быстрее чем использовать классы.

Цитата(Secandr @ 7.10.2004, 14:28)

Написать 6 строчек быстрее чем использовать классы.

На таком уровне решения задач - конечно нафиг не надо ООП. Как и для задачи вывести hello, world!

Можно прямо так
echo hello, world!

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

По сути каждый слой имеет свою нишу. Можно и в достаточно большой системе, написанной в основном на ООП, использовать ассемблерные вставки. И рассматривать их именно с позиции "слоев".
Если я работаю в области написания драйверов, то вряд ли мне потребуется ООП.
Если пишу программы для мобильника, то скорее буду использовать чистый С вкупе с ассемблером.

Прошу обратить внимание, что такая "слойность" отслеживается и при историческом развитии программирования. Т.е. можно отследить параллель между задачами, которые решались и методами, которыми эти задачи решались.

Но вот какие задачи и какую концепцию мы увидим дальше ? Может наступил некий предел возможностям человека абстрагировать задачи и выше мы не поднимемся ?

Что-то меня толкает перенести эту тему в "Научные дисскуссии"

Цитата

Что-то меня толкает перенести эту тему в "Научные дисскуссии"

ИМХо не стоит

Цитата

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

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

Не понимаю как можно наследование реализовать в асме..

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

И ооп там не нужно. Вот вам и пример прекладного программирования без ООП.

Цитата

Не понимаю как можно наследование реализовать в асме..

для этого можно дизассемблировать любую программу, написанную с использованием наследования на C++
хорошим примером реализации классов, наследования и пр. без использования специализированных для этого языков может послужить Windows API, в этом случае HANDLE, который очень часто передается в качестве первого параметра, служит некоторым аналогом указателя на объект
а пример наследования можно увидеть, если посмотреть на работу с графическими объектами (HBITMAP, HICON, ...)
опять же: объектно-ориентированный подход не занимается вопросами того, акк будет реализована работа с классами, он нужен для построения общей схемы программы
а в каждом ОО-языке ООП реализуется по-разному: в C++ одним способом, в Java немного другим, в C вообще никак

ООП хорошо для быстрой разработки проектов. Как правило сроки разработки оказываются более важным фактором чем размер программы или быстродействие. Но там где нужны критические вещи, от ООП как правило отказываются. Ядро операционной системы и драйвера к устройствам пишут на С и ассемблере, чтобы быть поближе к железу и использовать его максимально эффективно.

Язык С и ассемблер хороши своей простотой. Для них легко сделать компилятор и размер скомпилированной программы будет значительно меньше и при граммотном написании программа будет работать быстрее. Но они требуют от программиста более высокой квалификации, чем объектные языки, так как они не берут на себя ответственности за действия программиста.

Понятно что работать со строками гораздо приятнее в С++ чем в С, но как быть уверенным что строковый класс работает с ними оптимально? И почему их так много всяких разных?

За ООП двумя руками!

Цитата

Но они требуют от программиста более высокой квалификации,

То есть ты считаешь что программер который программирует на Си, гораздо более квалифицированный чем С++'ник ?

Цитата

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

В С++ тоже никто на себя отвественность не берёт...

Цитата(Secandr @ 7.10.2004, 15:53)

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

Так я о том же. Область твоего программирования находится в прикладной области легко алгоритмизируемых задач, причем достаточно последовательных (ничего так выразился ).

Это не значит, что это легче или не так пристижно. Но просто на каком-то уровне масштаба задачи ООП пока является наиболее приемлемым вариантом и проектирования и программирования. Причем на сегодня для решения масштабных задач используется ООП.

НО ! Я на обычном Паскале делал некий аналог ObjectPascal. На Си это тоже можно. Проблема не в компиляторе. Кстати, даже TurboAssembler от Borland тоже имел некие объектные расширения. Меня больше волнует проблема даже больше проектирования.

Я уже неоднократно слышал о функциональных языках, к сожалению никакого опыта применения у меня нет. Но идея использования функций вместо объектов явно занятна.

Например, при программировании каких-либо учетных систем бывает надо получить курс валют. И сразу возникает вопросы новичка в Delphi "где взять компонент, который умеет это делать". Но ведь на самом деле надо "получить курс валюты", а как это будет реализовано - да по барабану. И объекты тут совсем не причем.

Т.е. возможен ли такой путь (который кстати уже имеет место в службах WEB-Service+UDDI) - программа находит не объект, а функцию. И выполняет ее. Несомненно, программа может состоять из объектов, но не для каждой (даже достаточно сложной задачи) уже нужен будет объект. И вполне может быть разработан подход, в котором объекты/классы будут не самым верхним слоем. А будут те же функции. Только на другом уровне - так сказать "в мировом масштабе".

Цитата

То есть ты считаешь что программер который программирует на Си, гораздо более квалифицированный чем С++'ник ?

Да. Потому что приходиться работать не с объектами, которые могут для тебя являтся просто черными ящиками, а с областями памяти, в которые ты помещаешь свои данные. Что легче написать

Код

string s = "Hello"; s += ", world";

или

Код

char s[256] = "Hello"; strcat(s, ", world"); /* а что будет если мы вылезем за буфер? */

Цитата

В С++ тоже никто на себя отвественность не берёт...

Берет. Конструкторы и деструкторы для чего придуманы? А обработка исключений?

Цитата

А обработка исключений?

ОНа и в Си есть вроде..

Цитата(chipset @ 7.10.2004, 13:39)

Цитата А обработка исключений? ОНа и в Си есть вроде..

Нету. Вместо try и catch используется оператор goto

Цитата

#!/usr/bin/perl $sum=0; while (<STDIN>){ /([^ \t]+)[ \t]+([^ \t]+)[ \t]+([^ \t]+)[ \t]+([^ \t]+)[ \t]+([^ \t]+)[ \t]+([^ \t]+)[ \t]+([^ \t]+)/; $sum+=$6; } print "\ntrafik=".$sum;

сразу скажу Perl'а не знаю, но:
что такое STDIN? уж не стандартный ли поток ввода?
а что это как не объект? пусть реализованный где-то в самом языке
для того, чтобы быть объектом, совсем необязательно использовать слово class...