Только не надейтесь, что я буду сравнивать Pascal и C++
Война будет более глобальной

Я предлагаю высказаться тем, кто ЗА объектно-ориентированные языки и кто ПРОТИВ.

Для затравки - я ЗА. И вот почему:

1. Объекты позволяют строить гораздо более мощные системы
2. Повторное использование кода улучшается и возрастает
3. Рапараллеливание процессов гораздо более удобно, что позволяет масштабировать задачи.
4. Объект внутри себя позволяет использовать все что душе угодно - те же процедурные языки или функциональные.

В таком разе подкорректируй сабж - чтобы было понятно о чем тред.

И потом - с какими типами языков ты хотел бы сравнивать объектно-ориентированные?

По твоим тезисам есть масса возражений - однако они сформулированы слишком общо, пальцы жалко

Это сообщение отредактировал(а) Akina - 7.10.2004, 11:04

сначала хотел написать

Цитата

а кто за Windows или за Linux , нужно указать область применения

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

резюме: я за то, чтобы использовать ООП (в смысле подход, а не программирование), но и за то, чтобы очень осмотрительно применять ООП-языки при разработке в специфических областях

Соласен с maxim1000 , всё должно быть вмеру.
Вот зачем мне пименять классы в пхп, если я хочу просто обработать форму и напечатать результа на экран?

Цитата(Secandr @ 7.10.2004, 13:02)

Соласен с maxim1000 , всё должно быть вмеру.

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

Так почему же не рассматривать объекты как еще один уровень. Понятно, что управлять портом ввода-вывода на низком уровне через объекты - не получиться. Но если та же операционка на мобильнике будет иметь объект как порт ввода-вывода,то пользоваться им будет удобно.

Мой товарищ работал с Symbian (EPOC) - так там по его словам практически вся ОС построена на объектах. И программы получаются очень компактные и функциональные. Потому как работа внутренних систем инкапсулирована в объекты.

Я несколько переформулирую идею - понятно, что на уровне ассемблера не будет у вас выбора (какое там ООП - влезть бы в пару килобайт). Но если мы говорим о дальнейшем развитии - любая ОС может быть представлена как набор объектов, которые будут уже отвечать за работу с подключенными устройствами. Любое программное обеспечение ВЫГОДНО представлять на таком уровне - не предоставлять голые вызовы функции, а предоставлять набор объектов. Те же драйвера устройств или еще что.

Так вот я думаю, что концепция ООП - хорошая концепция, которая является еще более высоким уровнем над тем, что было до этого.

Программы величиной больше 500 строк (субьективно) очень ТЯЖЕЛО создавать без ООП.
Пример: в том проекте который я сейчас отлаживаю, около 20 классов, глаза разбегаются..
Если бы это были функции, я с ума сошёл тут же...

Преобретаешь простоту и универсальность, теряешь в производительности.

Цитата

Преобретаешь простоту и универсальность, теряешь в производительности.

Проведем эксперимент?

Асемблер VS делфи. У кого будет меньше программа и быстрее работать?

Secandr
Спроси у Монти ;)
Он как то провёл исследование ASM vs Delphi
Добавлено @ 12:43
Я так понимаю, тут речь идёт о ООП vs процедурщина.
Поэтому и тестить надо на одном языке:
Си vs C++?


Это сообщение отредактировал(а) chipset - 7.10.2004, 12:39

chipset
Я утрирую. о смысл от этого не меняется.

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

Я так понимаю, тут речь идёт о ООП vs процедурщина.

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

А выше куда ? Если мы говорим о распределенных и параллельных вычислениях, то как раз объекты и позволяют сделать это хорошо. А вот выше есть что-нибудь ? Или вместо ?

Моя концепция такова, что как сети и компьютеры создаются "слоями", так и софт может создаваться "слоями". И на сегодня объекты для меня самый высокий "слой". Ниже всего ассемблер, потом процедуры как методы объектов, ну и сами объекты/классы.

Но есть ли у кого-нибудь идея - может есть какой-то другой ?

Цитата

Я несколько переформулирую идею - понятно, что на уровне ассемблера не будет у вас выбора (какое там ООП - влезть бы в пару килобайт). Но если мы говорим о дальнейшем развитии - любая ОС может быть представлена как набор объектов, которые будут уже отвечать за работу с подключенными устройствами. Любое программное обеспечение ВЫГОДНО представлять на таком уровне - не предоставлять голые вызовы функции, а предоставлять набор объектов. Те же драйвера устройств или еще что.

я ни в коем случае не собирался спорить с тем, что слои ПО хорошо представлять в таком виде (я и сам стараюсь так делать)
я говорил о применении ООП при разработке внутри одного конкретного слоя (например, алгоритм сжатия или обработки видео)
и даже не говорил "не надо", а "осмотрительно"
Добавлено @ 13:10

Цитата

Преобретаешь простоту и универсальность, теряешь в производительности.

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

Это сообщение отредактировал(а) maxim1000 - 7.10.2004, 13:05

Цитата

Я просто не видел более продвинутой концепции. Если смотреть "с времен очаковских и покоренья Крыма", то сначала были чистые коды, потом ассемблеры, потом языки высокго уровня с процедурами, потом даже несколько файлов и отдельные библиотеки. Теперь настал черед классов и объектов.

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

Цитата

Объект внутри себя позволяет использовать все что душе угодно - те же процедурные языки или функциональные.

Добавлено @ 13:17

Цитата

А выше куда ? Если мы говорим о распределенных и параллельных вычислениях, то как раз объекты и позволяют сделать это хорошо. А вот выше есть что-нибудь ? Или вместо ?

ну, понятия процессов и потоков все-таки не тождественны объектам, так что можно назвать это "еще чем-нибудь"

Цитата

Преобретаешь простоту и универсальность, теряешь в производительности.

Обьясните мне ламеру, почему при ООП теряешь в производительности...

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

Код

#!/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...

Цитата(Sun @ 7.10.2004, 17:27)

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

Исходя из такой логики на JAVA писать еще проще и не требуется хорошей подготовки
Тут и уничтожать ничего не надо.

Помню пришла к нам тетенька из какого-то НИИ. Мы ей показываем стенд, как мы для него программу на Паскале пишем с новым алгоритмом (добавляем), как собираем, как запускаем и все на экране красиво. А она на нас смотрит и говорит: "А в кодах что я должна набирать ?". Она, оказывается, все в кодах набирала. Знала наизусть несколько десятков команд.
И программку для записи байта в порт и оттуда она напишет быстрее меня. Но зато систему, которая будет обслуживать все датчики, следить за их состоянием и в нужное время напоминать обо всех проблемах она написать не сможет. И не потому что глупее - просто уровень задач (даже лучше слой) задач - другой. Не хуже и не лучше. Просто другой.

Я когда на JAVA переходил - полгода привыкал, что удалять указатели не надо


Добавлено @ 17:08
Многие из нас - уже достаточно сложившиеся профи, которые решают определенные задачи с использованием той или иной технологии. На сегодня IMHO наиболее масштабируемая - ООП.

Только опять я не принижаю роль других техник. Я делаю сравнение типа - печь, баня, сарай, дом, аэропорт.

Печь тоже надо уметь делать, но техника для нее не подходит для аэропорта.

Тоже самое и тут - лучше ООП для огромных систем пока ничего нет. А у меня есть ощущение, что уже наступает момент, когда системы уже перерастают и этот уровень.

От аэропорта пришли к Международной Космической станции. Тут ООП уже не спасает. Или все таки спасает ?
И вообще есть ли задачи, которые мы пока решить не можем не одной из перечисленных техник ?

maxim1000 А это стандартные вещи для юникса, там даже ком порт работает как стандартный файл

А я перл уважаю - быстро и сердито, всегда под рукой.

Цитата(Secandr @ 7.10.2004, 16:10)

maxim1000 А это стандартные вещи для юникса, там даже ком порт работает как стандартный файл

ну это и для Windows так
только я хотел сказать другое:
все порты, все потоки ввода/вывода, да и обычные дисковые файлы представлены уже в самой системе в виде "логических" файлов
разве это не наследование в чистом виде?
кроме того, когда программист читает из потока, он не задумывается о том, как ОС будет это делать - тоже сильно смахивает на ООП

Цитата

Исходя из такой логики на JAVA писать еще проще и не требуется хорошей подготовки Тут и уничтожать ничего не надо.

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

Цитата(Sun @ 7.10.2004, 18:15)

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

Так в том то и дело, что задачи ДОЛЖНЫ быть разные. Нефиг на JAVA писать то, что хорошо ложиться на С. And vice-versa.
Просто если я не думаю над одной проблемой я могу решать другую. И чем более подходящие у меня блоки для данных решений, тем быстрее я решу задачу. Вот я и раскручиваю всех на то, чтобы подумать над тем, есть ли блоки еще более крупные чем объекты

Цитата

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

В Win32 можно использовать __try,__except
Братцы!
Да ведь оказывается на QBasic программер квалифицированней чем Жабист

Цитата(chipset @ 7.10.2004, 08:49)

...Жабист...

Ты эта ... смотри ...

Цитата(chipset @ 7.10.2004, 14:49)

Цитата Нету. Вместо try и catch используется оператор goto  В Win32 можно использовать __try,__except Братцы! Да ведь оказывается на QBasic программер квалифицированней чем Жабист

В Windows все не как у людей В стандартном С обработки исключений нет. Вот тебе пример кода их Linux kernel, где вместо try catch используется goto

Код

int __devinit cpu_up(unsigned int cpu) {        int ret;        void *hcpu = (void *)(long)cpu;        if ((ret = down_interruptible(&cpucontrol)) != 0)                return ret;        if (cpu_online(cpu) || !cpu_present(cpu)) {                ret = -EINVAL;                goto out;        }        ret = notifier_call_chain(&cpu_chain, CPU_UP_PREPARE, hcpu);        if (ret == NOTIFY_BAD) {                printk("%s: attempt to bring up CPU %u failed\n",                                __FUNCTION__, cpu);                ret = -EINVAL;                goto out_notify;        }        /* Arch-specific enabling code. */        ret = __cpu_up(cpu);        if (ret != 0)                goto out_notify;        if (!cpu_online(cpu))                BUG();        /* Now call notifier in preparation. */        notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu); out_notify:        if (ret != 0)                notifier_call_chain(&cpu_chain, CPU_UP_CANCELED, hcpu); out:        up(&cpucontrol);        return ret;[code] }

Цитата

Ты эта ... смотри ...

Добавлено @ 18:14

Цитата

Вот тебе пример кода их Linux kernel, где вместо try catch используется goto

Бедные линуксоиды...

Цитата(AntonSaburov @ 7.10.2004, 16:19)

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

На самом деле есть и даже большой

Цитата(AntonSaburov @ 7.10.2004, 16:19)

Но идея использования функций вместо объектов явно занятна.

Не функции вместо объектов, а описание задачи вместо, описания алгоритма ее решения.

Вот мое мнение по этому поводу, лучше Джоэла я все равно не скажу, потому читайте лучше оригинал: Закон Дырявых Абстракций

Цитата(LSD @ 7.10.2004, 20:24)

Не функции вместо объектов, а описание задачи вместо, описания алгоритма ее решения

Да, именно это я имел в виду

Цитата(Pegas @ 7.10.2004, 23:27)

Вот мое мнение по этому поводу, лучше Джоэла я все равно не скажу, потому читайте лучше оригинал: Закон Дырявых Абстракций

Ну я бы не стал столь категорично. Огромное количество людей пишут на HTML, JAVA, JavaScript и даже не думают о том, что лежит под ними.
И это в какой-то степени правильно. Разделение труда - специализация.

Опять же возвращаясь к "слойности" задач. Может будет такой момент, когда программисты будут делиться и на категории задач, а не только на языки программирования. Понятно, что для написание крупных систем надо понимать СУБД, HTTP, какой-нибудь язык программирования и возможно ее что-то.
И конечно профи высокого уровня, которые работали на всех "слоях" будут цениться выше, чем другие. Но это было всегда и не только в IT области.

maxim1000 Смахивает, но не ооп

Интересная постановка вопроса. ИМХО она немного некоректна. Все равно что сказать, вы за электричество или против. Конечно же ЗА.
Ибо любой маломальский программист, который имеет хоть какой-нибудь опыт написания приложений (можно читать как кода), со временем понимает, что ООП - это более прередовой метод программирования, который позволяет экономить время и не распылять силы. А кроме того и многое другое. Вспомните определение понятий трех китов ООП - инкапсуляция, полиморфизм, и наследование. Вспомните.
Вот здесь...
И теперь вы сразу согласитесь со мной. А если не согласитесь, то вспомните еще раз, и так до тех пор, пока не согласитесь.

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

А вот этой статьей (Закон Дырявых Абстракций) я хотел сказать то, что не надо забывать и о том, что же лежит в черных ящиках - объектах.

Полностью согласен.

Я привёл примеры программирования, где нет смысла применять ооп.
ООП - мощный метод, но нельзя говорить что он единственный.

Сейчас меня будут бить..
Господа, я против ООП. Но позвольте сперва объясниться..
Как и любой нормальный программер, я считаю ООП существенно экономит время, это понятнее для человека, что позволяет создавать все более сложные системы. Да, это все замечательно. Но!
ИМХО, в ООП есть очень опасная вещь - черный ящик. Работая с объектом не обязательно знать как он устроен. Теперь смотрите: появляется поколение программистов, взращенных на этой идеалогии - они используют готовые решения или создают свои классы на основе СУЩЕСТВУЮЩИХ. Мы все дальше и дальше уходим от железа - допустим, в моем городе куча спецов на Delphi, но почти никого на ASM'e - народ не знает и НЕ хочет знать как все это устроено! Понимающих во "внутренностях" компьютера становится все меньше (во всяком случае, большинство университетов выпускают в основном высокоуровневых специалистов).
Итого - вся мощь ООП и вообще все программирование держится на кучке "низкоуровневых фанатиков". Скоро все забудут про указатели и ручное очищение памяти. Действительно, зачем об этом думать, если уже все решено за нас? Однако, представьте, что придет нужда сделать исправления на самом низком уровне. Надо, а некому!
Поэтому, я считаю, что упование на ООП ведет к краху IT-индустрии, т.к. подрывается ее фундамент.
Ессно, ООП нужно использовать, но не стоит забывать об истоках. Во всяком случае, до тех пор, пока процессоры, установленные у нас на компах, не начнут понимать что-то типа Java или С++.

З.Ы. Повторюсь, это всего лишь ИМХО. Мое ЛИЧНОЕ мнение.

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

Цитата

Изучение программирования уже начинается не с битов и байтов и устройства процессора, а с драг-энд-дропа.

В общем то да, C#/VB дали этому делу ход. А проблема в том что работодателю как мне кажется (а на самом деле хз) по**** на это.
А начинать нужно не с этого, а с алгоритмов

Это сообщение отредактировал(а) chipset - 15.10.2004, 10:45

а может, нужны и такие программисты?

Цитата

Итого - вся мощь ООП и вообще все программирование держится на кучке "низкоуровневых фанатиков"

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

Цитата

. Мы все дальше и дальше уходим от железа - допустим, в моем городе куча спецов на Delphi, но почти никого на ASM'e - народ не знает и НЕ хочет знать как все это устроено!

Спрашиваю: кому нужен АСМ в твоём городе? Что на нём кроме драйверов можно эффективно программировать?
К сожалению программисты немного потеряли ореол таинственности, хакеризма и.т.д...

Это сообщение отредактировал(а) chipset - 15.10.2004, 10:48

просто разработка ПО стала такой большой областью, что охватить ее одному человеку все сложнее и сложнее
поэтому разделение людей по уровням будет все сильнее и стльнее

Моё ИМХО: всё то что только что сказал Sun изучают школьники которым старший брат показал как кнопочки рисовать в VB в своё удовольствие.
Добавлено @ 10:52
И считают себя при этом суперпупер прогерами..

Это сообщение отредактировал(а) chipset - 15.10.2004, 10:52

Kurt

Цитата(Kurt @ 15.10.2004, 00:49)

ИМХО, в ООП есть очень опасная вещь - черный ящик. Работая с объектом не обязательно знать как он устроен. Теперь смотрите: появляется поколение программистов, взращенных на этой идеалогии - они используют готовые решения или создают свои классы на основе СУЩЕСТВУЮЩИХ. Мы все дальше и дальше уходим от железа - допустим, в моем городе куча спецов на Delphi, но почти никого на ASM'e - народ не знает и НЕ хочет знать как все это устроено! Понимающих во "внутренностях" компьютера становится все меньше (во всяком случае, большинство университетов выпускают в основном высокоуровневых специалистов). Итого - вся мощь ООП и вообще все программирование держится на кучке "низкоуровневых фанатиков". Скоро все забудут про указатели и ручное очищение памяти. Действительно, зачем об этом думать, если уже все решено за нас? Однако, представьте, что придет нужда сделать исправления на самом низком уровне. Надо, а некому! Поэтому, я считаю, что упование на ООП ведет к краху IT-индустрии, т.к. подрывается ее фундамент.

Извини, но ты чушь сказал. А кто по твоему разрабатывает компиляторы, среды разработки и исполнения программ? "низкоуровневые фанатики"? Просто есть рынок труда. Если большинство современных пректов дешевле разрабатывать с применением ООП, то оно и будет работать. А низкоуровневое программирование никуда не денется, просто оно занимает свою нишу и всё.
Мне вот интересно что ты со знанием ASM собрался исправлять, например в модуле R/3 или Axata?
А мощь ООП на специалистах по разработке концепций и аналитиках. Что ни говори, а низкоуровневый программист всегда останется всего лишь исполнителем, причём самого низшего звена.
Основы конечно ИТ-специалисту необходимы, но между основами и разработкой огромная пропасть. И не надо путать эти понятия.

Цитата(gray_k @ 15.10.2004, 07:55)

Мне вот интересно что ты со знанием ASM собрался исправлять, например в модуле R/3 или Axata? А мощь ООП на специалистах по разработке концепций и аналитиках. Что ни говори, а низкоуровневый программист всегда останется всего лишь исполнителем, причём самого низшего звена. Основы конечно ИТ-специалисту необходимы, но между основами и разработкой огромная пропасть. И не надо путать эти понятия.

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

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

Цитата(Sun @ 15.10.2004, 12:38)

Хороший архитектор для начала должен поработать простым строителем.

Хороший пример того, что анологии фальшивы.
Архитектор отнюдь не должен работать строителем, так же как и инженер не должен работать техником, для того чтобы быть хорошим специалистом.

Цитата

Хороший архитектор для начала должен поработать простым строителем.

Кстати в Microsoft, архитекторы кодят простые задачи несколько раз в неделю - чтоб не расслаблялись и не теряли чутья..

Это сообщение отредактировал(а) chipset - 15.10.2004, 13:28

Цитата(gray_k @ 15.10.2004, 10:23)

Цитата(Sun @ 15.10.2004, ) Хороший архитектор для начала должен поработать простым строителем. Хороший пример того, что анологии фальшивы. Архитектор отнюдь не должен работать строителем, так же как и инженер не должен работать техником, для того чтобы быть хорошим специалистом.

У нас разное понимание "хорошего специалиста"

Цитата

Извини, но ты чушь сказал. А кто по твоему разрабатывает компиляторы, среды разработки и исполнения программ? "низкоуровневые фанатики"? Просто есть рынок труда

Угу. Вот смотри.. Пройдемся по ВУЗам нашей распрекрасной страны..
Посчитай, чему больше учат? Кого готовят? Спецов по бизнес приложениям или по железу и низкоуровнему программированию? В каких пропорциях? Почему? Прааально - рынок труда. Всем нужны программеры "плюх энд плюй"! Мы приходим к тому, что выросло поколение "программистов", к-е даже командной строкой не умеет пользоваться! А что дальше?
ИМХО, происходит деградация и хороших спецов найти все труднее, т.к. мы забывам основы.

Если бы не ООП, мы наверное до сих пор бы сидели в досовском интерфейсе. И ООП никак не крах ИТ индустрии. Просто надо грамотно разделять труд.

Цитата(Pegas @ 16.10.2004, 04:46)

Если бы не ООП, мы наверное до сих пор бы сидели в досовском интерфейсе. И ООП никак не крах ИТ индустрии. Просто надо грамотно разделять труд.

