Цитата(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 Смахивает, но не ооп

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

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

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

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

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