Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 136
Что за гон на плюсы, он то зачем в этом списке? Что значит "языки семейства C становятся всё менее релевантными", си это же основной язык. Понятно, что найти работу зная только его сложно, но это же можно сказать про любой язык. И причем тут web, который "вытесняет" С, тоже неясно. Программы и 3d шутеры тоже скоро на веб чтоли перейдут?
Основной для чего?
На данный момент большая часть ОС написана именно на C. И уход на C++ и C# наблюдается, но окончательно С как востребованный язык умрет еще очень нескоро, как собственно и асемблер.
Более того, замечу, что не существует задачи, для выполнения которой необходим строго C++. И, кстати, подход plain C зачастую увеличивает производительность. Ведь программист в таком случае делает упор на линейне алгоритмы, нежели на дерево классов. Это относится, конечно, к конкретным задачам, нежели к масштабной системе.
вы каждый день пишете ОС?
Помимо того C - это основной зык программирования многих микроконтроллеров.
Игрушки на Питоне уже пишут.
//Понятно, что найти работу зная только его сложно
встречный,быть может глупый вопрос - можно ли найти работу зная много чего кроме Си, не лады у меня с ним :) ?
встречный,быть может глупый вопрос - можно ли найти работу зная много чего кроме Си, не лады у меня с ним :) ?
Не согласен по поводу С. Помойму нет ничего быстрее его на данный момент, тем более под веб. Если внимательно почитать доки по fast-cgi, так популярной сегодня технологии, можно вычитать что писалась она в основном под Си. Си умеет работать со всеми современными СУБД, способен работать с протоколом на низком уровне итп. Конечно, разработка софта под веб на Си достаточно гиморный и трудоемкий процесс, однако я не думаю что данная профессия умрет. По крайней мере в ближайшее время, как заявил автор. Мое мнение
Ага, и поэтому они его вытесняют ;-)
Мало того, на C написаны почти все UNIX'ы (включая Linux) и даже (о нет!) сам Microsoft Windows!
разработка на C процесс гораздо более трудоемкий нажали на C# или Java, но есть вещи которые на них не напишешь. поэтому спрос на C-девелоперов останется, только критерии отбора будут суда серьезнее чем к писателям на managed-языках. в общем C-шники останутся, но их будет мало, при хороших зарплатах, и статус C-шника будет прсетижным, что приведет к миграции девелоперов с C# на С... но только серьезных дядек, уверенных в том, что у них есть шансы пролезть в C-ники :)
Знание C++ без знания С - это... Не подобрать столь негативного слова. ООП это апгрейд функционального похода. А то нагородят кучу объектов, а вдруг необходимо расширить - так приходится все переписывать. Read stroustroup, там все сказано.
>Не согласен по поводу С. Помойму нет ничего быстрее его на данный момент
http://java.sun.com/developer/technicalA…
"It is possible for Java code to be faster than C. For example, allocation in the Java language is already much faster than it is in C. Java programming enables optimizations not possible in C because C leaves so many important factors, such as allocation and thread management, to libraries. Ironically, it's the bit-level control over pointers, which most C programmers see as their most powerful weapon, that cripples the C compiler's ability to optimize effectively. By giving up that bit of control, you enable a wealth of optimizations that are not possible in C — and the Java compiler knows more about optimization than 99.99 percent of programmers do."
http://java.sun.com/developer/technicalA…
"It is possible for Java code to be faster than C. For example, allocation in the Java language is already much faster than it is in C. Java programming enables optimizations not possible in C because C leaves so many important factors, such as allocation and thread management, to libraries. Ironically, it's the bit-level control over pointers, which most C programmers see as their most powerful weapon, that cripples the C compiler's ability to optimize effectively. By giving up that bit of control, you enable a wealth of optimizations that are not possible in C — and the Java compiler knows more about optimization than 99.99 percent of programmers do."
Кто-нибудь, пообсуждайте этот момент. Мне как человеку неосведомленному интересно. :)
Чего тут обсуждать? Писали менеджеры для менеджеров =)
Для C можно использовать свой менеджер памяти, а не то уродство, что пердоставляется системой. При чём этих менеджеров памяти ещё года четыре назад было несколько штук, а сейчас и подавно должны быть в изобилии.
Поддержка многопоточности это совсем песня. Разницы между реализацией на Java и на C практически нет - в Java обёртки для системных вызовов используются. Но не в этом дело - многопоточное программирование для подавляющего числа разработчиков это тёмный лес и с фреймворком никак не связано. Алгоритмы и примитивы все используют одинаковые, основная проблема в использователях этих примитивов и алгоритмов =)
Для C можно использовать свой менеджер памяти, а не то уродство, что пердоставляется системой. При чём этих менеджеров памяти ещё года четыре назад было несколько штук, а сейчас и подавно должны быть в изобилии.
Поддержка многопоточности это совсем песня. Разницы между реализацией на Java и на C практически нет - в Java обёртки для системных вызовов используются. Но не в этом дело - многопоточное программирование для подавляющего числа разработчиков это тёмный лес и с фреймворком никак не связано. Алгоритмы и примитивы все используют одинаковые, основная проблема в использователях этих примитивов и алгоритмов =)
Лично меня привел в недоумение набор тегов.
тоже не согласен по поводу С
он переживет всех нас.
вот только распространенность его будет падать с каждым годом, и он вернется туда, откуда пришел - в *системное* программирование. На чем написаны движок php, FireFox, Apache иже с ними? А Quake и NFS? А AutoCad?
За пол-века було придумано несколько тысяч (от 5 до 10) языков программирования. C - один из первых. Где сейчас остальные, и где С?
Кроме того, пока жив *nix - жить и С (и С++ и пр.)
он переживет всех нас.
вот только распространенность его будет падать с каждым годом, и он вернется туда, откуда пришел - в *системное* программирование. На чем написаны движок php, FireFox, Apache иже с ними? А Quake и NFS? А AutoCad?
За пол-века було придумано несколько тысяч (от 5 до 10) языков программирования. C - один из первых. Где сейчас остальные, и где С?
Кроме того, пока жив *nix - жить и С (и С++ и пр.)
да, еще...
не путайте язык "С", "С-подобные" языки и среды разработки а ля MS VC++.
VC++ умрет, С++ - нет
не путайте язык "С", "С-подобные" языки и среды разработки а ля MS VC++.
VC++ умрет, С++ - нет
ну что Вы, право дело, накинулись на автора?
ключевая фраза про си звучит как "но знания только базового языка C уже недостаточно"!
>Си умеет работать со всеми современными СУБД
о что ч того, что C умеет? речь едет о разрабочике который не умеет :) и не знает что такое СУБД. легко ему будет найти работу там, где такие знания нужны?
>А Quake и NFS? А AutoCad?
А про Direct3D, OpenGL, базовые принципы CAD-систем уже не нужны !? Нужны!
Ну дык вот, голый C-шник никому не нужен, нужно чтобы кроме знаний C, важность которого никто не подвергает сомнению, у него в голове было еще что-то :)
ключевая фраза про си звучит как "но знания только базового языка C уже недостаточно"!
>Си умеет работать со всеми современными СУБД
о что ч того, что C умеет? речь едет о разрабочике который не умеет :) и не знает что такое СУБД. легко ему будет найти работу там, где такие знания нужны?
>А Quake и NFS? А AutoCad?
А про Direct3D, OpenGL, базовые принципы CAD-систем уже не нужны !? Нужны!
Ну дык вот, голый C-шник никому не нужен, нужно чтобы кроме знаний C, важность которого никто не подвергает сомнению, у него в голове было еще что-то :)
Погодите погодите, а разве разработчик на php, perl, asp и любых других веб языков без знания СУБД кому-то нужен на текущий момент??? Тогда можно вписывать, цитирую, "несколько тысяч (от 5 до 10) языков программирования". В духе:
"но знания только базового языка basic уже недостаточно"
"но знания только базового языка pascal уже недостаточно"
"но знания только базового языка php уже недостаточно"
"но знания только базового языка asp уже недостаточно"
итп
"но знания только базового языка basic уже недостаточно"
"но знания только базового языка pascal уже недостаточно"
"но знания только базового языка php уже недостаточно"
"но знания только базового языка asp уже недостаточно"
итп
И в конце концов, если речь зашла про DirectX и OpenGL, а на чем писаны эти библиотеки, побоюсь спросить? =)
не удивлюсь если частично на ASM'е :)
но неужели Вы считаете что кроме зания С у авторов за плечами больше ничего не было !?
кстати, вас наверное удивит, но еще несколько лет достаточно было просто знать С. Зачем человеку который пишет драйвера или консольные апликушки под ДОC/linux знать о существовании directX !? но сейчас тенденции таковы что знать надо много, очень много, поскольку C++ выпал из ниши простеньких консольных утилиток уступив ее скриптовым языкам и оставив за собой громоздкие проекты критичные к быстродействию (это конечно утрировано, но в принципе отражает реалии). а громоздкость тянет за собой необходимость быть эрудированным во многих областях.
но неужели Вы считаете что кроме зания С у авторов за плечами больше ничего не было !?
кстати, вас наверное удивит, но еще несколько лет достаточно было просто знать С. Зачем человеку который пишет драйвера или консольные апликушки под ДОC/linux знать о существовании directX !? но сейчас тенденции таковы что знать надо много, очень много, поскольку C++ выпал из ниши простеньких консольных утилиток уступив ее скриптовым языкам и оставив за собой громоздкие проекты критичные к быстродействию (это конечно утрировано, но в принципе отражает реалии). а громоздкость тянет за собой необходимость быть эрудированным во многих областях.
Думаю, что современный компилятор оптимизирует код а ассемблере получше человека.
На небольших объемах кода и на не сильно сложных конструкциях.
грамотного человека компилатор не переплюнет еще долго.
кое-что он конечно может оптимизировать, но человек это ГОЛОВА! :)
за сим до сих пор многое (имеются в виду ассемблерные вставки) пишут именно на ассемблере, не полагаясь на компиляторы
кое-что он конечно может оптимизировать, но человек это ГОЛОВА! :)
за сим до сих пор многое (имеются в виду ассемблерные вставки) пишут именно на ассемблере, не полагаясь на компиляторы
Но кроме компилляторов еще бывают VM ;)
См. http://www.habrahabr.ru/blog/translation…
См. http://www.habrahabr.ru/blog/translation…
Вы ошибаетесь
Позвольте.. Все сейчас такие умные, прямо сисархи и не менее. История идет витками. Нука, найдите мне толкового системного программиста! Эвоно как, C++, Java.. Python на худой конец. Алгоритмы, господа! И знание C тут не преимущество, а жестокая необходимость. Уж от этого отплясать за пару месяцев можно легко.
с васиком и паскалем наверное в точку, а вот asp и php подразумевают обладание подобными знаниями "по умолчанию" ...
Ну это тоже как посмотреть. Например года 4 назад, когда веб разработчики видили mysql только в сладких снах, "знание php" вовсе не подразумевало "владение СУБД"
угу, и базовые знания http протоколов им не нужны были, и основы верстки/xml тоже с них никто не спрашивал...
Странно, я веб-разработчик и видел mysql 6 лет тому назад и версия у него уже была третья. А на PHP приложение, работающее с БД, пишут сразу после hello world. Не думаю, что имеет смысл писать на php приложение, не работающее с базой данных.
Я не впадаюсь в крайности =) мускул был и этого я не отрицаю. Но для русских разработчиков, в большенстве свеоем, он оставался заоблачным. Бесплатных хостингов с базой небыло тогда вообще. Платные хостинги зажимали йайца разработчика в капканы, не дай бог будет использовать более одной БД итп.
Да и потом такие проекты как ExBB, copi.ru существуют без БД и не жалуются.
Да и вообще, я не понимаю о чем спор. Если заглянуть в php.ini - mysql это лишь модуль, модулем он стал с 4.3 чтоли версии. Т.е. на данный момент в "базовые знания" php вовсе не входит владение СУБД
Да и потом такие проекты как ExBB, copi.ru существуют без БД и не жалуются.
Да и вообще, я не понимаю о чем спор. Если заглянуть в php.ini - mysql это лишь модуль, модулем он стал с 4.3 чтоли версии. Т.е. на данный момент в "базовые знания" php вовсе не входит владение СУБД
Четыре года назад мы видели MySQL не в сладких снах, а на серверах. А вот лет так 10 назад я на сервере видел miniSQL ( http://www.hughes.com.au/ )
Видимо, когда-то знания базового языка Cи было достаточно.
первый раз слышу о профессии cc:Mail
6. Программирование на C
По мере наступления веба, языки семейства C становятся всё менее релевантными. И хотя C++ и C Sharp по-прежнему живы и активно используются, но знания только базового языка C уже недостаточно, чтобы найти хоть какую-нибудь работу.
феерический неаргументированный бред. у си давно есть своя чётка ниша - os level & hardware level & drivers/kernel services/modules. туда никакие шарпы и прочие поделья не залезут. так что так называемое 'вымирание' си всего лишь говорит о том, что ныне его редко применяют в виндовых user-space приложениях. хотя те же линуха имеют море сишного user-space софта. я, честно говоря, против использования си в user-space, но факт остаётся фактом - си суть классика, причём классика рабочая и бессмертная.
По мере наступления веба, языки семейства C становятся всё менее релевантными. И хотя C++ и C Sharp по-прежнему живы и активно используются, но знания только базового языка C уже недостаточно, чтобы найти хоть какую-нибудь работу.
феерический неаргументированный бред. у си давно есть своя чётка ниша - os level & hardware level & drivers/kernel services/modules. туда никакие шарпы и прочие поделья не залезут. так что так называемое 'вымирание' си всего лишь говорит о том, что ныне его редко применяют в виндовых user-space приложениях. хотя те же линуха имеют море сишного user-space софта. я, честно говоря, против использования си в user-space, но факт остаётся фактом - си суть классика, причём классика рабочая и бессмертная.
В озвученной нише вакансий (и вообще людей) ооочень мало. А речь идет именно о шансах трудоустройства.
Если так рассуждать то кроме java/php/C#/C++ вообще все остальное можно записать в вымирающие навыки.
Половина десктопного софта под линукс на gtk и, соотвественно, на С.
Половина десктопного софта под линукс на gtk и, соотвественно, на С.
мало, но есть. я, например, работаю в этой сфере, и знаю довольно много людей, как в москве, так и в питере, являющихся моими коллегами по языку =)
А я полность за. C - программы вполне выполняют свою роль. И пишутся частенько быстрее. Ведь любая задача - есть суть линейный алгоритм. Взвесили цели, расписали задачи, спрограммировали линейный код. И нет огорода с объектами (зачастую очень труднорасширяемого). Нет, я не противник ООП, я его приверженец, но только в True виде.
чтобы писать юзерспейс программу на си, нужно иметь для этого очень веские аргументы. например если скорость критична или нужен самописный memory manager, заточенный под определённые цели. потому что действительно нереально много памяти в сложные приложениях на сях тратятся на отладку всевозможных сигфолтов, мемликов итп.
имхо, для мелкой небольшой юзерспейс гуй-программки идеален питон. а вот более сложные, по крайней мере в *nix приходится писать на сях или плюсах, что есть очень хорошо. думаю, что вскоре языки типа d++ займут эту нишу.
имхо, для мелкой небольшой юзерспейс гуй-программки идеален питон. а вот более сложные, по крайней мере в *nix приходится писать на сях или плюсах, что есть очень хорошо. думаю, что вскоре языки типа d++ займут эту нишу.
пункт 9 вообще не понял, ни в переводе, ни тут
что такое случилось с администраторами PC-сетей, их заменили windows servers?
кстати, профессий в этом списке только две, остальное — навыки (как и написано в оригинале)
что такое случилось с администраторами PC-сетей, их заменили windows servers?
кстати, профессий в этом списке только две, остальное — навыки (как и написано в оригинале)
ктонибудь для прикола посчитайте сколько вакансийна на хабре для каждого языка. На первый взгляд PHP без конкуренции, промелькнули также .NET, perl, Javascript. И кроеме того справа большой банер "пишешь на PHP"?
со знанием С/C++ нашел только одну вакансию(мастерхоста) с зарплатой 100 000 руб в месяц. и судя по всему на такую вакансию примут только гуру. Тоесть выходит что со средними знаниями только одного C на хабр-работе будет трудно подыскать себе чтото. А вот со среднимизнаниями PHP будет легко трудоустроится.
со знанием С/C++ нашел только одну вакансию(мастерхоста) с зарплатой 100 000 руб в месяц. и судя по всему на такую вакансию примут только гуру. Тоесть выходит что со средними знаниями только одного C на хабр-работе будет трудно подыскать себе чтото. А вот со среднимизнаниями PHP будет легко трудоустроится.
Эту статистику нельзя считать глобальной - слишком сильно сказывается web-специфика Хабра.
точно. Ища webdev, я бы с радостью принял на работу C/C++ гуру/посвященного. Для него php, perl/все что угодно будут семечками. Ведь программист не характеризуется знанием языка.
Точно, имея опыт "think in pattern" на профессиональном уровне легко освоить любой другой язык, даже тот, который не полностью поддерживает раннее используемые принципы. Пример: разработчик одного из продвинутых javascript фреймворков "Ext JS", Jack Slocum был до этого, в течении 10 лет, разработчиком на Jave. Языки разные, поддержка ООП разная, но мыслит опытный человек изначально в правильном направлении ;)
Легко трудоустроиться, зато невозможно получать нормальную зарплату =)
2. Нереляционные СУБД — очень спорно, на вскидку Cache, (berley db)
6. Программирование на C — вообще бред
с остальным пожалуй соглашусь хотя с COBOL тоже не все так однозначно
6. Программирование на C — вообще бред
с остальным пожалуй соглашусь хотя с COBOL тоже не все так однозначно
насчёт C согласен ....
в нашем городе только однна контора предоставляет вакансии С++ девелоперов с
с нормаьной зп ......
в противном случае со знаниями С можно идти в постсовдеповское НИИ
на ЗП в 5 тыров ....
Хотя с трудоустройством С#, Java, PHP девелоперов проблем никаких.
в нашем городе только однна контора предоставляет вакансии С++ девелоперов с
с нормаьной зп ......
в противном случае со знаниями С можно идти в постсовдеповское НИИ
на ЗП в 5 тыров ....
Хотя с трудоустройством С#, Java, PHP девелоперов проблем никаких.
...До сих пор продолжаются споры, насколько надёжны и масштабируемы приложения на ColdFusion по сравнению с конкурентами...
Есть такой скромный сайт - MySpace.com.
Шестое место в мире по траффику.
Первое среди социальных сетей - более 176 миллионов пользователей.
Щёлкнете на любой пункт в меню и посмотрите на URL:
http://www.myspace.com/index.cfm?fuseact…
.cfm - это CFML. То есть Coldfusion, хотя в данном случае BlueDragon - альтернативный аналог Adobe Coldfusion, выпускаемый компанией New Atlanta.
Так как насчёт надёжности и масштабируемости?
Расширение - не показатель.
У меня есть несколько проектов, выполненных на ColdFusion.
Мое мнение, по простоте (скорости разработке) этот язык проигрывает PHP.
А по возможности создания специализированных приложений — Perl.
Для меня оказалось рентабельнее освоить два последних языка, чем мириться с "досадными недоразумениями" ColdFusion.
Мое мнение, по простоте (скорости разработке) этот язык проигрывает PHP.
А по возможности создания специализированных приложений — Perl.
Для меня оказалось рентабельнее освоить два последних языка, чем мириться с "досадными недоразумениями" ColdFusion.
Эээ если я правильно помню что такое ColdFusion , то вообще это строго говоря не язык вовсе. Если копнуть глубже, то опаньки вылазит java. А если еще посмотреть поглубже, то выясняется, что весь этот ColdFusion ни что иное как своеобразный фрейморк для java.
Щёлкаем на второй пункт меню (browse). Второй, потому что первый это Home, ведущий, очевидно, на http://www.myspace.com/
И смотрим на URL: http://browseusers.myspace.com/browse/br…
.aspx это ASP.NET. То есть, .NET Framework, хотя в данном случае наверняка вторая версия.
Насчёт масштабируемости и надёжности Coldfusion могу сказать следующее:
Много лет назад от него отказались и он остался только в некритичных для скорости местах. То бишь тех, которые кэшируются через reverse proxy или куда ходит мало людей. Но со временем перепишут и эти места =)
Я не удивлюсь, что там ещё встречается Perl =) Что, Perl хуже ColdFusion, раз с него сбежали разработчики MySpace? ;)
И смотрим на URL: http://browseusers.myspace.com/browse/br…
.aspx это ASP.NET. То есть, .NET Framework, хотя в данном случае наверняка вторая версия.
Насчёт масштабируемости и надёжности Coldfusion могу сказать следующее:
Много лет назад от него отказались и он остался только в некритичных для скорости местах. То бишь тех, которые кэшируются через reverse proxy или куда ходит мало людей. Но со временем перепишут и эти места =)
Я не удивлюсь, что там ещё встречается Perl =) Что, Perl хуже ColdFusion, раз с него сбежали разработчики MySpace? ;)
Не поленитесь щёлкнуть дальше. И посмотрите на URL.
Пункт меню Search:
http://search.myspace.com/index.cfm?fuse…
Пункт Film:
http://www.myspace.com/index.cfm?fuseact…
Пункт Forum:
http://forum.myspace.com/index.cfm?fusea…
Ну и так далее. Походите внутри сайта.
Везде .cfm - то есть ColdFusion.
Только Browse почему-то .aspx - не успели ещё на cfm переписать :)
Пункт меню Search:
http://search.myspace.com/index.cfm?fuse…
Пункт Film:
http://www.myspace.com/index.cfm?fuseact…
Пункт Forum:
http://forum.myspace.com/index.cfm?fusea…
Ну и так далее. Походите внутри сайта.
Везде .cfm - то есть ColdFusion.
Только Browse почему-то .aspx - не успели ещё на cfm переписать :)
Катеорически несогласен касаемо OS/2: до сих пор считаю её лучшей (с т.зр. обывателя) операционной системой. "Ошибка природы" - не OS/2, а брэндменеджер данного продукта, решивший позиционировать её как сугубо корпоративное решение вместо действий, направленных на массовый рынок.
и все же какую нишу сейчас занимает полуось на фоне борьбы эйпл, микрософт и линукс?
давно никакую. ИБМ с самого начала забили на эту ось (чего стоит непофиксенная годами возможность завалить ось из досовской сессии через echo>pagefile).
Sun стоит на большем количестве компьютеров, чем Apple. Любопытно, почему Apple с её копейками процентов участвует в борьбе, а Sun нет? ;)
Как ты это определил? :)
Да никак не определял. Что у тех копейки, что у других. Точных данных никто не знает, всё на уровне погрешности измерений. Меня просто позабавил факт борьбы Apple =) Очевидно, что со своей глючной операционкой они не смогут стать массовыми. Как только появится более-менее приличное количество разработчиков, они сделают такую кучу говна, что Джобс нафиг закроет всю документацию вообще =)
А расскажи мне про мою глючную операционку? :)
В двух словах, реальность порой не соответствует документации, а в некоторых случаях документация выглядит "смотрите заголовки". Ну и segfault это плохая идея для безобидных операций с неправильными параметрами.
Как только девелоперы будут такого же низкого уровня, как в Windows, MacOS тут же станет дырявой и глючной.
Как только девелоперы будут такого же низкого уровня, как в Windows, MacOS тут же станет дырявой и глючной.
Так я не в двух словах, услышанных от Арика, хочу прочитать, а что-нибудь конкретное, чтобы знать, чего опасаться. В идеале хороший мануал. Я за четыре года не нарывался, но вдруг.
Строгое управление памятью (лично вот моя претензия) — она как раз на пользу идёт, не даёт расслабляться.
Ну и конечно тут мы замечаем, что она только «станет», а не «есть», как ты до этого говорил. =)
Строгое управление памятью (лично вот моя претензия) — она как раз на пользу идёт, не даёт расслабляться.
Ну и конечно тут мы замечаем, что она только «станет», а не «есть», как ты до этого говорил. =)
Ну вот как стану девелопером для Мака, тогда буду держать в голове все ответы на все вопросы. А пока либо принимай в двух словах, либо сам спрашивай "что-нибудь конкретное" у Арика =)
Про строгое управление памяти - массовость невозможна с таким подходом. Потому что получишь кучу софта, работающего абы как. Что, в общем-то, и есть показатель дырявости и кривости операционки.
Глючность MacOS будет проявляться с популяризацией, но существует она уже сейчас.
А пока самой дырявой и глючной общепринято считать Windows, это наследние от Win9x досталось. В действительности это самая нормальная операционка из всех существующих и более-менее популярных. Линух был самым защищённым, пока он никому не был нужен. А как стал отбивать у FreeBSD кусок пирога, тут же и дыры появились и всё такое. Впрочем, это не мешает до сих пор ярым апологетам Linux рассказывать всем, что в Linux просто физически невозможен вирус и что его невозможно сломать чисто из-за архитектуры.
Всегда и везде символ >>| используется для перемотки по трекам, а в DVD-плейере Apple, эта кнопка используется ещё и для плавной перемотки вперёд, если её зажать =) Я понимаю, минималистичность и всё такое, но Apple слишком маленькая компания, чтобы сломать такие стереотипы. Да ещё так хреново - пользователь Мака с двухмесячным стажем этой шутки юмора не просёк.
Но в любом случае Sun борется с Микрософтом точно так же интенсивно, как и Apple =)
И ещё я смотрю на операционку не как пользователь, а как девелопер. Carbon я видел краем глаза и он заметно хуже спроектирован и задокументирован, чем Java/.NET/Win32. Пользователи своё фи скажут когда-нибудь потом, как софта будет побольше =) А пока я вижу у нас на шарах кучу папочек/файлов с точками в начале и флагом скрытости и меня смешит такое поведение операционной системы.
Про строгое управление памяти - массовость невозможна с таким подходом. Потому что получишь кучу софта, работающего абы как. Что, в общем-то, и есть показатель дырявости и кривости операционки.
Глючность MacOS будет проявляться с популяризацией, но существует она уже сейчас.
А пока самой дырявой и глючной общепринято считать Windows, это наследние от Win9x досталось. В действительности это самая нормальная операционка из всех существующих и более-менее популярных. Линух был самым защищённым, пока он никому не был нужен. А как стал отбивать у FreeBSD кусок пирога, тут же и дыры появились и всё такое. Впрочем, это не мешает до сих пор ярым апологетам Linux рассказывать всем, что в Linux просто физически невозможен вирус и что его невозможно сломать чисто из-за архитектуры.
Всегда и везде символ >>| используется для перемотки по трекам, а в DVD-плейере Apple, эта кнопка используется ещё и для плавной перемотки вперёд, если её зажать =) Я понимаю, минималистичность и всё такое, но Apple слишком маленькая компания, чтобы сломать такие стереотипы. Да ещё так хреново - пользователь Мака с двухмесячным стажем этой шутки юмора не просёк.
Но в любом случае Sun борется с Микрософтом точно так же интенсивно, как и Apple =)
И ещё я смотрю на операционку не как пользователь, а как девелопер. Carbon я видел краем глаза и он заметно хуже спроектирован и задокументирован, чем Java/.NET/Win32. Пользователи своё фи скажут когда-нибудь потом, как софта будет побольше =) А пока я вижу у нас на шарах кучу папочек/файлов с точками в начале и флагом скрытости и меня смешит такое поведение операционной системы.
Тоже хочется про языки сказать. Вы не забывайте, что удобный и используемый язык - это не то же самое, что и язык за знание которого нанимают. C++, C#, Java, Perl - это то, за что платят, а платят потому что те, у кого есть деньги, частенько понятия не имеют, с чем они сталкивают своих программистов. Нет у них времени разобраться, поковыряться, и найти горы глюков, неконсистентностей, сложностей во всех этих раскрученных средствах разработки. Всё это есть в любях языках, например, в C кошмар с #include или деление на значение по адресу. Но чем меньше язык, тем этих глюков меньше. Perl, C++, C# и современная Java - большие языки.
Почему сложные языки популярны? Популярность этих средств книжна: чем толще книжка, тем язык круче - обычная мораль, обычного самца homo sapiens. Раз он смог освоить очень сложное средство, то он крут. Раз он смог освоить корявое средство, вроде C++, то он крут. Так уж получилось, что люди с деньгами оценвают не эффективность, а именно крутость того, кого нанимают, ибо в эффективности они понять ничего не могут, в силу иной профессиональной ориентации. А крутость, ещё раз, в программировании это означает умение программировать на сложных средствах. Нет, конечно, гораздо круче разбираться во всех алгоритмах, упомянутых Кнутом и Корнелом, но для этого уже нужно напрягать мозг и тратить время, и проверить эту крутость сложнее, потому что тогда наниматель должен в этом всём разбираться сам, а там терминов и абстракций гораздо больше, чем в семантике языка программирования, а связи между ними гораздо богаче, чем отношение isA.
Плюс людям с деньгами на семинарах промывают мозги, рассказывая сказки о том, насколько Java может быть эффективной, и насколько хорошо она может управлять нитями, и насколько хорошо памятью. Но начинаешь разбираться и: конечно, может, иногда, в некоторых случаях, специальных, которые часто встречаются в том коде, скорость работы которого не критична. Вы не забывайте, что насколько бы продвинутой была VM она обязана защитить runtime от действий программиста, а это горы лишних проверок при хоть сколько-нибудь нетривиальном обращении к массивам, или отсутсвие нормальных массивов в языке совсем. Но менеджер этого не знает, а обёртка у Java очень красивая.
Про C++ то же самое: смотрите какие чудные иерархии мы можем строить, а потом использовать совершенно безумные хаки, чтобы это всё нормально работало, cooool, давайте заставлять их строить всегда и везде, в любой беде. Давайте напишем про это кучу теоретических книжек, сделаем большие бабки на этом, и дадим кодерам возможность получать больше денег, за меньший объём осмысленной работы. Умные гомоморфные автоматические указатели со сборкой мусора рулятЪ и trueЪ. Это же такая хардкорная математика, и, как алгебраиста интеллектуально она меня очень привлекает, например. Всегда очень хочется прочитать новое издание advanced c++ programming. Но это всё красивые теории, а не практика.
Это всё к удобству и эффективности отношения не имеет. Просто, подкреплённое ленью менеджеров и ценой на компиляторы (компилятор C++ или C# НАМНОГО сложнее, чем компилятор C, естественно, их сложно воспроизвести, следовательно, на этом можно делать деньги), общественное мнение и работа на собственную крутость.
Между тем, на C в комбинации с продвинутой shell можно спокойно писать сложные web-приложения. И даже гораздо более сложные, чем на всех этих высокоуровневых С#, Java, C++, Python, которые загоняют программистов в древовидные структуры классов и библиотек. Потому что дают свободу. Посмотрите на все web службы для Plan9 - там только C и rc. Сложный ли там код? Гораздо проще, чем мне доводилось видеть в аналогичных службах, писанных на asp.net. Да, на C приходится писать free, освобождая память, но это единственная техническая сложность. Но по сравнению с чисто техническими проблемами при использовании классов - это такие мелочи.
Почему Linux'оиды чаще всего выбирают для программирования C и shell, а не кучу других языков, которые доступны для использования? У меня вот в gentoo установлено сейчас около 400 пакетов, и только около 50 составлены на чём-то отличном от C и shell. Не по историческим причинам совсем при разработке 'софта не из-за денег' используется именно эта комбинация, есть много свеженьких проектов, разработку которых начали в эпоху всего этого высокоуровневого разгула. Именно потому, что это достаточно компактные языки. Можно быстро выучить и запомнить все странности и глюки, можно получить свободу в оперировании данными. А это как раз то, что нужно, чтобы за короткое время стартануть, а потом эволюционно развивать проект.
Поэтому, возможно, самого C не станет со временем, но подобный ему язык со всеми прелестями (действительно прелестями, а не недостатками, как это считают теоретики), вроде указателей и плоского пространства имён, обязательно будет существовать. И будет массовым. Потому что простенько, эффективно и пригодно не только для того, чтобы писать ядра систем или виртуальные машины для языков программирования.
Почему сложные языки популярны? Популярность этих средств книжна: чем толще книжка, тем язык круче - обычная мораль, обычного самца homo sapiens. Раз он смог освоить очень сложное средство, то он крут. Раз он смог освоить корявое средство, вроде C++, то он крут. Так уж получилось, что люди с деньгами оценвают не эффективность, а именно крутость того, кого нанимают, ибо в эффективности они понять ничего не могут, в силу иной профессиональной ориентации. А крутость, ещё раз, в программировании это означает умение программировать на сложных средствах. Нет, конечно, гораздо круче разбираться во всех алгоритмах, упомянутых Кнутом и Корнелом, но для этого уже нужно напрягать мозг и тратить время, и проверить эту крутость сложнее, потому что тогда наниматель должен в этом всём разбираться сам, а там терминов и абстракций гораздо больше, чем в семантике языка программирования, а связи между ними гораздо богаче, чем отношение isA.
Плюс людям с деньгами на семинарах промывают мозги, рассказывая сказки о том, насколько Java может быть эффективной, и насколько хорошо она может управлять нитями, и насколько хорошо памятью. Но начинаешь разбираться и: конечно, может, иногда, в некоторых случаях, специальных, которые часто встречаются в том коде, скорость работы которого не критична. Вы не забывайте, что насколько бы продвинутой была VM она обязана защитить runtime от действий программиста, а это горы лишних проверок при хоть сколько-нибудь нетривиальном обращении к массивам, или отсутсвие нормальных массивов в языке совсем. Но менеджер этого не знает, а обёртка у Java очень красивая.
Про C++ то же самое: смотрите какие чудные иерархии мы можем строить, а потом использовать совершенно безумные хаки, чтобы это всё нормально работало, cooool, давайте заставлять их строить всегда и везде, в любой беде. Давайте напишем про это кучу теоретических книжек, сделаем большие бабки на этом, и дадим кодерам возможность получать больше денег, за меньший объём осмысленной работы. Умные гомоморфные автоматические указатели со сборкой мусора рулятЪ и trueЪ. Это же такая хардкорная математика, и, как алгебраиста интеллектуально она меня очень привлекает, например. Всегда очень хочется прочитать новое издание advanced c++ programming. Но это всё красивые теории, а не практика.
Это всё к удобству и эффективности отношения не имеет. Просто, подкреплённое ленью менеджеров и ценой на компиляторы (компилятор C++ или C# НАМНОГО сложнее, чем компилятор C, естественно, их сложно воспроизвести, следовательно, на этом можно делать деньги), общественное мнение и работа на собственную крутость.
Между тем, на C в комбинации с продвинутой shell можно спокойно писать сложные web-приложения. И даже гораздо более сложные, чем на всех этих высокоуровневых С#, Java, C++, Python, которые загоняют программистов в древовидные структуры классов и библиотек. Потому что дают свободу. Посмотрите на все web службы для Plan9 - там только C и rc. Сложный ли там код? Гораздо проще, чем мне доводилось видеть в аналогичных службах, писанных на asp.net. Да, на C приходится писать free, освобождая память, но это единственная техническая сложность. Но по сравнению с чисто техническими проблемами при использовании классов - это такие мелочи.
Почему Linux'оиды чаще всего выбирают для программирования C и shell, а не кучу других языков, которые доступны для использования? У меня вот в gentoo установлено сейчас около 400 пакетов, и только около 50 составлены на чём-то отличном от C и shell. Не по историческим причинам совсем при разработке 'софта не из-за денег' используется именно эта комбинация, есть много свеженьких проектов, разработку которых начали в эпоху всего этого высокоуровневого разгула. Именно потому, что это достаточно компактные языки. Можно быстро выучить и запомнить все странности и глюки, можно получить свободу в оперировании данными. А это как раз то, что нужно, чтобы за короткое время стартануть, а потом эволюционно развивать проект.
Поэтому, возможно, самого C не станет со временем, но подобный ему язык со всеми прелестями (действительно прелестями, а не недостатками, как это считают теоретики), вроде указателей и плоского пространства имён, обязательно будет существовать. И будет массовым. Потому что простенько, эффективно и пригодно не только для того, чтобы писать ядра систем или виртуальные машины для языков программирования.
Эх : ( Опять нафлудил...
"Почему Linux'оиды чаще всего выбирают для программирования C и shell, а не кучу других языков, которые доступны для использования? У меня вот в gentoo установлено сейчас около 400 пакетов, и только около 50 составлены на чём-то отличном от C и shell. Не по историческим причинам совсем при разработке 'софта не из-за денег' используется именно эта комбинация, есть много свеженьких проектов, разработку которых начали в эпоху всего этого высокоуровневого разгула. Именно потому, что это достаточно компактные языки. Можно быстро выучить и запомнить все странности и глюки, можно получить свободу в оперировании данными. А это как раз то, что нужно, чтобы за короткое время стартануть, а потом эволюционно развивать проект."
к сожалению, чем популярнее Линукс, тем больше появляется проектов на интерпретируемых языках. Люди не любят учиться, разбираться. Мало кто возьмется читать книгу по LaTeX, когда есть такой наглядный и "простой" ворд при том, что подавляющее большинство не знают про стили.
к сожалению, чем популярнее Линукс, тем больше появляется проектов на интерпретируемых языках. Люди не любят учиться, разбираться. Мало кто возьмется читать книгу по LaTeX, когда есть такой наглядный и "простой" ворд при том, что подавляющее большинство не знают про стили.
к сожалению, чем популярнее Линукс, тем больше появляется проектов на интерпретируемых языках. Люди не любят учиться, разбираться. Мало кто возьмется читать книгу по LaTeX, когда есть такой наглядный и "простой" ворд при том, что подавляющее большинство не знают про стили.
чем плохи проекты на интерпретируемых языках. я лично полностью за то, чтобы лёгкий гуй писали на питоне и подобных.
чем плохи проекты на интерпретируемых языках. я лично полностью за то, чтобы лёгкий гуй писали на питоне и подобных.
Лёгкий GUI, написанный на Python превращается в очень тяжёлый GUI. Тяжёлый для пользователя, конечно: подтормаживает, память поджирает, процессор грузит. Не самая сложная программа, например, gajim, которая вобщем-то есть GUI для Jabber, может очень сильно начать греть процессор и грузить swap. Странно, но гораздо более сложный и функциональный gaim намного реактивнее. При этом, объём его кода всего на 30 процентов больше (а, напомню, протоколов он поддерживает в 6 раз больше). Вот такие пироги.
ну на gajim вы немного наговариваете, уже чёрт знает сколько его использую - замечаются тормоза только на момент загрузки и в процессе запроса инфо о пользователе. но тем не менее, гаджим становится монстриком, это уже далеко не лёгкий гуй, и он, как вы правильно заметили, будет становиться тяжелее.
но всё же, какие могут быть альтернативы? использовать gtk и с, gtkmm/qt и с++ для лёгковесной морды к какой-нибудь консольной программке - садомазохизм. если известно, что гуй не будет обрастать до монструозности, то проще сэкономить время, используя скриптовый язык, как это делают например господа из ubuntu.
но всё же, какие могут быть альтернативы? использовать gtk и с, gtkmm/qt и с++ для лёгковесной морды к какой-нибудь консольной программке - садомазохизм. если известно, что гуй не будет обрастать до монструозности, то проще сэкономить время, используя скриптовый язык, как это делают например господа из ubuntu.
КРоме того, GUI очень просто пишется на tcl - средстве, которое разработано, чтобы сшивать различные функции на C. Вот. Логика у него такова, что памятью в tcl программе очень просто управлять автоматически, а на tcl/tk GUI писать - совершенно очаровательное дело. Надо кнопку - пишем buttom и не мучаемся : ) Это я к тому, что все эти сложности с объектами, иерархиями, интерфейсами и прочим - совсем не обязательны, чтобы писать быстро и компактно.
а зачем пользовательский интерфейс вообще писать ? имхо, его надо проектировать/компоновать и будет лучше если это будут делать не программисты.
абсолютно согласен, но в мире open-source, к сожалению, этим в большинстве случаев занимаются именно программисты.
ну инструментов уже достаточно в т. ч. первоклассных. А касательно программистов: косвенно, но очень весомо помогает openusability project на тех же opensource принципах. И тут совершенно другие критерии, т.к. абстрактная контора может нанять хорошего или не очень юзабилити специалиста, а открытый проект может бесплатно получить рекоммендации гораздо более опытных людей и большую аудиторию для тестирования.
Почему? Люди любят учиться и разбираться, иначе они не пошли бы в программисты. Только разобраться во всём очень сложно. А работодатель заставляет разбираться не в самых эффективных средствах разработки. А раз человек выучил интерпретируемый язык, потому что все вокруг хотят от него того, чтобы он его выучил, и раз он может написать на нём программу, которая его устраивает, он и будет это делать.
Удручает только то, что вместо, например, огромной библии программирования на с++ или толстенной camelbook он бы мог прочесть тоненькую книжку о 'c', и толстую книжку об алгоритмах и структурах данных, да пару руководств по shell с описанием всяких утилит, вроде sed, что позволило бы ему писать более эффективно и быстро, да к тому же использовать все возможности существующего кода.
Удручает только то, что вместо, например, огромной библии программирования на с++ или толстенной camelbook он бы мог прочесть тоненькую книжку о 'c', и толстую книжку об алгоритмах и структурах данных, да пару руководств по shell с описанием всяких утилит, вроде sed, что позволило бы ему писать более эффективно и быстро, да к тому же использовать все возможности существующего кода.
Опять вы про то что ООП плохо :))) Если говорить про прикладное ПО, то там удобнее использовать именно ООП из-за быстрого выстроения иерархии объектов и абстракций. К тому же если все правильно сделано, это еще очень хорошо расширяется. Что бы написать тоже самое в другой отличной от ООП парадигме вам прийдется гараздо более тщательно проектировать и определять алгоритмы и структуры данных. Так как у C свои ограничения. Теперь немного про free. Лишний раз free говорите написать? Ну это выливается в то, что программист вместо того, чтобы думать как мне сделать вот эту штуку, думает а не забыл ли я там память освободить? Любой язык программирования как палка о двух концах. Что тут лучше делается, что-то там. Лучше всего это понимать и использовать то что надо где надо.
Теоретически, всё верно. Но быстро выстроить хорошие абстракции очень сложно. Нет, конечно, если человек может делать это быстро, то у него превосходный интеллект, я бы сказал на уровне гениальности, но многи ли таких людей? Обычные люди, как убедительно показывают исследования в области истории науки, абстракции, не формулируют перед началом работы, а находят в процессе исследований. Абстракция - это обобщение свойств. А как можно начать обобщение свойств, когда компоненты ещё не написаны? Конечно, можно указать множество ситуаций, в которых можно прибегнуть к имеющемуся опыту. Например, кнопка там, или итератор, они и в Африке кнопка или итератор. Но что если программа к этому не сводится? Когда абстракции понятны - ООП рулит, очевидно и неоспоримо. Расширяться тоже можно просто и без проблем, реализуя уже найденные интерфейсы.
Но для новых проектов всё это ООП - зло. Оно заставляет поиск решения производить задом наперёд: придумали абстракцию начали делать, а потом, хопа, поняли, что всё это работать не будет, и начинается изменение всей иерархии. Это же сложно и время отнимает, поэтому люди начинают нарушать парадигму на право и налево. Но возникает вопрос: а зачем тогда вообще они начали писать свои классы?
Насчёт free. Частое использование malloc/free - это рузультат неправильного проектирования, по моему мнению. И является болезнью больших проектов, в которых писают всё написать на C. Но C придумывался не для этого. Компоненты, написанные на C должны быть маленькими и максимально специализированными под решаемую задачу. Большая же решается через объединение компонентов через IPC. Это удобнее, чем придумывание иерархий, потому что позволяет вклиниваться и менять взаимодействие между компонентами как угодно.
Попробуйте воткнуть дополнительную обработку в pipe, или дополнительную обработку во взаимодействие между двумя объектами, когда один вызывает другой. Как минимум, придётся нечто наследовать, заново думать над тем, что должно быть виртуальным или не виртуальным. И так далее. Много работы. Может быть, именно поэтому, все сложные ОО системы рано или поздно приходят к тому, чтобы создать свою транспортную систему данных между объектами. Или воспользоваться существующей в виде базы данных или чего-нибудь, вроде, CORBA. Но это всё усложнения, усложнения и ещё раз усложнения. Которые надо осваивать, особенно при коммерческом программировании, а это всё уводит сознание от размышлений над другими методами организации вычислений. Существенно более гибкими и простыми. Ну вот сравнить хотя бы ту же CORBA с plumber'ом из Plan9 или Linda.
Поэтому я против ООП. Мне не нравится, когда навязываются сложности и неэффективности, да ещё такими ненаучными способами: вы хотя бы в одной книге по ООП видели сравнение предлагаемых способов решения тех или иных иных задач в этой парадигме с решением их в других?
Но для новых проектов всё это ООП - зло. Оно заставляет поиск решения производить задом наперёд: придумали абстракцию начали делать, а потом, хопа, поняли, что всё это работать не будет, и начинается изменение всей иерархии. Это же сложно и время отнимает, поэтому люди начинают нарушать парадигму на право и налево. Но возникает вопрос: а зачем тогда вообще они начали писать свои классы?
Насчёт free. Частое использование malloc/free - это рузультат неправильного проектирования, по моему мнению. И является болезнью больших проектов, в которых писают всё написать на C. Но C придумывался не для этого. Компоненты, написанные на C должны быть маленькими и максимально специализированными под решаемую задачу. Большая же решается через объединение компонентов через IPC. Это удобнее, чем придумывание иерархий, потому что позволяет вклиниваться и менять взаимодействие между компонентами как угодно.
Попробуйте воткнуть дополнительную обработку в pipe, или дополнительную обработку во взаимодействие между двумя объектами, когда один вызывает другой. Как минимум, придётся нечто наследовать, заново думать над тем, что должно быть виртуальным или не виртуальным. И так далее. Много работы. Может быть, именно поэтому, все сложные ОО системы рано или поздно приходят к тому, чтобы создать свою транспортную систему данных между объектами. Или воспользоваться существующей в виде базы данных или чего-нибудь, вроде, CORBA. Но это всё усложнения, усложнения и ещё раз усложнения. Которые надо осваивать, особенно при коммерческом программировании, а это всё уводит сознание от размышлений над другими методами организации вычислений. Существенно более гибкими и простыми. Ну вот сравнить хотя бы ту же CORBA с plumber'ом из Plan9 или Linda.
Поэтому я против ООП. Мне не нравится, когда навязываются сложности и неэффективности, да ещё такими ненаучными способами: вы хотя бы в одной книге по ООП видели сравнение предлагаемых способов решения тех или иных иных задач в этой парадигме с решением их в других?
Тьфу блин. Чёртов грипп. 'писают всё написать на С' - это 'пытаются всё написать на C'.
Теоретически, всё верно. Но быстро выстроить хорошие абстракции очень сложно.
Это касается так же и C. И разницы под что их собственно строить особой нет.
Обычные люди, как убедительно показывают исследования в области истории науки, абстракции, не формулируют перед началом работы, а находят в процессе исследований.
Процесс исследования и проектирования может быть различным.
Абстракция - это обобщение свойств. А как можно начать обобщение свойств, когда компоненты ещё не написаны?
А зачем вам для поиска компонент писать код? Для поиска компонент и последующего выведения абстракций существует к примеру ручка и бумага или UML, который позоволяет автоматически генерировать классы и объекты.
Когда абстракции понятны - ООП рулит, очевидно и неоспоримо.
А когда они не понятны, то как вас спасет функциональный или процедурный подход?
Но для новых проектов всё это ООП - зло. Оно заставляет поиск решения производить задом наперёд: придумали абстракцию начали делать, а потом, хопа, поняли, что всё это работать не будет, и начинается изменение всей иерархии. Это же сложно и время отнимает, поэтому люди начинают нарушать парадигму на право и налево. Но возникает вопрос: а зачем тогда вообще они начали писать свои классы?
Абстракция на пустом месте не возникает. И от ошибок проектирования не использование ООП не спасает. В любом случае если у вас было не верно спроектировано, то вам прийдется откатываться. И что отказывать как-то уже глубоко фиолетово.
Это же сложно и время отнимает, поэтому люди начинают нарушать парадигму на право и налево. Но возникает вопрос: а зачем тогда вообще они начали писать свои классы?
А что частный случай неудачного применения ООП уже указывает на неудачу парадигмы в целом ? Интересно интересно :)
Насчёт free. Частое использование malloc/free - это рузультат неправильного проектирования, по моему мнению.
И как вы будете реализовывать FIFO без частого использования malloc/free ?
Компоненты, написанные на C должны быть маленькими и максимально специализированными под решаемую задачу. Большая же решается через объединение компонентов через IPC. Это удобнее, чем придумывание иерархий, потому что позволяет вклиниваться и менять взаимодействие между компонентами как угодно.
Вы просто перенеосите процесс придумывания иерархий выше. На то как вам эти куски соеденить. Реально же каждый из пакетов или классов можно рассматривать как такой вот маленький специализированный модуль. От того какую вы модель используете для реализации основные приципы особо не меняются. В одном случае происходит взаимодействие объектов в другом случае взаимодействие специализированных модулей.
Попробуйте воткнуть дополнительную обработку в pipe, или дополнительную обработку во взаимодействие между двумя объектами, когда один вызывает другой. Как минимум, придётся нечто наследовать, заново думать над тем, что должно быть виртуальным или не виртуальным. И так далее. Много работы.
Для решения такой задачи существует специальный паттерн. И унификация интерфейсов. Опять же с pipe сравнивать не корректно. Так как pipe представляет из себя поток байтов. Я тоже могу реализовать такой интерфейс в ООП и он будет точно так же работать как и в не ООП.
Мне не нравится, когда навязываются сложности и неэффективности, да ещё такими ненаучными способами: вы хотя бы в одной книге по ООП видели сравнение предлагаемых способов решения тех или иных иных задач в этой парадигме с решением их в других?
А вы хоть в одной книге по функциональному программированию или по процедурному видели такое сравнение? Думаю что нет. Собственно эти книги знакомят вас с технологиями, а не с тем чем лучше или хуже та или иная технология. Если же говорить про ООП, то в прикладных областях использование этой парадигмы вполне оправданно, так как она позволяет получить результат существенно быстрее, чем процедурная или функциональная парадигма.
Функциональное программирование больно той же самой болезнью: нужно проектировать задом наперёд. Сначала проектируется общий вид основной функции, а потом всё ниже и ниже проектируются вспомогательные. То же самое в ООП: сначала проектируем интерфейс, а потом пытаемся реализовать. И если интерфейс оказался неподходящим, то переделывать придётся весь код. Если высокоуровневая функция в функциональном подоходе оказалась неподходящей, то переделывать весь код придётся в гораздо большей степени, чем в императивном ООП.
Оба подхода заставляют по форме (что должно быть) определить содержание (как должно быть). Вобщем-то вполне себе математичный подход. Теоретически красивый. Да, мы вот сейчас всё пишем и пишем, и на словах, действительно ООП гораздо красивее обычного структурного подхода. Кроме того, можно кучу книжек писать, ООП - богатая среда для мудрствований, например, вот те же замечательные философствования о шаблонах и рефакторинге. Так же как и функциональное программирование, а когда оно ещё и с монадами, то вообще, ууУУух как поумничать можно и статьи пописать.
C же освобождает от необходимости проектировать строго определённый интерфейс, конечно, от ответа на вопрос: что код должен делать? уйти вряд ли удасться, но ответ этот может быть достаточно нестрогим. Язык ориентирован на работу с данными, а не объектами. Если я совершу ошибку на этапе придумывания интерфейса, то мне никто не мешает напрямую залезть в структуру данных, и написать новый код для работы с ней, в том месте, где он нужен. Да, это грязно, это не математично, это нарушение кучи принципов, об этом не напишешь умную книжку, потому что это глупо, но это работет. И работает не только корректно, но и эффективно. Если подобный код мне нужен будет во многих местах - родилась абстракция - я его вынесу в соответсвующий модуль, и доступ к нему сделаю частью интерфейса.
Мог бы я подобное обнаружить на бумажке? Запросто, если бы писал на бумажке настоящую программу, до уровня операторов и вызов функций, а не просто рисовал бы стрелочки, то наверняка обнаружил бы то же самое. Но на бумажке невозможно написать нечто более или менее сложное.
Я могу предполагать, что в этом случае списки эффективны, но на реальных данных может оказаться, что они убивают производительность, или, вдруг оказывается, что для реализации некоторой возможности в новой версии нужно обращение к произвольному элементу. Если я это всё буду учитывать только после того, как напишу программу на бумажке, потом закодирую на ООП, потом откомпилирую, потом пойму, что все мои расчёты, мягко говоря, некорректные, потом опять сяду за бумажку... Я рискую ни одной эффективной программы за всю жизнь не написать.
В итоге, конечно, у меня тоже появляются объекты в программе, но границы у них не жёсткие, а размытые, и объекты именно появляются, а не спускаются сверху. Не тотальная закапсулированность позволяет упростить взаимодействие, особенно, при использовании в новом коде. А то, что объект возник естественным путём освобождает меня от необходимости прописывать какую-то невостребованную функциональность.
Да, всё то же самое можно делать и на C++, например. Но тогда надо будет делать все данные и методы изначально открытыми, и возникает вопрос, а зачем тогда этот весь этот лишний классовый синтаксис?
Ещё можно сказать, что в Smalltalk именно так формировались интерфейсы. Они формировались снизу вверх. Они возникали, а не навязывались сверху. Наследования же вообще не было. Все эти, на мой взгляд, сложности, связанные с проектирование сверху вниз, появились в компилируемых языках, в которых для повышения эффективности стали путать типы и объекты.
И последнее замечание: в книжках по функциональному программированию, обычно, всё истолковывается в терминах и примерах из императивных языков программирования, поэтому, в них со сравнением с другими технологиями всё лучше.
Оба подхода заставляют по форме (что должно быть) определить содержание (как должно быть). Вобщем-то вполне себе математичный подход. Теоретически красивый. Да, мы вот сейчас всё пишем и пишем, и на словах, действительно ООП гораздо красивее обычного структурного подхода. Кроме того, можно кучу книжек писать, ООП - богатая среда для мудрствований, например, вот те же замечательные философствования о шаблонах и рефакторинге. Так же как и функциональное программирование, а когда оно ещё и с монадами, то вообще, ууУУух как поумничать можно и статьи пописать.
C же освобождает от необходимости проектировать строго определённый интерфейс, конечно, от ответа на вопрос: что код должен делать? уйти вряд ли удасться, но ответ этот может быть достаточно нестрогим. Язык ориентирован на работу с данными, а не объектами. Если я совершу ошибку на этапе придумывания интерфейса, то мне никто не мешает напрямую залезть в структуру данных, и написать новый код для работы с ней, в том месте, где он нужен. Да, это грязно, это не математично, это нарушение кучи принципов, об этом не напишешь умную книжку, потому что это глупо, но это работет. И работает не только корректно, но и эффективно. Если подобный код мне нужен будет во многих местах - родилась абстракция - я его вынесу в соответсвующий модуль, и доступ к нему сделаю частью интерфейса.
Мог бы я подобное обнаружить на бумажке? Запросто, если бы писал на бумажке настоящую программу, до уровня операторов и вызов функций, а не просто рисовал бы стрелочки, то наверняка обнаружил бы то же самое. Но на бумажке невозможно написать нечто более или менее сложное.
Я могу предполагать, что в этом случае списки эффективны, но на реальных данных может оказаться, что они убивают производительность, или, вдруг оказывается, что для реализации некоторой возможности в новой версии нужно обращение к произвольному элементу. Если я это всё буду учитывать только после того, как напишу программу на бумажке, потом закодирую на ООП, потом откомпилирую, потом пойму, что все мои расчёты, мягко говоря, некорректные, потом опять сяду за бумажку... Я рискую ни одной эффективной программы за всю жизнь не написать.
В итоге, конечно, у меня тоже появляются объекты в программе, но границы у них не жёсткие, а размытые, и объекты именно появляются, а не спускаются сверху. Не тотальная закапсулированность позволяет упростить взаимодействие, особенно, при использовании в новом коде. А то, что объект возник естественным путём освобождает меня от необходимости прописывать какую-то невостребованную функциональность.
Да, всё то же самое можно делать и на C++, например. Но тогда надо будет делать все данные и методы изначально открытыми, и возникает вопрос, а зачем тогда этот весь этот лишний классовый синтаксис?
Ещё можно сказать, что в Smalltalk именно так формировались интерфейсы. Они формировались снизу вверх. Они возникали, а не навязывались сверху. Наследования же вообще не было. Все эти, на мой взгляд, сложности, связанные с проектирование сверху вниз, появились в компилируемых языках, в которых для повышения эффективности стали путать типы и объекты.
И последнее замечание: в книжках по функциональному программированию, обычно, всё истолковывается в терминах и примерах из императивных языков программирования, поэтому, в них со сравнением с другими технологиями всё лучше.
Функциональное программирование больно той же самой болезнью: нужно проектировать задом наперёд. Сначала проектируется общий вид основной функции, а потом всё ниже и ниже проектируются вспомогательные. То же самое в ООП: сначала проектируем интерфейс, а потом пытаемся реализовать. И если интерфейс оказался неподходящим, то переделывать придётся весь код.
В случае же если вы начали проектировать снизу-вверх, а сверху-вниз то у вас может получиться не совсем, то что вы хотели и вам прийдется переделывать или интерфейсы или код. Особой разницы в стоимости ошибки при проектировании сверху вниз или снизу вверх нет. И там и там могут быть дорогостоящие ошибки.
Оба подхода заставляют по форме (что должно быть) определить содержание (как должно быть). Вобщем-то вполне себе математичный подход. Теоретически красивый. Да, мы вот сейчас всё пишем и пишем, и на словах, действительно ООП гораздо красивее обычного структурного подхода. Кроме того, можно кучу книжек писать, ООП - богатая среда для мудрствований, например, вот те же замечательные философствования о шаблонах и рефакторинге. Так же как и функциональное программирование, а когда оно ещё и с монадами, то вообще, ууУУух как поумничать можно и статьи пописать.
Конечно и то и то дает богатую возможность для теоретизирования так как дает очень мощный механизм абстракции. Как собственно и высшая математика. Если так цепочку выстраивать можно сказать, что и ООП зло, а высшая математика вообще зло :) Хотя и то и то всего лишь инструменты.
C же освобождает от необходимости проектировать строго определённый интерфейс, конечно, от ответа на вопрос: что код должен делать? уйти вряд ли удасться, но ответ этот может быть достаточно нестрогим.
А кто вам сказал, что в C++ или любом другом языке мне требуется проектировать очень строгий интерфейс? Я могу определить где-то так. Дальше уже расширить интерфейс и где-то пару методов.
Язык ориентирован на работу с данными, а не объектами. Если я совершу ошибку на этапе придумывания интерфейса, то мне никто не мешает напрямую залезть в структуру данных, и написать новый код для работы с ней, в том месте, где он нужен.
А кто вам мешает делать тоже самое в C++? Объекты кстати гараздо четче распределяют где, что стоит делать в отличии от C. В результате модифицировать ООП код часто удобнее чем структурный код.
Да, это грязно, это не математично, это нарушение кучи принципов, об этом не напишешь умную книжку, потому что это глупо, но это работет.
Глупо и не математично не предерживаться структурирования программы. Если в ООП у вас код структурируется за счет собственно объектного подхода, то в случае процедурного программирования вам надо думать над этим самому. Да это бывает эффективно. Особенно в том случае если сложность проекта не высока. Так как в этом случае начинается перевозка кучки песка карьерным самосвалом.
Мог бы я подобное обнаружить на бумажке? Запросто, если бы писал на бумажке настоящую программу, до уровня операторов и вызов функций, а не просто рисовал бы стрелочки, то наверняка обнаружил бы то же самое. Но на бумажке невозможно написать нечто более или менее сложное.
На бумаге надо написать как оно возможно будет работать. Конечно если вы используете восходящую методику программирования, то она вам как мертвому припарка. Для меня же это вещь позволящая экономить кучу времени.
В итоге, конечно, у меня тоже появляются объекты в программе, но границы у них не жёсткие, а размытые, и объекты именно появляются, а не спускаются сверху.
В результате вы можете получить не самую удачную реализацию которая или не будет содержать каких либо второстепенных, но необходимых объектов или же содержать не нужные объекты. К тому же ваша система может получиться плохо расширяемой и масштабируемой именно из-за проектирования восходящего проектирования.
Не тотальная закапсулированность позволяет упростить взаимодействие, особенно, при использовании в новом коде. А то, что объект возник естественным путём освобождает меня от необходимости прописывать какую-то невостребованную функциональность.
В большинстве случаев взаимодействие может быть сложнее, а не проще. И использовать ваш объект или расширять его будет сложнее.
Да, всё то же самое можно делать и на C++, например. Но тогда надо будет делать все данные и методы изначально открытыми, и возникает вопрос, а зачем тогда этот весь этот лишний классовый синтаксис?
Можно. Но если вам необходима именно такая структура, то вам стоит посмотреть python, там как раз так. Меня иногда раздражает.
Все эти, на мой взгляд, сложности, связанные с проектирование сверху вниз, появились в компилируемых языках, в которых для повышения эффективности стали путать типы и объекты.
Они появились ровно в тот момент когда Страуструп захотел получать хорошо расширяемый и повторно используемый код. Увы для этого требуется проектирование сверху вниз.
в книжках по функциональному программированию, обычно, всё истолковывается в терминах и примерах из императивных языков программирования, поэтому, в них со сравнением с другими технологиями всё лучше
Обычно только самое начало.
О чём, собственно, и речь. Либо я должен ограничивать полёт своей мысли некими шаблонами, которые вполне могут не вписываться в решаемую задачу, а для этого изучать много умных слов и тратить время, которое я могу потратить на разработку алгоритмов. Или я сам должен придумать шаблоны, но тут опять полезут сложно исправляемые глюки в будущем.
И я должен буду выполнять много сложной работы по переписыванию кода, настолько сложной, что для этого появляются автоматизированные средства.
И я должен буду выполнять много сложной работы по переписыванию кода, настолько сложной, что для этого появляются автоматизированные средства.
Вам определённо следует учесть, что я прочитал 'Шаблоны' : ) И ничего нового для себя не открыл, всё то же самое, но не феноменологически: в этом случае делаем так, а в этом так, а в третьем задом-наперёд - а на гораздо более строгом и детальном уровне, в реальном коде, а не в стрелочках, описано у Бадда в 'ООП в действии' или у Голуба в 'правилах программирования на C и C++'.
Про OS/2 грубовато сказано. Более правильная версия жизнеописания OS/2 была запощена на Хабре некоторое время назад.
А про C вообще сказано с позиции "современного российского программиста". Спрос на программистов низкого уровня есть, и средняя з/п сишника выше средней зарплаты явера. Только при этом средний явер это студент, который хочет денег, а средний сишник это специалист по алгоритмике и светлая голова (потому что если он не такой, то не принесет никакой пользы в сферах, где пишут на С :))
А про C вообще сказано с позиции "современного российского программиста". Спрос на программистов низкого уровня есть, и средняя з/п сишника выше средней зарплаты явера. Только при этом средний явер это студент, который хочет денег, а средний сишник это специалист по алгоритмике и светлая голова (потому что если он не такой, то не принесет никакой пользы в сферах, где пишут на С :))
Не соглашусь про ColdFusion.
вот, кстати, свежий обзор текущих вакансий: http://abava.blogspot.com/2007/05/blog-p…
По-моему все время уменьшается доля C на рынке, но не количество вакансий. Так ведь и было задумано, одни занимаются основанием (C), а другие стенами (C#, Java, PHP и т.д.).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Десять вымирающих профессий в сфере IT