информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
 Рекордное число уязвимостей в 2021 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / miscellaneous
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Дык Перл я привел для примера. Во-первых, ты очень не прав... 26.10.05 23:21  Число просмотров: 1080
Автор: 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-скриптами на Си я не замечал.
<miscellaneous> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach