| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Религиозные войны > Языки программирования |
| Автор: AntonSaburov 7.10.2004, 10:55 |
| Только не надейтесь, что я буду сравнивать Pascal и C++ Война будет более глобальной  Я предлагаю высказаться тем, кто ЗА объектно-ориентированные языки и кто ПРОТИВ. Для затравки - я ЗА. И вот почему: 1. Объекты позволяют строить гораздо более мощные системы 2. Повторное использование кода улучшается и возрастает 3. Рапараллеливание процессов гораздо более удобно, что позволяет масштабировать задачи. 4. Объект внутри себя позволяет использовать все что душе угодно - те же процедурные языки или функциональные. |
| Автор: Akina 7.10.2004, 11:03 |
| В таком разе подкорректируй сабж - чтобы было понятно о чем тред. И потом - с какими типами языков ты хотел бы сравнивать объектно-ориентированные? По твоим тезисам есть масса возражений - однако они сформулированы слишком общо, пальцы жалко  |
| Автор: maxim1000 7.10.2004, 11:22 | ||
сначала хотел написать
потом, как водится, подумал... я за то, чтобы использовать объектно-ориентированный подход практически во всех сферах программирования однако, в той области, в которой я сейчас работаю (разработка встроенного ПО для устройств с мультимедийными функциями), часто возникает одно НО (чисто психологическое): если программист использует какие-то объекты, то он, по идее ООП, не должен даже думать о том, как все там внутри реализовано, приводит это к тому, что он не чувствует того, какие операции исполняются долго, какие быстро (ведь он не знает и не хочет знать, как они выполняются ), это может привести к большой неоптимальности:пример: есть класс вектор (в математическом представлении), у него есть свойство модуль (корень из суммы квадратов координат), а программисту для чего-то понадобилось вычислить квадрат модуля вектора, что он сделает? возведет длину вектора в квадрат однако, это абсолютно не означает, что я не использую ООП при проектировании программы, которую в последствии, возможно, напишу на ассемблере резюме: я за то, чтобы использовать ООП (в смысле подход, а не программирование), но и за то, чтобы очень осмотрительно применять ООП-языки при разработке в специфических областях |
| Автор: Secandr 7.10.2004, 12:02 |
| Соласен с maxim1000 , всё должно быть вмеру. Вот зачем мне пименять классы в пхп, если я хочу просто обработать форму и напечатать результа на экран? |
| Автор: AntonSaburov 7.10.2004, 12:27 | ||
А я не согласен. Практически все, что создается в компьютерной индустрии (сетевые протоколы, сами компьютеры, операционные системы) создаются в виде логических уровней. Для сети это OSI со своими уровнями, тот же компьютер - вентили, микропрограммы, команды процессора и выше. Так почему же не рассматривать объекты как еще один уровень. Понятно, что управлять портом ввода-вывода на низком уровне через объекты - не получиться. Но если та же операционка на мобильнике будет иметь объект как порт ввода-вывода,то пользоваться им будет удобно. Мой товарищ работал с Symbian (EPOC) - так там по его словам практически вся ОС построена на объектах. И программы получаются очень компактные и функциональные. Потому как работа внутренних систем инкапсулирована в объекты. Я несколько переформулирую идею - понятно, что на уровне ассемблера не будет у вас выбора (какое там ООП - влезть бы в пару килобайт). Но если мы говорим о дальнейшем развитии - любая ОС может быть представлена как набор объектов, которые будут уже отвечать за работу с подключенными устройствами. Любое программное обеспечение ВЫГОДНО представлять на таком уровне - не предоставлять голые вызовы функции, а предоставлять набор объектов. Те же драйвера устройств или еще что. Так вот я думаю, что концепция ООП - хорошая концепция, которая является еще более высоким уровнем над тем, что было до этого. |
| Автор: chipset 7.10.2004, 12:32 |
| Программы величиной больше 500 строк (субьективно) очень ТЯЖЕЛО создавать без ООП. Пример: в том проекте который я сейчас отлаживаю, около 20 классов, глаза разбегаются.. Если бы это были функции, я с ума сошёл тут же...  |
| Автор: Secandr 7.10.2004, 12:34 |
| Преобретаешь простоту и универсальность, теряешь в производительности. |
| Автор: chipset 7.10.2004, 12:35 | ||
Проведем эксперимент? |
| Автор: Secandr 7.10.2004, 12:37 |
| Асемблер VS делфи. У кого будет меньше программа и быстрее работать? |
| Автор: chipset 7.10.2004, 12:39 |
| Secandr Спроси у Монти ;) Он как то провёл исследование ASM vs Delphi Добавлено @ 12:43 Я так понимаю, тут речь идёт о ООП vs процедурщина. Поэтому и тестить надо на одном языке: Си vs C++? |
| Автор: Secandr 7.10.2004, 12:58 |
| chipset Я утрирую. о смысл от этого не меняется. |
| Автор: AntonSaburov 7.10.2004, 12:59 | ||
Не совсем. Я просто не видел более продвинутой концепции. Если смотреть "с времен очаковских и покоренья Крыма", то сначала были чистые коды, потом ассемблеры, потом языки высокго уровня с процедурами, потом даже несколько файлов и отдельные библиотеки. Теперь настал черед классов и объектов. А выше куда ? Если мы говорим о распределенных и параллельных вычислениях, то как раз объекты и позволяют сделать это хорошо. А вот выше есть что-нибудь ? Или вместо ? Моя концепция такова, что как сети и компьютеры создаются "слоями", так и софт может создаваться "слоями". И на сегодня объекты для меня самый высокий "слой". Ниже всего ассемблер, потом процедуры как методы объектов, ну и сами объекты/классы. Но есть ли у кого-нибудь идея - может есть какой-то другой ? |
| Автор: maxim1000 7.10.2004, 13:04 | ||||
я ни в коем случае не собирался спорить с тем, что слои ПО хорошо представлять в таком виде (я и сам стараюсь так делать) я говорил о применении ООП при разработке внутри одного конкретного слоя (например, алгоритм сжатия или обработки видео) и даже не говорил "не надо", а "осмотрительно" Добавлено @ 13:10
совсем необязательно мне кажется, что все-таки причины потери производительности больше субъективные - зависят от программиста, от того, что он не видит некоторых аспектов реализации а если объекты достаточно крупные, то потери от ООП представляют очень малую часть от вычислительной сложности |
| Автор: maxim1000 7.10.2004, 13:16 | ||||||
я бы сказал по-другому: раньше были чистые коды, потом процедуры и чистые коды, потом библиотеки, процедуры и чистые коды, а теперь ООП, библиотеки, процедуры и чистые коды в каждом случае нужно выбирать оптимальные средства решения задач, а не те, которые позже всех появились, а чаще всего получается комбинация разных методов, например:
Добавлено @ 13:17
ну, понятия процессов и потоков все-таки не тождественны объектам, так что можно назвать это "еще чем-нибудь" |
| Автор: chipset 7.10.2004, 13:27 | ||
Обьясните мне ламеру, почему при ООП теряешь в производительности...  |
| Автор: Secandr 7.10.2004, 13:28 | ||
Вот задача из жизни: нужно парсить данные и сосчитать суму по одному из столбцов:
Зачем мне ООП? Написать 6 строчек быстрее чем использовать классы. |
| Автор: AntonSaburov 7.10.2004, 14:20 | ||
На таком уровне решения задач - конечно нафиг не надо ООП. Как и для задачи вывести hello, world! Можно прямо так echo hello, world! Просто опять же возвращаясь к уровням/слоям По порядку (сверху вниз) - объекты/классы (программирование крупных систем с большим количеством взаимодействий, масштабированием и прочая) - алгоритмический процедурный язык со вставками на ассемблере (программирование небольших задач, оптимизированных библиотек, программы для мобильных устройств, критичные к памяти и к скорости) - ассемблер (программирование драйверов и низокуровневых операций) - машинные коды (программирование контроллеров) По сути каждый слой имеет свою нишу. Можно и в достаточно большой системе, написанной в основном на ООП, использовать ассемблерные вставки. И рассматривать их именно с позиции "слоев". Если я работаю в области написания драйверов, то вряд ли мне потребуется ООП. Если пишу программы для мобильника, то скорее буду использовать чистый С вкупе с ассемблером. Прошу обратить внимание, что такая "слойность" отслеживается и при историческом развитии программирования. Т.е. можно отследить параллель между задачами, которые решались и методами, которыми эти задачи решались. Но вот какие задачи и какую концепцию мы увидим дальше ? Может наступил некий предел возможностям человека абстрагировать задачи и выше мы не поднимемся ? Что-то меня толкает перенести эту тему в "Научные дисскуссии" |
| Автор: chipset 7.10.2004, 14:25 | ||
ИМХо не стоит |
| Автор: maxim1000 7.10.2004, 14:29 | ||
тут нужно четко различать ООП - объектно-ориентированное программирование и ООП - объектно-ориентированный подход или проектирование в первом случае речь, обычно, идет о средствах языка по использованию ООП во втором случае речь идет об этапе, предшествующем написанию какого-либо кода - когда программист придумывает, как же все это будет работать кстати, изначально было придумано ООП во втором понимании (только у меня порядок неправильный получился ), а уже потом объектно-ориентированным программированием стали называть использование языков, имеющих для этого специальные средстватак вот ООП во втором понимании вполне можно и даже стоит использовать даже при разработке приложений real-time обработки информации, в том числе и в ассемблерных программах другое дело, что иногда стоит отказываться от принципов сокрытия информации и т.д. (что часто ведет к снижению понятности и масштабируемости) ради снижения ресурсоемкости. |
| Автор: chipset 7.10.2004, 14:31 |
Не понимаю как можно наследование реализовать в асме..  |
| Автор: Secandr 7.10.2004, 14:53 |
| AntonSaburov А у меня большая часть задачь такие, только я привёл самый простой пример разборки логов, а если привести разборку логов комунигейта.... пару сотен строк получится. И ооп там не нужно. Вот вам и пример прекладного программирования без ООП. |
| Автор: maxim1000 7.10.2004, 14:59 | ||
для этого можно дизассемблировать любую программу, написанную с использованием наследования на C++ хорошим примером реализации классов, наследования и пр. без использования специализированных для этого языков может послужить Windows API, в этом случае HANDLE, который очень часто передается в качестве первого параметра, служит некоторым аналогом указателя на объект а пример наследования можно увидеть, если посмотреть на работу с графическими объектами (HBITMAP, HICON, ...) опять же: объектно-ориентированный подход не занимается вопросами того, акк будет реализована работа с классами, он нужен для построения общей схемы программы а в каждом ОО-языке ООП реализуется по-разному: в C++ одним способом, в Java немного другим, в C вообще никак |
| Автор: Sun 7.10.2004, 15:13 |
| ООП хорошо для быстрой разработки проектов. Как правило сроки разработки оказываются более важным фактором чем размер программы или быстродействие. Но там где нужны критические вещи, от ООП как правило отказываются. Ядро операционной системы и драйвера к устройствам пишут на С и ассемблере, чтобы быть поближе к железу и использовать его максимально эффективно. Язык С и ассемблер хороши своей простотой. Для них легко сделать компилятор и размер скомпилированной программы будет значительно меньше и при граммотном написании программа будет работать быстрее. Но они требуют от программиста более высокой квалификации, чем объектные языки, так как они не берут на себя ответственности за действия программиста. Понятно что работать со строками гораздо приятнее в С++ чем в С, но как быть уверенным что строковый класс работает с ними оптимально? И почему их так много всяких разных? |
| Автор: Vit 7.10.2004, 15:38 |
| За ООП двумя руками! |
| Автор: chipset 7.10.2004, 16:03 | ||||
То есть ты считаешь что программер который программирует на Си, гораздо более квалифицированный чем С++'ник ?
В С++ тоже никто на себя отвественность не берёт... |
| Автор: AntonSaburov 7.10.2004, 16:19 | ||
Так я о том же. Область твоего программирования находится в прикладной области легко алгоритмизируемых задач, причем достаточно последовательных (ничего так выразился ).Это не значит, что это легче или не так пристижно. Но просто на каком-то уровне масштаба задачи ООП пока является наиболее приемлемым вариантом и проектирования и программирования. Причем на сегодня для решения масштабных задач используется ООП. НО ! Я на обычном Паскале делал некий аналог ObjectPascal. На Си это тоже можно. Проблема не в компиляторе. Кстати, даже TurboAssembler от Borland тоже имел некие объектные расширения. Меня больше волнует проблема даже больше проектирования. Я уже неоднократно слышал о функциональных языках, к сожалению никакого опыта применения у меня нет. Но идея использования функций вместо объектов явно занятна. Например, при программировании каких-либо учетных систем бывает надо получить курс валют. И сразу возникает вопросы новичка в Delphi "где взять компонент, который умеет это делать". Но ведь на самом деле надо "получить курс валюты", а как это будет реализовано - да по барабану. И объекты тут совсем не причем. Т.е. возможен ли такой путь (который кстати уже имеет место в службах WEB-Service+UDDI) - программа находит не объект, а функцию. И выполняет ее. Несомненно, программа может состоять из объектов, но не для каждой (даже достаточно сложной задачи) уже нужен будет объект. И вполне может быть разработан подход, в котором объекты/классы будут не самым верхним слоем. А будут те же функции. Только на другом уровне - так сказать "в мировом масштабе". |
| Автор: Sun 7.10.2004, 16:27 | ||||||||
Да. Потому что приходиться работать не с объектами, которые могут для тебя являтся просто черными ящиками, а с областями памяти, в которые ты помещаешь свои данные. Что легче написать
или
Берет. Конструкторы и деструкторы для чего придуманы? А обработка исключений? |
| Автор: chipset 7.10.2004, 16:39 | ||
ОНа и в Си есть вроде.. |
| Автор: Sun 7.10.2004, 16:54 | ||||
Нету. Вместо try и catch используется оператор goto |
| Автор: maxim1000 7.10.2004, 17:02 | ||
сразу скажу Perl'а не знаю, но: что такое STDIN? уж не стандартный ли поток ввода? а что это как не объект? пусть реализованный где-то в самом языке для того, чтобы быть объектом, совсем необязательно использовать слово class... |
| Автор: AntonSaburov 7.10.2004, 17:02 | ||
Исходя из такой логики на JAVA писать еще проще и не требуется хорошей подготовки Тут и уничтожать ничего не надо. Помню пришла к нам тетенька из какого-то НИИ. Мы ей показываем стенд, как мы для него программу на Паскале пишем с новым алгоритмом (добавляем), как собираем, как запускаем и все на экране красиво. А она на нас смотрит и говорит: "А в кодах что я должна набирать ?". Она, оказывается, все в кодах набирала. Знала наизусть несколько десятков команд. И программку для записи байта в порт и оттуда она напишет быстрее меня. Но зато систему, которая будет обслуживать все датчики, следить за их состоянием и в нужное время напоминать обо всех проблемах она написать не сможет. И не потому что глупее - просто уровень задач (даже лучше слой) задач - другой. Не хуже и не лучше. Просто другой. Я когда на JAVA переходил - полгода привыкал, что удалять указатели не надо Добавлено @ 17:08 Многие из нас - уже достаточно сложившиеся профи, которые решают определенные задачи с использованием той или иной технологии. На сегодня IMHO наиболее масштабируемая - ООП. Только опять я не принижаю роль других техник. Я делаю сравнение типа - печь, баня, сарай, дом, аэропорт. Печь тоже надо уметь делать, но техника для нее не подходит для аэропорта. Тоже самое и тут - лучше ООП для огромных систем пока ничего нет. А у меня есть ощущение, что уже наступает момент, когда системы уже перерастают и этот уровень. От аэропорта пришли к Международной Космической станции. Тут ООП уже не спасает. Или все таки спасает ? И вообще есть ли задачи, которые мы пока решить не можем не одной из перечисленных техник ? |
| Автор: Secandr 7.10.2004, 17:10 |
| maxim1000 А это стандартные вещи для юникса, там даже ком порт работает как стандартный файл А я перл уважаю - быстро и сердито, всегда под рукой. |
| Автор: maxim1000 7.10.2004, 17:14 | ||
ну это и для Windows так только я хотел сказать другое: все порты, все потоки ввода/вывода, да и обычные дисковые файлы представлены уже в самой системе в виде "логических" файлов разве это не наследование в чистом виде? кроме того, когда программист читает из потока, он не задумывается о том, как ОС будет это делать - тоже сильно смахивает на ООП |
| Автор: Sun 7.10.2004, 17:15 | ||
На Java однозначно проще писать чем на С. Для решения одной и той же задачи на С и Java, в первом случае потребуется более квалифицированный специалист. Когда я пишу программу на С, то приходится прилагать значительно больше усилий чем на Java. |
| Автор: AntonSaburov 7.10.2004, 17:25 | ||
Так в том то и дело, что задачи ДОЛЖНЫ быть разные. Нефиг на JAVA писать то, что хорошо ложиться на С. And vice-versa. Просто если я не думаю над одной проблемой я могу решать другую. И чем более подходящие у меня блоки для данных решений, тем быстрее я решу задачу. Вот я и раскручиваю всех на то, чтобы подумать над тем, есть ли блоки еще более крупные чем объекты |
| Автор: chipset 7.10.2004, 17:49 | ||
В Win32 можно использовать __try,__except Братцы! Да ведь оказывается на QBasic программер квалифицированней чем Жабист  |
| Автор: Domestic Cat 7.10.2004, 17:51 | ||
Ты эта ... смотри ... |
| Автор: Sun 7.10.2004, 18:02 | ||||||
В Windows все не как у людей В стандартном С обработки исключений нет. Вот тебе пример кода их Linux kernel, где вместо try catch используется goto
|
| Автор: chipset 7.10.2004, 18:13 | ||||
 Добавлено @ 18:14
Бедные линуксоиды... |
| Автор: LSD 7.10.2004, 19:24 | ||||
На самом деле есть и даже большой
Не функции вместо объектов, а описание задачи вместо, описания алгоритма ее решения. |
| Автор: Medved 7.10.2004, 22:27 |
| Вот мое мнение по этому поводу, лучше Джоэла я все равно не скажу, потому читайте лучше оригинал: http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html |
| Автор: AntonSaburov 8.10.2004, 14:25 | ||||
Да, именно это я имел в виду
Ну я бы не стал столь категорично. Огромное количество людей пишут на HTML, JAVA, JavaScript и даже не думают о том, что лежит под ними. И это в какой-то степени правильно. Разделение труда - специализация. Опять же возвращаясь к "слойности" задач. Может будет такой момент, когда программисты будут делиться и на категории задач, а не только на языки программирования. Понятно, что для написание крупных систем надо понимать СУБД, HTTP, какой-нибудь язык программирования и возможно ее что-то. И конечно профи высокого уровня, которые работали на всех "слоях" будут цениться выше, чем другие. Но это было всегда и не только в IT области. |
| Автор: Secandr 8.10.2004, 17:51 |
| maxim1000 Смахивает, но не ооп |
| Автор: Medved 8.10.2004, 23:00 |
| Интересная постановка вопроса. ИМХО она немного некоректна. Все равно что сказать, вы за электричество или против. Конечно же ЗА. Ибо любой маломальский программист, который имеет хоть какой-нибудь опыт написания приложений (можно читать как кода), со временем понимает, что ООП - это более прередовой метод программирования, который позволяет экономить время и не распылять силы. А кроме того и многое другое. Вспомните определение понятий трех китов ООП - инкапсуляция, полиморфизм, и наследование. Вспомните. Вот здесь... И теперь вы сразу согласитесь со мной. А если не согласитесь, то вспомните еще раз, и так до тех пор, пока не согласитесь. Да даже если лично по себе судить, я помню, что когда еще только начитал программировать я не использовал приемы и идеологию ООП, поскольку не доконца ее понимал и у меня было мало знаний и опыта. Но постепенно, программируя все больше и больше, набираясь этой драгоценности (опыта), я начал вводить в свои программы эти элементы. Постепенно я стал писать свои объекты и даже библиотеки классов. Потому как начал понимать, что незачем делать двойную работу, или тратить время попусту, часами исправляя свой код, только потому что заказчик захотел сделать одно маленькое дополнение или я где-то что-то упустил. Теперь, я не представляю как бы я сопровождал свои программы, если бы они не были написаны как можно ближе к пардиаграмме ООП. Это же сколько времени и сил надо, чтобы написать даже маломальское приложение (да пусть тот же простейший текстовой редактор), процедурным, не говоря уже о линейном, методом программирования. И насколько я знаю, более передового метода чем ООП пока еще не придумано. Или я ошибаюсь? Вроде как нет.... А вот этой статьей (http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html) я хотел сказать то, что не надо забывать и о том, что же лежит в черных ящиках - объектах. |
| Автор: Secandr 9.10.2004, 09:16 |
| Полностью согласен. Я привёл примеры программирования, где нет смысла применять ооп. ООП - мощный метод, но нельзя говорить что он единственный. |
| Автор: Kurt 15.10.2004, 00:49 |
| Сейчас меня будут бить.. Господа, я против ООП. Но позвольте сперва объясниться.. Как и любой нормальный программер, я считаю ООП существенно экономит время, это понятнее для человека, что позволяет создавать все более сложные системы. Да, это все замечательно. Но! ИМХО, в ООП есть очень опасная вещь - черный ящик. Работая с объектом не обязательно знать как он устроен. Теперь смотрите: появляется поколение программистов, взращенных на этой идеалогии - они используют готовые решения или создают свои классы на основе СУЩЕСТВУЮЩИХ. Мы все дальше и дальше уходим от железа - допустим, в моем городе куча спецов на Delphi, но почти никого на ASM'e - народ не знает и НЕ хочет знать как все это устроено! Понимающих во "внутренностях" компьютера становится все меньше (во всяком случае, большинство университетов выпускают в основном высокоуровневых специалистов). Итого - вся мощь ООП и вообще все программирование держится на кучке "низкоуровневых фанатиков". Скоро все забудут про указатели и ручное очищение памяти. Действительно, зачем об этом думать, если уже все решено за нас? Однако, представьте, что придет нужда сделать исправления на самом низком уровне. Надо, а некому! Поэтому, я считаю, что упование на ООП ведет к краху IT-индустрии, т.к. подрывается ее фундамент. Ессно, ООП нужно использовать, но не стоит забывать об истоках. Во всяком случае, до тех пор, пока процессоры, установленные у нас на компах, не начнут понимать что-то типа Java или С++. З.Ы. Повторюсь, это всего лишь ИМХО. Мое ЛИЧНОЕ мнение. |
| Автор: Sun 15.10.2004, 10:36 |
| Kurt, полностью согласен. Мне тоже осточертели программисты, которые не знают элементарных вещей и что интересно, не стремящихся их узнать. Изучение программирования уже начинается не с битов и байтов и устройства процессора, а с драг-энд-дропа. |
| Автор: chipset 15.10.2004, 10:45 | ||
В общем то да, C#/VB дали этому делу ход. А проблема в том что работодателю как мне кажется (а на самом деле хз) по**** на это. А начинать нужно не с этого, а с алгоритмов  |
| Автор: maxim1000 15.10.2004, 10:45 | ||
а может, нужны и такие программисты?
ну не такая уж и кучка думаю, над созданием компиляторов работает куча людей (а не кучка )кроме того, я продолжаю настаивать на том, чтобы разделить ООП как способ программирования и ООП как способ мышления при разработке ПО |
| Автор: chipset 15.10.2004, 10:47 | ||
Спрашиваю: кому нужен АСМ в твоём городе? Что на нём кроме драйверов можно эффективно программировать? К сожалению программисты немного потеряли ореол таинственности, хакеризма и.т.д... |
| Автор: maxim1000 15.10.2004, 10:48 |
| просто разработка ПО стала такой большой областью, что охватить ее одному человеку все сложнее и сложнее поэтому разделение людей по уровням будет все сильнее и стльнее |
| Автор: chipset 15.10.2004, 10:52 |
| Моё ИМХО: всё то что только что сказал Sun изучают школьники которым старший брат показал как кнопочки рисовать в VB в своё удовольствие. Добавлено @ 10:52 И считают себя при этом суперпупер прогерами.. |
| Автор: gray_k 15.10.2004, 10:55 | ||
Kurt
Извини, но ты чушь сказал. А кто по твоему разрабатывает компиляторы, среды разработки и исполнения программ? "низкоуровневые фанатики"? Просто есть рынок труда. Если большинство современных пректов дешевле разрабатывать с применением ООП, то оно и будет работать. А низкоуровневое программирование никуда не денется, просто оно занимает свою нишу и всё. Мне вот интересно что ты со знанием ASM собрался исправлять, например в модуле R/3 или Axata? А мощь ООП на специалистах по разработке концепций и аналитиках. Что ни говори, а низкоуровневый программист всегда останется всего лишь исполнителем, причём самого низшего звена. Основы конечно ИТ-специалисту необходимы, но между основами и разработкой огромная пропасть. И не надо путать эти понятия. |
| Автор: Sun 15.10.2004, 12:38 | ||
Хороший архитектор для начала должен поработать простым строителем. Нельзя бесконечно абстрагироваться от реальности, иначе рискуешь построить прекрасное здание, которое рухнет в самый неподходящий момент. И нужно знать далеко не только основы, а нужно иметь четкое представление как все работает на низком уровне. |
| Автор: gray_k 15.10.2004, 13:23 | ||
Хороший пример того, что анологии фальшивы. Архитектор отнюдь не должен работать строителем, так же как и инженер не должен работать техником, для того чтобы быть хорошим специалистом. |
| Автор: chipset 15.10.2004, 13:27 | ||
Кстати в Microsoft, архитекторы кодят простые задачи несколько раз в неделю - чтоб не расслаблялись и не теряли чутья..  |
| Автор: Sun 15.10.2004, 13:37 | ||||
У нас разное понимание "хорошего специалиста" |
| Автор: Kurt 15.10.2004, 20:39 | ||
Угу. Вот смотри.. Пройдемся по ВУЗам нашей распрекрасной страны.. Посчитай, чему больше учат? Кого готовят? Спецов по бизнес приложениям или по железу и низкоуровнему программированию? В каких пропорциях? Почему? Прааально - рынок труда. Всем нужны программеры "плюх энд плюй"! Мы приходим к тому, что выросло поколение "программистов", к-е даже командной строкой не умеет пользоваться! А что дальше? ИМХО, происходит деградация и хороших спецов найти все труднее, т.к. мы забывам основы. |
| Автор: Medved 16.10.2004, 07:46 |
| Если бы не ООП, мы наверное до сих пор бы сидели в досовском интерфейсе. И ООП никак не крах ИТ индустрии. Просто надо грамотно разделять труд. |
| Автор: shedon 26.10.2004, 07:46 | ||
Я на это гляжу с такой точки зрения есть С(не поддерживает ООП) и С++(поддерживает ООП). Сейчас я в основном занимаюся программированием микроконтроллеров и ест. не о каком с++, тут и речи идти неможет, и так всё тормозит, а если там ещё и классы делать, то программак вместо 50кб будет занимать 400 кб, где я столько памяти возьму ? Тоже с драйверами... Да и винду с линухой на чистом си не спроста написали, так, чо всё зависит от конкретных обстоятельств, конечно ООП упрощает поддержку кода, увиличивает его "читаемость" и переносимость, но не везде оно применимо. А то что тут говорят, типа люди асм забывать стали и от истоков отбились, то потребность в системщиках и низкоуровневых программистах будет всегда, только стоить они будут дороже, что не так уж и плохо |
| Автор: Jey_k 26.10.2004, 10:09 | ||||
Винды 95,98 писали на Кобол+С, дальше не знаю
Да вних потребность и сейчс дикая, ДРОВА нужны однако |
| Автор: Alex101 26.10.2004, 10:53 | ||
А надо ли ему ей пользоваться, если он пишет программу складского учета, работающую под виндами, а не компилятор? И кто быстрее эту программу напишет, ассемблерщик или плюх энд плюйщик, учитывая, что последний знает, какие процессы происходят на складе? |
| Автор: chipset 26.10.2004, 12:14 | ||||
Как это? А разве не на С++?  Возможно ядро, но я своими глазами где то читал что мол ".. с приходом ООП стало легко делать масштабные проекты, как например и сделали в Win95... "
  |
| Автор: shedon 26.10.2004, 12:58 | ||
Нет на чистом си, сам видел |
| Автор: Jey_k 26.10.2004, 21:57 | ||
Согласен. Нельзя же на асме писать проги для работы с БД или на дельфях дрова ваять, хотя слышал что это возможно. |
| Автор: shedon 26.10.2004, 22:03 |
| Да дрова на асме сейчас тоже уже мало кто пишет, пишут на си(без плюсов), хотя некоторые "особо продвинутые" их визардами лепят. |
| Автор: Sardar 26.10.2004, 22:15 |
| Да и компиляторы тоже не на асме пишут Что бы строить таблицы решений, нужно знание машины, опкодов. Но это лишь небольшая часть компилятора, который например может гнерить код под разные процессоры и ОС. |
| Автор: bel_nikita 20.11.2004, 23:21 | ||
|
| Автор: Anklav 27.11.2004, 03:08 | ||||||
А я где-то читал, что винды писали в основном на асме |
| Автор: simanyay 27.11.2004, 18:31 | ||
LOL Кто-то над тобой нехило подшутил |
| Автор: chipset 27.11.2004, 19:05 |
| Небольшой юморной оффтопик: .NET Driver Development Kit |
| Автор: simanyay 27.11.2004, 21:20 | ||
Мне тут один знакомый сказал, что будет писать кроссплатформенную файловую систему на C# |
| Автор: Sardar 27.11.2004, 23:25 | ||
Ну не знаю как вы тогда к этому отнесётесь: http://www.cs.utah.edu/flux/janos/ Операционная система на Java, причём это уже вторая которую встречаю. |
| Автор: Cheba 28.11.2004, 14:03 | ||
Это все из-за лени. Ну, покажите мне человека (или Microsoft ), который решился бы все с самого начала переписать на С++. Хотя как посмотрю на дату выхода Longhorn'а, так закрадывается подозрение, что все же нашелся такой...А Linux все же частично на С++ написан. |
| Автор: simanyay 28.11.2004, 15:02 | ||
Так, ИМХО, OSKit не на Java же написан? Или я чего не понял... |
| Автор: shedon 29.11.2004, 12:47 | ||||
Вот что написанно в Unreliable Guide To Hacking The Linux Kernel
|
| Автор: Конструктор 13.2.2005, 23:39 |
| Хм, относительно Java, читал про такой процессор PicoJava II от Sun, он вроде Java байт-код аппаратно умеет обрабатывать, на каком то уровне. Да и влюбом случае хоть какая-то часть ОС пишется на асме, хотябы чтобы загрузиться, включить режимы процессора необходимые, память выстроить, всякие дескрипторы настроить и т.п. А как будет выстроено оокружение необходимое для работы более выского языка, вот тогда и в путь. А вот насчет того что винда но Коболе написана, это да... |
| Автор: AntonSaburov 14.2.2005, 19:12 | ||
Это не процессор - это спецфикация процессора. Хотя насколько мне известно даже есть реальные продукты. Но что-то не уживается он в мире. Спроса нет. |
| Автор: Конструктор 14.2.2005, 20:29 | ||
picoJava это скорее и процессор и спецификация
|
| Автор: xnordx 27.2.2005, 20:19 |
| А вообще какой язык лучше? И что лучше из этих двух языков Delphi или Builder точнее какой из неих более распространенней и по возможнастям обширнее? |
| Автор: Domestic Cat 27.2.2005, 23:51 | ||
Самый распространенный язык - Виндовс. Или Спектрум, не помню... |
| Автор: oleg1973 28.2.2005, 00:34 |
| Domestic Cat спектрум эт святоена нем виндос написан |
| Автор: SoWa 28.2.2005, 08:59 |
| М-да! Точно война! Я тоже за объектно-ориентированные языки, но выбор еще и от задачи зависит! В Дельфи мне без ООП не обойтись, а в Перле или Си - зачем ООП надо(если задача системная)? |
| Автор: Конструктор 28.2.2005, 20:25 |
| oleg1973, да ты чего, там же видно что Windows написан на DLL++ и Object EXE. Там еще какие то мелкие скрипты, типа Visual INI и INF - enterprise architect применяются иногда. |
| Автор: Domestic Cat 28.2.2005, 20:32 |
| A DLL++ и ActiveХХХ написаны на Ворде. А Ворд сам писался на Спектрум ZX80. А Спектрум писали на перфокартах, перфолентах и перфораторах. А их составляли из картонок и дырочек. |
| Автор: chipset 28.2.2005, 21:01 | ||
| Блин друзья, чё за бред вы тут втираете начинающим чайникам? Виндовс была написана на Нортон Командере! А Нортон Командер на Поиске! Добавлено @ 21:02
Нету языка DLL++. Есть язык DLL#. Который в свою очередь является частным случаем dotJava написанного на ZX-80. |
| Автор: oleg1973 1.3.2005, 03:50 |
| полный гон! как шас помню, z80 переродился в Amiga и там появился Rexx и на нем написали OS/2 ну а потом и винду! |
| Автор: Medved 1.3.2005, 04:29 | ||
Ну и? Типа если задача системная, значит ООП нафиг не нужно? Блин, Вот это мысль! |
| Автор: En_t_end 1.3.2005, 05:50 | ||
Ды вы чего это... совсем историю забыли, а ведь её уважать надо. Виндовс написана на языке одного племени ТУМБА-ЮМБА, хотя и сотрудникам майкосфта пришлось чуть чуть изменить язык, но в целом виндовс благодаря ему получила целый ряд фич : 1. тормознутость...2. ограниченность...3. тупость...4. глючность...5. матерки типа abort, retry e.t.c... |
| Автор: xnordx 1.3.2005, 10:07 |
| А что за язык Ассемблер? |
| Автор: oleg1973 1.3.2005, 11:26 |
| xnordx это такой язык на который переходят те кому важен размер/скорость/безглючность программы ))а любители "накидать компонентов на форму" его боятся и не понимают |
| Автор: LSD 1.3.2005, 23:40 | ||
|
| Автор: Medved 2.3.2005, 00:12 | ||
мммм. да... |
| Автор: oleg1973 2.3.2005, 12:34 |
| LSD Pegas ламеры на асме не пишут )))от этого и безглючность |
| Автор: Конструктор 2.3.2005, 23:57 | ||
Боятся и уважают! Visual Asm кстати видели? Там вроде тоже можно накидать  |
| Автор: oleg1973 3.3.2005, 00:20 |
| Конструктор там можно тока диалог нарисовать и в файл ресурсов его скомпилить |
| Автор: Exception 4.4.2005, 15:43 | ||
Язык dotJava является частью системы dotInternet. Между прочим, dotInternet был написан корпорацией Monsters, Inc. во главе с chipset. |
| Автор: Chingachguk 23.4.2005, 07:25 |
| AntonSaburov Собственно, по поводу темы. Мой взгляд на это, как и, полагаю, твой отличается отсутствием серьезного опыта в области "поля действия" оппонента. Если ты, вероятно, большую часть своих программ написал на HLL и использовал ООП, то я же такого опыта не имею. Поэтому аргументы вида "даже на обычном C будет сложно контролировать программу более 500 строк" для меня "не звучат", ибо я писал программы на асме или его комбинациях с HLL общим объемом 5-10 тыс. строк, даже бд мелкие ;) Однако перейдем к делу. Является ли программирование наукой и, если да, то какого рода и какая роль ООП в ней ? Наука в общих чертах может развиваться в двух вариантах: фундаментальном и феменологическом (экспериментальном). В последнем случае нет базовой теории, есть только набор опытов, из которых, например, может следовать определенный ряд выводов типа "сложность понимания программы прямо пропорцилнальна количеству строк кода в программе" и т.п. Вообще программирование - зыбкая вещь в смысле оценок, так как критерием служат субъективно-косвенные данные типа личного мнения выборки программистов или итоги соревнования на самую быструю программу поклонников различных видов языков. Поэтому я склонен оценивать программирование - по крайней мере ту его часть, которой занимается большинство из нас - а это коммерческое ПО и в малой доле математические расчеты (ВУЗы и т.п.) именно как чистую феменологию. ООП в этом свете - некая абстракция, полутеория-полумодель, которая, возможно, по замыслу ее создателей и поклонников, должна была обобщить некие знания в кодировании и дать некие положительные следствия. Что является одним из базисов этой модели ? А им является восприятие человеком - программистом - задачи, которую он должен реализовать при помощи двоичной логики. Это очень интересный момент - в основную задачу включается легкость написания кода, что не может не вызвать недоумение у, скажем, приемной комисси какого-нибудь космического проекта когда они видят перед собой разработчиков программы для бортового компьютера, которая по тестам показала время отклика в 1 час вместо 1 минуты, но писать код им было удобно. В эту теорию также включены элементы маркетинга, пусть и неявно. Кого еще кроме менеджера может интересовать скорость разработки ? Вы видели где-нибудь в классической науке такой фактор как скорость создания теории ? Но таков мир, и программер вынужден сегодня учитывать и этот фактор. Однако всякая приличная теория должна не только объяснять существующие эксперименты, но и предсказывать новые опыты. Если теория предсказывает, что сортировка пузырьком ~N^2, то всякий программер может лично в этом убедиться. Были ли проведены серьезные исследования качества продуктов с применением ООП / в сравнении с другими продуктами ? Вряд ли, по большей части это всего лишь один из вариантов реализации перед современным менеджером проекта. Кто-то успешно применял его, кто-то - нет. Описывает ли ООП существующие задачи ? Возможно, в БД у нее это неплохо получается. Однако что касается системного программирования (например), то, по моему скромному мнению, она плывет, как, впрочем, и почти любой HLL. Но объективна ли моя последняя претензия к ООП ? Да, ведь нигде в ее постулатах не сказано, что "лучше всего на ООП писать текстовые редакторы". Т.е. я делаю допущение, что эта "теория" была разработана узкими специалистами - скорее всего в области БД (клиентского скорее) или интерфейсных диалогов, не имеющих опыта в системном программировании или, скажем, в области разработки ОС или нейросетей. Но вышеупомянутая область - это все равно серьезный кусок рынка, так что если бы тут появилось "великое обобщение", то это было бы также очень здорово. Однако даже если принять, что последнее верно (тут по причине вышеупомянутой субъективности оценок в современном программировании спорить не буду), напоследок отмечу вот что: - ООП является "инструментом не для всех". Если Вы не умеете им пользоваться, скорее всего Вы напишите отстой, лучшие результаты будут показаны при процедурном подходе (в среднем); - ООП не несет в своих постулатах стимула к развитию понимания процесса, созданию новых понятий; наоборот, она "инкапсулирует" в себе свойства объектов, тем самым сильно сужая поле для анализа программистом ситуации (все равно, что вместо детальных папиллярных линий криминалист имел дело с объектом "Нога.отпечаток пальца"). |
| Автор: Domestic Cat 23.4.2005, 07:50 | ||||||||
Довольно небольшие программы.
Странное утверждение. Когда врач тебе деклает операцию, ему необязательно знать как, из какого материала и кем был изготовлен его скальпель или кто изобрел лазер. Мне все равно, как устроен телевизор, и тебе по барабану, как был произведен сахар в твоей сахарнице. Мы используем эти продукты/вещи/ итп, вот и все. Понятие инкапсуляции непосредственно вытекает из жизненного опыта. И это ни в коей мере ничего не сужает. Врачу не пристало чинить лазер, также как и техник не сделает в жизни ни одной операции. Видимо, ты также не имеешь опыта в ООП и потому однобоко смотришь на вещи.
Что-то ты выдумываешь, для начала неплохо бы историю изучить. Не обижайся.
Интересно, зачем тогда на марсоходах пользовали Java3D? |
| Автор: Chingachguk 23.4.2005, 08:28 | ||||||||||||||||
Хм. Ты писал (а не сопровождал/работал в группе) б'ольшие ? И я же не говорил, что писал только одну такую.
А мне - нет. Я даже немного знаю, как - например, что такое p-n-p переход ;)
В том-то и дело, что нет. Я (хоть и ненавижу ООП), не поленился и прочел пару книжек по нему и попытался понять.
Вот такие вот "доказательства" у объективности ООП. Только ОПЫТ - критерий истины.
Зачем повторять мои же слова - тем более что я вынес их в начало своего поста:
Я не говорил, что это так - я сказал, что делаю допущение.
Да ? Интересно ! А использовали ли там объектный подход (ведь и средствами ООП можно писать в "процедурном" стиле, используя дополнительно такие приемущества как сборщик мусора и т.п.) ? |
| Автор: Domestic Cat 23.4.2005, 08:45 | ||||||
Писал. Но мы же не обо мне говорим. Сейчас программа на миллион строк на ООЯ не редкость.
Еспи пишут на ООЯ, то пишут ОО программы. Сборка мусора в Java есть всегда. А вообще то я тебя не понимаю. "Ненавидеть ООП" - этоо все равно что ненавидеть ножик или пишущую машинку. Это инструмент, очень удобный и очень полезный, на котором сейчас написано громадное коичество приложений. Растет скорость компов, становится менее критичным на чем писать.
Ну пускай опыт, я не буду спорить. Я начинал (как и все тут) писать на процедурных языках, и переход на ООП мне например намного облегчил жизнь. И я никому это доказывать не хочу, ругаться или перетягивать тебя просто времени жалко ЗЫ. Обычно ненавидят новое по нескольким причинам, например, человек считает себя специалистом в одной области, тогда как в новой нужно начинать с нуля. Тогда и возникает ответная реакция - непринятие нового. Это я так, к слову. |
| Автор: Chingachguk 23.4.2005, 17:54 | ||||||||||||
Можно пример ? Именно на миллион, ну хотя бы на 500 000. А еще лучше примера 3-4.
Я видел и обратное, поэтому - это личное мнение или на JAVA/C++ нельзя писать в процедурном стиле ?
Миллоны (здесь именно миллионы) людей в ссср ненавидели бутсы фирмы "Скороход". Это естественная реакция потребителя, который хочет знать, почему он должен что-то покупать.
Опять голословное утверждение. Кому-то удобный. Это субъективное мнение. См. мой пост (про скорость методов сортировки).
Не такое уж громадное. Скажем, в свое время на win 3.11 было ну просто громадное число пользователей. И где они сейчас ? Это относительно, нужны хотя бы сравнительные характеристики.
Отлично, вот ты написал, что начинал на HLL, потом перешел на удобный для тебя ООП. А что еще нового ты изучил кроме ООП - альтернативного, может, есть еще более продвинутые вещи ? PS Вообще-то насчет траты времени ты прав. Пока не было никаких критических замечаний к мыслям, которые я старался высказать в самом начале - лишь обмен аксиомами. |
| Автор: Domestic Cat 23.4.2005, 18:33 |
| Я спорить не буду, времени нет на это |
| Автор: chipset 23.4.2005, 18:55 | ||||||||
| А что тут спорить? ООП как парадигма гораздо удобнее для программиста, поскольку он живой человек а не робот. Конечно, на маленьких проектах это может не проявляться (1,000-15,000 строк), но писать, скажему, ERP систему процедурщиной это извращение чистой воды.. С тем же успехом её можно писать и на асме, мне кажется. Даже с применением ООП не так то легко разбираться, если бы это было процедурное программирование наверное вешаться можно было бы сразу. Ты спроси Вита или кого-нибудь, кто разрабатывает большие программы - какой гемморой был бы если бы всё разрабатывалось без ООП? А UML как-же, блин? Честно скажу, лень спорить, не хочешь писать - не пиши, только вот, я уверен, что большинство команд занимающихся написанием нормального софта будут требовать оопный стиль. Добавлено @ 18:57
Не кому-то, а большинству программистов пищущих средние и большие программы.
Да возьми любую ERP систему или среднюю десктопную программу. Добавлено @ 18:59
Руки главное шоб не кривые были, всё остальное приложится.
ЛОЛ Делать формы на асме, это уже сродни каким-то высшим степеням мазохизма.. |
| Автор: Chingachguk 23.4.2005, 22:59 |
| Согласен, спорить таким образом - зря время терять. Написал ответ но решил кильнуть его - кому интересно, в аттаче. |
| Автор: Дрон 24.4.2005, 00:31 |
| Chingachguk Так ответ твой был по делу Хотя споры -- это, конечно, вещь бесполезная. |
| Автор: Дрон 24.4.2005, 00:54 | ||
| Вот какая у меня мысль промелькнула по поводу сравнения ООП и процедурного программирования. Основным плюсом ОО считается быстрота написания и совершенствования программ. Но ведь если брать ОО подход в чистом виде, то мы сталкиваемся с ужасающей избыточностью программ. Да и вообще соблюдение всех правил ООП сильно уменьшает эффективность программ. Как-то раз меня в воскресенье вызвали на работу, т.к. срочно надо было исправить пару глюков. Приезжаю я. Читаю письмо от чела, исправляю... И тут вижу последним пунктом в списке багов написано, что вот невозможно узнать состояние одного объекта из другого, так как переменная, отвечающая за состояние, объявлена private. Изменять же класс, написанный мной, он не стал. А теперь скажите, что я должен был делать в этом случае? Заранее предусмотреть все возможности нельзя. Я не думал, что состояние может понадобиться снаружи и поэтому сделал его недоступным, как и положено. Можно сказать, что во избежание таких ситуаций нужно писать геттеры для свойств объекта. Но это же трата времени. Написание кучи функций такого вида:
это очень интересное и полезное занятие. И так в каждом серьёзном классе у меня таких функций штук пять, так ещё и я должен предусмотреть, что в будущем может быть когда-нибудь понадобится ещё к какому-нибудь члену получить доступ. А ведь такие функции ещё и производительность снижают и размер кода увеличивают. Но зато ООП. До кучи ещё можно сказать, что почему это состояние у меня типа int, ведь нужно же отдельный enum или класс сделать Так вот сижу я в воскресенье вечером в пустынном офисе и улыбаясь, заменяю private на public без каких-либо душевных мук. Хрен с ним с этим ООП. |
| Автор: Domestic Cat 24.4.2005, 01:55 |
| Дрон. Во-первых ИДЕ могут генерить подобные вещи за долю секунды, правда речь не о студии. Во-вторых, проперти/геттер/сеттер и вообще метод произвйдительность снижает настолько, что если бы не снижал, это бы ни на что не повлияло. В-третьих, преимущество ООП состоит в переиспользовании кода, в инкапсуляции, гораздо меньшем времени затраченном на дебаггинг, удобочитаемости кода, и т п. Для того, чтобы это понять, нужно читать хорошие книжки и писать код. В какой-то момент начинаешь понимать, что ты пишешь правильный код. А так все рассуждения здесь больно смешно (для меня) звучат |
| Автор: Дрон 24.4.2005, 03:10 | ||||
Domestic Cat
Я старался Не собирался же я тут разбивать в пух и прах идеи ООП. Я просто привёл пример того, что ООП не идеально. Мне оно одновременно и нравится, и не нравится. Наследование и полиморфизм это круто, но зато инкапсуляция -- фигня.
По порядку: Возможность переиспользования кода требует зарание предусмотреть все варианты использования объекта. А это, согласись, довольно трудоёмкий процесс. Инкапсуляция. Да, она снижает вероятность появления багов, особенно, когда код пишут несколько человек. Но ведь и создаёт сложности. Когда нет возможности забраться внутрь, то приходится иногда такие извращения придумывать, чтобы получить нужный результат. Дебаггинг. Сложно сказать. У меня большинство багов не зависят от структуры. А вот идти step-by-step, когда у тебя на одну строку штук пять геттеров вызывается, действительно неприятно. Удобочитаемость. Тут сложно оспорить. Когда привык к объектам, то действительно всё легко и красиво. Но ведь если тебя заставить пару лет писать в обратной польской нотации, ты бы к ней тоже привык В общем ООП облегчает жизнь, если на нём не зацикливаться |
| Автор: Chingachguk 24.4.2005, 12:59 | ||||
На серьезные аргументы (сравнение с другими подходами) времени нет, а на подколки есть ? ;) ok. А для меня прикольно глядеть на мастодонтообразный код (исполняемый), полученный от ООП. Инженера интела старались, проц разогнали в десятки раз, а вы его тормознули - видимо, чтобы пользователю было привычнее работать в черепашных прогах.
Респект! Никто не говорил, что ООП - отстой. Просто все в конце концов совершенствуется путем обобщения прошлого опыта. И (имхо) возможны и другие варианты. |
| Автор: Domestic Cat 25.4.2005, 21:40 | ||
На серьезные ответы уйма времени уходит |
| Автор: chipset 27.4.2005, 00:45 |
| Народ. А кто вообще пораспускал мифы что C++ медленее Си? Убейте - не пойму, чего там медленного... |
| Автор: Domestic Cat 27.4.2005, 00:49 |
| Ну вообще-то медленнее, например методы нужно уже связывать динамически а не статически, что снижает скорость. |
| Автор: Ch0bits 28.4.2005, 19:58 |
| BIG OffTopic: Сегодня страшный(а может великий) день в моей жизни! Так сложилась судьба(звёзды, карма), что Я СТАЛ ДЕЛЬФИЙЦЕМ!     Больше я не буду хаять Дельфи(ну разве что язык), буду материть .Net! Товарищи дельфийцы, встречайте попонение в своих рядах, я пришёл! УРА! УРА! УРА! Теперь могу заявить: Delphi будет жить! Мы ещё второй большой взрыв переживём! Для меня на свете есть только 2 языка: Delphi & Java! |
| Автор: Kurt 29.4.2005, 22:25 | ||
| Ни разу в жизни не видел программера, к-й бы сказал "Сегодня я стал Дельфийцем, Java-истом, дотНЕТовцом" (нужное подчеркнуть). Не удержусь спросить, как можно так определиться за один день? 
а вот этого не советую. |
| Автор: Ch0bits 29.4.2005, 22:31 | ||||
Да нее... я буду криптованый мат юзать. ШюТкА!
Народная мудрость: старику где тепло там и родина. Теперь угадай как? |
| Автор: Jey_k 2.5.2005, 20:31 |
| Vadim999 Ну собственно правильный выбор. Поздравляю!!!  |
| Автор: chipset 3.5.2005, 12:01 |
| Ужоснах. |
| Автор: simanyay 3.5.2005, 14:38 |
| Кошмар |
| Автор: Ch0bits 3.5.2005, 14:47 |
| Сгинь-сгинь нечистый... чур меня... |
| Автор: Domestic Cat 3.5.2005, 17:46 |
| Ужос!!! |
| Автор: Ch0bits 3.5.2005, 22:02 |
кОшМаР!  PS: Это вы все про Яву что-ли??? |
| Автор: simanyay 4.5.2005, 13:33 | ||
Ага, про мотоцикл |
| Автор: Ch0bits 4.5.2005, 17:09 |
| А я думал мы тут DLL++ обсуждаем??? |
| Автор: Jey_k 5.5.2005, 10:33 |
| Аминь! Фортран рулит! Вместе с Коболом |
| Автор: GrayCardinal 7.5.2005, 13:38 |
| [прикуривая] ООП, ООП, PERL - это круто ... |
| Автор: chipset 7.5.2005, 15:39 |
| Эх вы.. Обьектно-ориентированное, процедурное программирование... фигня! Настоящие пацаны программируют на Чиста Конкретно Ориентированном программировании, внатуре! |
| Автор: GrayCardinal 11.5.2005, 09:01 |
| chipset однозначно Не, правда, после того как попользуешь Perl просто забывавешь что когда-то ... работал ... с C++ |
| Автор: Hidrag 13.1.2007, 23:49 |
| что то про эту войну забыли совсем |
| Автор: Beltar 18.1.2007, 13:36 | ||||
| Вытащили тему, АднАкА. Тоже что-ль написать что-нибудь.
По-моему это неправильное проектирование. Хотя мне тоже приходилось сталкиваться с такими за**ми, как масса геттеров и сеттеров. У меня есть пара компонентов для Delphi, один содержит внутри себя форму, а второй поток TThread. И некоторые свойства этих вложенных классов доступные и для каждого надо было писать функцию.
Загрузку камня отслеживать будем? |
| Автор: Real 31.12.2007, 15:34 |
| С# - 100% OPP |
| Автор: JackYF 31.12.2007, 16:26 | ||
OPP - это что? |
| Автор: Void 31.12.2007, 20:12 |
| Ахтунг, в новогоднюю ночь по Винграду ходит маньяк-некрофил! Он вытащил уже пять забытых холиваров. Кто следующая жертва? Следите за развитием событий! Real, в самом деле, что нашло-то на тебя такие темы поднимать? |
| Автор: JackYF 31.12.2007, 20:16 | ||
 |
| Автор: Mayk 31.12.2007, 20:20 | ||
Это признак того что кто-то уже прадзнует новый год. Так. у меня 40 минут до НГ. КАКОГО ЙА В ОНЛАЙНЕ? ФХТАГН |
| Автор: JackYF 31.12.2007, 20:34 | ||
Проснулся? |
| Автор: MAKCim 31.12.2007, 21:05 |
| господа, python рулит однозначно какой там perl...  |
| Автор: mr.DUDA 1.1.2008, 03:17 | ||
Есть подозрение, что чел напилсо Выпил - будь человеком, не некромантничай и некрофильничай! Хоть и Новый Год и простительно, но блин это уж чересчур. |
| Автор: thomas 1.1.2008, 13:17 | ||
mr.DUDA,
Не, просто дату перепутал. Как вариант. |
| Автор: Ch0bits 3.1.2008, 15:48 |
1С - рулит!  |
| Автор: JackYF 3.1.2008, 15:56 | ||
Ррррр........ врррррррррррр..................... уээээээээээээу уэээээээээээээу уэээээээээээээээээээээээээуууууууууррррррррррщщщщщщщ...... бздышшшшшщь! [стена] |
| Автор: Lazin 4.1.2008, 12:20 |
| Недавно узнал что MS SQL Server написан на чистом С.. ООП sucks |
| Автор: Void 4.1.2008, 12:32 |
| Пруфлинк в студию. Допускаю, что это так, но бездоказательным утверждениям грош цена. |
| Автор: smartov 4.1.2008, 13:42 |
| А вот Линус Торвальдс не любит ООП... |
| Автор: Lazin 4.1.2008, 13:43 |
| Доказательств у меня нет, я просто слышал, что 2005й SQL Server они сначала хотели переписать на .NET, потом отказались от этого. Есть еще куча больших проектов написаных на С - интерпретатор python, blender... |
| Автор: JackYF 4.1.2008, 13:44 | ||||
так от кого-то? а то ОБС получается? Добавлено через 36 секунд
ядро linux, часть гнома, xfce... дальше что? а есть ещё куча больших проектов, написанных на С++... |
| Автор: Void 4.1.2008, 13:55 | ||||
Я из этого его жаркого послания так и не понял, что он больше не любит, ООП или C++. Ну и область у него... специфическая, мягко говоря.
Правильно, ибо нафиг? Тем не менее, MS SQL 2005 может выступать в качестве CLR host, использовать ХП на managed языках, типы данных CLR и т.д. И наконец, эта «новость» ничего не говорит о том, на чём именно написан SQL Server. Может частями на C++, кто знает. |
| Автор: Lazin 4.1.2008, 14:51 | ||
так и получается))) Вобще я за то что-бы пользоваться тем что хорошо знаешь, если человек всю жизнь пишет в процедурном стиле, то при переходе на ООП он скорее всего понапишет глупостей Добавлено через 14 секунд поначалу конечно |
| Автор: JackYF 4.1.2008, 15:02 | ||
несомненно. Вот у Линуса на С хорошо получается - флаг в руки. А меня С не устраивает, хочу С++ - и Линус со своими претензиями идёт куда подальше. |
| Автор: Shaggie 6.1.2008, 22:50 | ||
Эй, зачем матацикел сламал, да? |
| Автор: MAKCim 6.1.2008, 23:41 | ||
сейчас договоришься  |
| Автор: JackYF 7.1.2008, 00:02 | ||||
1С :( у него судьба такой...
э? а чего я такого сказал?  |
| Автор: Lazin 7.1.2008, 00:45 | ||
нэт, это он азверина объелся |
