Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Дык Перл я привел для примера. Во-первых, ты очень не прав... 26.10.05 23:21 Число просмотров: 1103
Автор: Heller <Heller> Статус: Elderman
|
> В том же C++ хедер можно подключить и в командной строке, и > мейкфайле, и в настройках проекта для IDE. Это относится к > реализации. А конструктор в том же C++ можно вызвать и > неявно, простым объявлением переменной нужного типа. И это > опять таки связано именно с реализацией, а не с парадигмой.
> Во первых по сравнению с расходами на САМ перл, эти расходы > уже не очень значительны и опять таки они никак не связаны > с ООП. В C++ информация о классах ПОЛНОСТЬЮ теряется на > этапе компиляции (кроме динамического полиморфизма и RTTI, > но это другая история). В конце концов код получается > совершенно идентичным. Вызов метода - просто вызов функции > (ей еще помимо явных аргументов передается неявный this, но > это тоже особенности реализации). > > Так зачем писать на перле? :-) Дык Перл я привел для примера. Во-первых, ты очень не прав насчет "вся информация о классах теряется при компиляции". Представь себе, что объекст создается в результате работы switch, причем имя объекта при любом из условий будет одним и тем же. Стало быть информацию о классах хранить все же надо.
Но я говорил больше не об этом. Вот примерный код метода header:
sub header {
my ($http_head, $name, $content);
shift;
if (!@_) {$http_head="Content-type: text/html\n"}
if ($_[0]!~/^-/&&$_[0]=~#^\w+/\w+$#) {
$http_head="Content-type: $_[0]\n";
shift;
}
while (@_) {
$name=shift;
$name=substr $name, 1;
$content=shift;
$http_head.="$name: $content\n";
}
return "$http_head\n";
} ---
Это я, конечно, на вскидку прикинул - на деле там еще больше условий и проверок, но бредовость использования такого метода для простого вывода "Content-type: text/html", думаю, очевидна. Конечно, этим же страдает почти любая библиотечная функция, а не только методы объектов, но один из постулатов ООП гласит о том, что "пользователя не должно заботить, что происходит внутри объектов". Это и приводит к тому, что появляются совершенно идиотские применения ООП. А если бегиннерса начинать учить сразу с такого безобразия, то что из него вырастет?
> Вывести CGI хедер с типом text/html > Теперь скажи мне, что точнее отражает СУЩНОСТЬ > происходящего? > > Никто не мешает, но попробуй доказать, что код который НЕ > НАДО комментировать (самокомментирующийся) чем то хуже > того, который надо. Сама возможность писать без > комментариев говорит о том, что такой код ПОНЯТНЕЕ. Объясни мне такую вещь: если оператор "print" мне И ТАКПОЛНОСТЬЮПОНЯТЕН, то для чего мне делать его ЕЩЕ БОЛЕЕ ПОНЯТНЫМ?
> Опять двадцать пять. Объектный подход ближе к МЫШЛЕНИЮ > человека и не имеет никакого отношения к школе вообще. Да и > функциональное программирование настолько же далеко от > процедурного, как и объектно-ориентированное. Вот простая программа, соответствующая человеческому мышлению (по аналогии с Паскалем):
Название "хорошо провести время";
Процедура "попить пивка";
Начало
Пойти на кухню;
Открыть холодильник;
Достать пивка;
Попить пивка;
Вернуться;
Конец;
Процедура "пойти покурить";
Начало
Пойти на лестницу;
Достать сигарет;
Покурить;
Вернуться;
Конец;
Процедура "купить" ("продукт питания");
Начало
Найти денег;
Пойти в магазин;
Купить "продукт питания";
Вернуться;
Конец;
Начало
Если нет(пивка) то купить(пивка);
Попить пивка;
Если нет(сигарет) то купить(сигарет);
Пойти покурить;
Конец. ---
Не знаю, как ты, amirul, но лично я обычно рассуждаю именно так. Строго, последовательно, процедурами. Ни о каких объектах я и думать не думаю. Возможно, ты сейчас скажешь, что, мол, "на подсознательном уровне ты всё равно оперируешь объектами", но я тебе отвечу, что оно на подсознательном уровне - в этом пускай разбираются психологи и философы, а не программисты. А я думаю так как я думаю.
> Кстати, очень хочу как нибудь выкроить время и ознакомиться > с haskel, lisp, ml (ocaml). Для расширения кругозора
Ну, фразы "функциональное программирование" я не произносил, а произносил слово "функции". ИМХО, имею на это право (в том же Паскале есть слово такое зарезервированное: Function). Если говорить о функциональном программировании, то я не шибко крутой спец, однако Lisp мельком пробегал - полная ахинея, ИМХО, и выделять это самое как отдельную парадигму я бы не стал. По сути та же самая процедурная парадигма с небольшими нововведениями (сомнительными) и кучей кастраций. Кстати, тот же Lisp тоже не чисто функциональный - там есть практически все элементынормальногопроцедурного языка. А вот непонятно с чего ты несколькими постами выше Си не отнес к функциональным, а Perl отнес "отчасти"? Единственная разница между Си и Перл, которая хоть как-то приближает последний к Лисп - это возможность возвращать в качестве результата функции списки и наличие команды eval. Хотя и то и другое к самой парадигме функционального программирования не имеет отношения, насколько я понимаю. Ну да это оффтоп уже, да и тема ИМХО не шибка интересная, чтобы ее обсуждать.
> > 4. Насчет строк, массивов и переменных. Кто-то из > философов > > сказал: "Не надо плодить сущности без надобности". > Чтобы > > Это Оккам был Спасибо :)
> > работать со всем перечисленным, надо в любом случае > > понимать, что это такое на уровне структур данных. > > ЖЕЛАТЕЛЬНО. Но не обязательно. Беггинеру и вовсе не нужно Видимо, мы друг друга не правильно поняли. Я не имею ввиду, что бегиннерсу надо объяснять про принципы, что массив - это последовательная область памяти, которая рассматривается как набор переменных, для получения доступа к которым используется смещение от нулевого элемента массива и пр. и пр. Достаточно сказать, что "массив - это упорядоченный набор переменных, к которым мы обращаемся по номеру". Точно так же "строка - массив символов". Я привел минимальное определние, без которого работать вообще невозможно (хотя насчет строк это утверждение и сомнительно, ну да не суть важно). Никакие объекты уйти от того, что я сказал в кавычках, не помогут, как не крути. Да и потом это и так просто, для того, чтобы прикручивать сюда еще какие-то абстракции.
> >Дополнительновспоминать в данном случае о ООП - > излишняя > > нагрузка информацией, которая по сути является > абстракцией > > и не несет никакого прикладного смысла. > > Как это излишняя? Избыточность практически всегда несет > единственный смысл - помехозащищенность. Во всем начиная от > человеческой речи, контрольных сумм для архивов и > заканчивая грамотной типизацией ЯВУ. Чем более избыточный > язык, тем меньше будет ошибок в программе на нем. Только > надо сделать так, чтобы избыточность не раздражала > программеров (они таки зачастую лентяи), а то вообще не > будет никаких программ на этом языке. Вот опять. Объясняю еще раз: избыточность - это замечательно. Но есть такой уровень, после которого избыточность уже перестает играть какую-то роль, так как возрстание объема начинает оказывать всё меньше эффекта на помехозащищенность. Я это говорю не о тенденции в целом, а о конкретных цифрах.
> А ООП - всего лишь способ структурирования информации и > уменьшения количества взаимосвязей во все возрастающих > программах У тебя одержимость "все возрастающими программами"? Ещё раз (чисто для избыточности): мы говорим про бегиннерсов. Бегиннерсы не пишут "большие проекты". Они пишут "калькулятор", "звездное небо" и "угадай число".
> > 5. В любом случае, используя объектно-ориентированный > > подход, ты не убежишь от того, что придется рано или > поздно > > создавать собственные классы и методы. А это есть ни > что > > иное как написание тех же функций. В случае функций > ты, > > конечно, тоже к объектам придешь, но зато уже с > изначальным > > умением писать собственные классы и методы. Если же > знать > > ООП, но не уметь писать функции, то это уже умственный > > Поговорим о сферических людях в вакууме. Не понял твоей эронии.
> > > инвалид получается (кстати, если возвращаться к тому > коду > > на Perl, что я привел выше, то основная масса людей > > использует именно первый способ, а не простой print, > именно > > потому, что по-другому они не умеют - а из-за этого > > огромные потери и падение эффективности). > > Ну насчет огромных ты погорячился. Перл все таки умеет > прекомпилировать и "огромная" потеря выйдет только после > первого раза. Кроме того, если в твоем случае так важна > эффективность советую писать на C/C++. Выводить на stdout > они умеют не хуже перла, библиотек регекспов до фига, а > скорость вырастет в разы (если не на порядки). Оффтоп, конечно, но в вебе использование Си не спасает. Тут надо прикручивать либо Fast CGI, либо mod_perl. Кстати, большого падения производительности mod_perl по сравнению с Fast CGI-скриптами на Си я не замечал.
|
|
|