Я на это гляжу с такой точки зрения есть С(не поддерживает ООП) и С++(поддерживает ООП). Сейчас я в основном занимаюся программированием микроконтроллеров и ест. не о каком с++, тут и речи идти неможет, и так всё тормозит, а если там ещё и классы делать, то программак вместо 50кб будет занимать 400 кб, где я столько памяти возьму ? Тоже с драйверами... Да и винду с линухой на чистом си не спроста написали, так, чо всё зависит от конкретных обстоятельств, конечно ООП упрощает поддержку кода, увиличивает его "читаемость" и переносимость, но не везде оно применимо. А то что тут говорят, типа люди асм забывать стали и от истоков отбились, то потребность в системщиках и низкоуровневых программистах будет всегда, только стоить они будут дороже, что не так уж и плохо

Цитата(shedon @ 26.10.2004, 07:46)

Да и винду с линухой на чистом си не спроста написали

Винды 95,98 писали на Кобол+С, дальше не знаю

Цитата(shedon @ 26.10.2004, 07:46)

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

Да вних потребность и сейчс дикая, ДРОВА нужны однако

Цитата(Kurt @ 15.10.2004, 17:39)

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

А надо ли ему ей пользоваться, если он пишет программу складского учета, работающую под виндами, а не компилятор?
И кто быстрее эту программу напишет, ассемблерщик или плюх энд плюйщик, учитывая, что последний знает, какие процессы происходят на складе?

Это сообщение отредактировал(а) Alex101 - 26.10.2004, 10:55

Цитата(Shedon @ 26.10.2004, 00:09)

Да и винду с линухой на чистом си не спроста написали

Как это? А разве не на С++?
Возможно ядро, но я своими глазами где то читал что мол ".. с приходом ООП стало легко делать масштабные проекты, как например и сделали в Win95... "

Цитата(Jey_k @ 26.10.2004, 00:09)

Винды 95,98 писали на Кобол+С

Это сообщение отредактировал(а) chipset - 26.10.2004, 12:16

Цитата(chipset @ 26.10.2004, 09:14)

Как это? А разве не на С++?  Возможно ядро, но я своими глазами где то читал что мол ".. с приходом ООП стало легко делать масштабные проекты, как например и сделали в Win95... "

Нет на чистом си, сам видел

Цитата(Alex101 @ 26.10.2004, 10:53)

А надо ли ему ей пользоваться, если он пишет программу складского учета, работающую под виндами, а не компилятор? И кто быстрее эту программу напишет, ассемблерщик или плюх энд плюйщик, учитывая, что последний знает, какие процессы происходят на складе?

Согласен. Нельзя же на асме писать проги для работы с БД или на дельфях дрова ваять, хотя слышал что это возможно.

Да дрова на асме сейчас тоже уже мало кто пишет, пишут на си(без плюсов), хотя некоторые "особо продвинутые" их визардами лепят.

Да и компиляторы тоже не на асме пишут
Что бы строить таблицы решений, нужно знание машины, опкодов. Но это лишь небольшая часть компилятора, который например может гнерить код под разные процессоры и ОС.

Цитата

Нет на чистом си, сам видел

а где, такое показывают?

Цитата(chipset @ 26.10.2004, 12:14)

Цитата(Shedon @ 26.10.2004, 00:09) Да и винду с линухой на чистом си не спроста написали Как это? А разве не на С++? Возможно ядро, но я своими глазами где то читал что мол ".. с приходом ООП стало легко делать масштабные проекты, как например и сделали в Win95... " Цитата(Jey_k @ 26.10.2004, 00:09) Винды 95,98 писали на Кобол+С

А я где-то читал, что винды писали в основном на асме

Цитата(Anklav @ 27.11.2004, 05:08)

А я где-то читал, что винды писали в основном на асме

LOL Кто-то над тобой нехило подшутил

Небольшой юморной оффтопик:
.NET Driver Development Kit

Цитата(chipset @ 27.11.2004, 21:05)

Небольшой юморной оффтопик: .NET Driver Development Kit

Мне тут один знакомый сказал, что будет писать кроссплатформенную файловую систему на C#

Цитата(simanyay @ 27.11.2004, 20:20)

Мне тут один знакомый сказал, что будет писать кроссплатформенную файловую систему на C#

Ну не знаю как вы тогда к этому отнесётесь: http://www.cs.utah.edu/flux/janos/
Операционная система на Java, причём это уже вторая которую встречаю.