Здравствуйте, vdimas, Вы писали:
V>Да нет, ты просто потерял нить разговора и уже давно. Вся ветка была о "клевом подходе" к разработке веба на LISP в эпоху CGI.
В данном случае обсуждалась исключительно адекватность вывода.
V>blah-blah-blah... V>для тебя С++ — как красная тряпка для быка, удивляться его использованию в реальных проектах ты способен (намерен?) бесконечно.
Я вообще это не обсуждал. Еще раз тебе повторяю, что ты сражаешся с ветренными мельницами. Но если тебе охота получить вопрос о применении С++ в веб-проектах, то отвечу. Я таких людей считаю фанатиками и маньяками не способными принять адекватное решение.
Что же до С++ и красных тряпок... то мне плевать на этот язык. Просто его слишко часто суют во все дыры. Это и раздражает.
V>>>Я лишь добавил пару комментов к их выбору...
VD>>А они тебя просили?
V>А тебя?
V>Ты привел с потолка взятый аргумент, насчет длины цикла, который я и оспорил. Занятно уже то, что твой же аргумент никак не относился к твоей же логике...
Извини, но большей неадекватности на этих форумах встретить тяжело. Я не приводил никаких аргументов по длиннам циклов. Я заметил банальный алогизм в рассуждениях. Если ты не понял моих слов, то просто збудь их. Мне этот бессмысленный разговор порядком надоел.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Понимаеш ли. Твои слова про сложность С++ — это не правда. Как язык C# значительно сложнее. Он обладает куда большим объемом кострукций не говоря уже о их применении.
VD>Сам С++ относительно простой язык. Сложно же в нем обходить грабли. Вот тут действительно нужно выроботать привычку использовать только безопасные паттерны. Ну, и сложно следить за теми самыми мелочами. Однако сложность использования и сложность продукта не коррелирую между собой. К примеру, телевизор очень не простой продукт, то использовать его может трех-летний ребенок.
мне кажется — количество конструкций языка не говорит о его сложности.
Сложность языка — это наскольно сложно на нем писать КАЧЕСТВЕННЫЙ КОД.
Здравствуйте, mogadanez, Вы писали:
M>мне кажется — количество конструкций языка не говорит о его сложности. M>Сложность языка — это наскольно сложно на нем писать КАЧЕСТВЕННЫЙ КОД.
Сложность может расматриваться с разных точек зрения. Так что и да, и нет.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
P>>Сложнее будет не только реализация, но и использование.
VD>Ровно настолько насколько делать вызовы методов на ассемблере нежели на языке высокого уровня.
А что, (хотя бы) этого недостаточно??
В ассемблере не хватает многого из того, к чему привыкли пользователи ящыков высокого уровня. Например, такие возможности, как вычисление выражений, или "управляющие" конструкции (ветвление, циклы). Это тоже не абстракции?
P>>Удобнее для тех, кто реализует, и для тех, кто использует. Вроде object->do_it() удобнее писать, чем object->vtbl->do_it(object). (А если бы не было понятия указателей на функции — вообще бы ужас получился.)
VD>Не нужно привлекать сюда заморочки КОМ-а. На С можно писать и так: VD>
VD>do_it(object);
VD>
VD>Это конечно не винец творения, но более чем приемлемо.
Я имел в виду именно полиморфный вызов.
P>>Ну, все-таки не изменение, а скорее уточнение синтаксиса.
VD>Нет, это именно изменение. Только конечно не синтаксиса, а семантики. Но это уже не важно.
Действительно, не важно... Хотя с изменением семантики можно и поспорить.
P>> Причем имеющее своей целью именно предоставление пользователю абстракции операции вывода, работающей для расширяемого множества типов потоков и расширяемого множества типов данных.
VD>Нда. Ну, и чем: VD>
VD>stdхзч << i;
VD>
VD>абстрактнее чем: VD>
VD>print(i);
VD>
VD>
Если второй код — это C, то он хуже отсутствием полиморфизма времени компиляции. Я же явно написал про "расширяемые множества типов" (потоков и выводимых значений).
А так же тем, что для вывода нескольких значений нужно повторять много раз print.
VD>>>Причем основанное на безолаберном отношении языка к безопасности кода.
P>>Это почему??
VD>Потому что в оригинале << это побитовый сдвиг влево.
И что? Дизайн языка (C++) предполагает переопределение операторов, и стандартная библиотека потокового ввода-вывода C++ вполне корректно это использует. Нарушения безопасности кода здесь IMHO нет, т.к. для введение нового operator << никоим образом не влияет на существующий код, использующий операцию побитового сдвига для работы с целыми числами.
VD> Плюс используется ошибка языка допускающая вычисления значений без присвоения их в переменную или передачи в качестве параметра.
То, что это ошибка — тема для holy war. По мне — так это штатная "фича" языка, без которой, может быть, невозможно было бы реализовать тот же "цепочечный" operator <<. Хотя с точки зрения чистой идеологии она, действительно, нежелательна.
P>>Возьмем, к примеру, C. Его printf-семейство абстрагирует вывод, но "не дотягивают" до operator << (отсутствие безопасности типов, необходимость явно указывать тип выводимых данных, полное отсутствие расширяемости).
VD>Чушь какая-то причем тут безопасность типов? Господа, отделяйте мухи от котлет.
Безопасность типов в данном случае — это вполне объективное преимущество operator << перед printf(). Хотя, возможно, и не относящееся к теме абстрагирования.
Да, кстати: товарищи, будьте взаимовежливы.
VD>Отсуствие расширяемости тоже звучит забавно. Создай новую процедуру и делай в ней все что хочешь.
Я не хочу каждый раз (для каждого нового типа) создавать новую процедуру (точнее, процедуру с новым именем). Если это делать, код, выводящий значения (в консоль или куда-то еще) становится менее единообразным, менее простым и больше привязанным к реализации — т.е. "качество" абстракции ухудшается. Кроме того, это не позволяет по-нормальному использовать существующий код (хотя этот аргумент становится по-настоящему важен только при наличии шаблоков — или при использовании макросов C).
Явное указание типов значений — это туда же (к ухудшению качества абстракции).
P>>Кстати, складывается впечатление, что у нас существенно разные понятия об абстракции. Определимся с определениями?
VD>Нет, проблем — Abstraction (computer science)
Да, это вполне можно принять за основу:
In computer science, abstraction is a mechanism and practice to reduce and factor out details so that one can focus on few concepts at a time.
"Reduce and factor out details" — это и более короткая запись вызова процедуры (C cs ASM), и не "перегруженная" строкой форматирования, единообразная запись cout << i (C++ vs C), и in place создание функции типа (lambda (person) (display (name person))) (Lisp vs C/C++/C#/Java).
P>>А какая суть? А то контекст, в котором было упоминание Spirit, что-то затерялся.
VD>Суть в том, что это не библиотека предоставляющая примитивы.
Примитивы эта библиотека предоставляет, только они (в основном) не независимы, а формируют "язык", с помощью которого специфицируется парсер. Хотя там есть и большой кусок (Phoenix), который можно использовать отдельно.
P>>Это не внутренние классы, а вполне даже внешний интерфейс, описанный в документации.
VD>Можно ссылку на то, о чем ты ведешь речь?
Здравствуйте, pvgoran, Вы писали:
P>А что, (хотя бы) этого недостаточно??
Для чего?
P>В ассемблере не хватает многого из того, к чему привыкли пользователи ящыков высокого уровня. Например, такие возможности, как вычисление выражений, или "управляющие" конструкции (ветвление, циклы). Это тоже не абстракции?
Видимо я как-то очень туманно изъясняюсь. Попробую по проще...
Я не призываю программировать на ассемблере. Я просто сказал, что абстракции можно добиться практически на любом языке программирование.
P>Я имел в виду именно полиморфный вызов.
Полиморфный вызов на С может выглядеть так:
SomeFunctionPointer();
P>Если второй код — это C, то он хуже отсутствием полиморфизма времени компиляции.
В С вообще с полиморфизмом не зашибись. Но с точки зрения абстракции разницы, согласись, нет никакой.
P> Я же явно написал про "расширяемые множества типов" (потоков и выводимых значений).
А я ясно написал "не путай теплое с мягким".
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В данном случае обсуждалась исключительно адекватность вывода.
Ok, адекватность — суть соответствие чему-либо. Продолжим.
VD>Я вообще это не обсуждал. Еще раз тебе повторяю, что ты сражаешся с ветренными мельницами. Но если тебе охота получить вопрос о применении С++ в веб-проектах, то отвечу. Я таких людей считаю фанатиками и маньяками не способными принять адекватное решение.
А ты уверен, что JSP-технология (была как вариант в обсуждаемой теме) образца 3-х летней давности способна выдержать нагрузку многих тысяч одновременно работающих пользователей? Я че-то не уверен. Кстати, сам движок Google на чем написан? А Yahoo? A Alta-Vista? Не надо путать RAD-подход к разработке и подход: "мы спустимся медленно, и отымеем все стадо".
VD>Что же до С++ и красных тряпок... то мне плевать на этот язык. Просто его слишко часто суют во все дыры. Это и раздражает.
Нифига себе дыры — самые крутые поисковые движки. А теперь еще и store-движки. Да блин, трудоемкость презентационной части веба в подобных задачах не видна и под микроскопом.
Если бы они для подобных задач взяли Java или там (не дай бог) PHP, то "Я таких людей считаю фанатиками и маньяками не способными принять адекватное решение." (С) VlaD2.
Фронт-енд к движку мог быть написан на чем угодно. Хотя, это уже не суть важно т.к. может не дать значительно выигрыша в скорости-качестве разработки (надо же будет обертки над нативом писать, в Java это не так просто как в .Net, т.е. приличного выигрыша трудоемкости не получим).
VD>Извини, но большей неадекватности на этих форумах встретить тяжело. Я не приводил никаких аргументов по длиннам циклов. Я заметил банальный алогизм в рассуждениях. Если ты не понял моих слов, то просто збудь их. Мне этот бессмысленный разговор порядком надоел.
vdimas wrote:
> VD>Я вообще это не обсуждал. Еще раз тебе повторяю, что ты сражаешся с > ветренными мельницами. Но если тебе охота получить вопрос о применении > С++ в веб-проектах, то отвечу. Я таких людей считаю фанатиками и > маньяками не способными принять адекватное решение. > А ты уверен, что JSP-технология (была как вариант в обсуждаемой теме) > образца 3-х летней давности способна выдержать нагрузку многих тысяч > одновременно работающих пользователей? Я че-то не уверен.
BEA Inc. с тобой не согласна. Кстати, еще в 2000 году свободный
JSP-сервер Tomcat спокойно держал тысячу запросов в секнду на хорошем
железе.
> Кстати, сам движок Google на чем написан? А Yahoo? A Alta-Vista? Не > надо путать RAD-подход к разработке и подход: "мы спустимся медленно, > и отымеем все стадо".
Еще раз (последний) я утверждений не делал. Я высказал мысль, что если кто-то посчитал, что Ява и т.п. дают какую-то выгоду по сравнению с лиспом, то на основании этого архи глупо и нелепо принимать решение о переписывании софта на С++.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>AltaVista вот как раз на Java написана.
Откуда дровишки? Скорее, речь идет о презентационной части (и то не факт)? И разве имеет значение, на чем написана презентационная часть, тем более подобной "сложности".
Насколько я помню, самая первая ферма серверов Alta-Vista крутилась на DEC-Alpha серверах еще с 95-го или 96-го года, и никакой Джавы в движке не было и в помине. Да и в более поздних коммерческих версиях их движка — тоже.
в догонку
C>BEA Inc. с тобой не согласна. Кстати, еще в 2000 году свободный C>JSP-сервер Tomcat спокойно держал тысячу запросов в секнду на хорошем C>железе.
vdimas wrote:
> C>BEA Inc. с тобой не согласна. Кстати, еще в 2000 году свободный > C>JSP-сервер Tomcat спокойно держал тысячу запросов в секнду на хорошем > C>железе. > Кстати, тысяча и десятки тысяч — разные вещи.
vdimas wrote:
> C>AltaVista вот как раз на Java написана. > Откуда дровишки?
C theserverside'а вестимо...
> Скорее, речь идет о презентационной части (и то не факт)? И разве > имеет значение, на чем написана презентационная часть, тем более > подобной "сложности".
Как раз фронтенд у них написан в виде модулей к апачу, а поисковый бот и
сама логика поиска — на Java. Об этом была статья на theserverside'е
году так в 2001.
> Насколько я помню, самая первая ферма серверов Alta-Vista крутилась на > DEC-Alpha серверах еще с 95-го или 96-го года, и никакой Джавы в > движке не было и в помине. Да и в более поздних коммерческих версиях > их движка — тоже.
Сначала не было, потом в 99 году там все переписали. Полученый продукт
еще и продавали другим компаниям для внутреннего поиска.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>> и как его реализовать на C#1.
VD>>>Реализовать интерфейс?
ANS>>Поподробнее, пожалуйста.
VD>Что подробнее? В IEnumerator два метода и одно свойство. Их название говорят сами за себя. Плюсь в МСДН для особо одаренных целый рассказ о томк как реализовывать этот интерфейс.
IEnumerator — это внешняя итерация, а речь шла вроде о внутренней.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, pvgoran, Вы писали:
P>>А что, (хотя бы) этого недостаточно??
VD>Для чего?
Переформулирую. То, что для использования абстракции (точнее, процедуры, реализующей абстракцию), нужно написать N нетривиально связанных друг с другом ассемблерных команд вместо одной строчки на C — это существенное уменьшение удобства использования абстракции (некоторые абстракции оно может совершенно обесценить). Для меня это показатель того, что ASM "поддерживает абстракции" хуже, чем C.
P>>В ассемблере не хватает многого из того, к чему привыкли пользователи ящыков высокого уровня. Например, такие возможности, как вычисление выражений, или "управляющие" конструкции (ветвление, циклы). Это тоже не абстракции?
VD>Видимо я как-то очень туманно изъясняюсь. Попробую по проще... VD>Я не призываю программировать на ассемблере. Я просто сказал, что абстракции можно добиться практически на любом языке программирование.
А что значит "можно добиться абстракции"?
1. "Можно реализовать любую абстракцию". Я сомневаюсь, что это возможно сделать в каком бы то ни было ЯП.
2. "Можно реализовать какие-то абстракции". С этим я соглашусь — но это совершенно не относится к теме достаточности процедур для введения любых абстракций.
P>>Я имел в виду именно полиморфный вызов.
VD>Полиморфный вызов на С может выглядеть так: VD>
VD>SomeFunctionPointer();
VD>
Ну да. Только для того, чтобы это был полиморфный вызов, нужно где-то выше написать что-то вроде:
SomeFunctionPointer = object->vtbl->do_it;
P>>Если второй код — это C, то он хуже отсутствием полиморфизма времени компиляции.
VD>В С вообще с полиморфизмом не зашибись.
Совершенно верно, об этом и речь.
VD>Но с точки зрения абстракции разницы, согласись, нет никакой.
Не соглашусь. Полиморфизм позволяет абстрагироваться от того, с объектом какого типа мы имеем дело.
P>> Я же явно написал про "расширяемые множества типов" (потоков и выводимых значений).
VD>А я ясно написал "не путай теплое с мягким".
Не было этого!
А если серьезно — то не поясните ли Вы, где, что и с чем я спутал?
P.S. Вы оставили непрокомментированным довольно большую часть моего сообщения. Означает ли это, что Вы согласны с тем, что там было написано?
Здравствуйте, VladD2, Вы писали:
ANS>>>>Осталось выяснить в каком месте внутренний итератор (кривым отражением которого и есть foreach) не является абстракцией, VD>>>Переведи это на русский. ANS>>Какое именно слово тебе не понятно? VD>Выделенно жирным.
Гм. Мне не понятно что же тебе не понятно
ANS>>>> и как его реализовать на C#1. VD>>>Реализовать интерфейс? ANS>>Поподробнее, пожалуйста. VD>Что подробнее? В IEnumerator два метода и одно свойство. Их название говорят сами за себя. Плюсь в МСДН для особо одаренных целый рассказ о томк как реализовывать этот интерфейс.
Влад, реч идёт о внутреннем итераторе. Для его реализации нужен один метод.
ANS>>>>Влад, абстракция без простоты это фигня какая то. VD>>>На это тебе очень хорошо ответил mihoshi
. ANS>>Уж, извини, не понял я ответа. VD>Точнее не захотел. Ты постоянно путашь понятия. Абстракцию с внешней формой. Простоту абстракции и сложность реализаци скрываемой за абстракцией. У меня складывается ощущение, что ты делашь это намеренно. Если это не так, то просто обратись к словарям. Ну, а если так, то давно пора завязывать этот разговор. Все равно путного ничего не выйдет.
Во-первых, внешний итератор — 2 метода и одно свойство, внутренний — один метод. Вывод: внутренний итератор — абстракция более высокого уровня.
Во-вторых, зачастую сложность реализации чего-либо это почти равнозначно невозможности реализации. То есть результат конечный один и тот же — неиспользование.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Во-первых, внешний итератор — 2 метода и одно свойство, внутренний — один метод. Вывод: внутренний итератор — абстракция более высокого уровня.
Что ты понимашь под словами "внешний итератор"?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ANS>>Во-первых, внешний итератор — 2 метода и одно свойство, внутренний — один метод. Вывод: внутренний итератор — абстракция более высокого уровня.
VD>Что ты понимашь под словами "внешний итератор"?
Извини, но данная теменология не общепринята и довольно не корректна. Все же применение функций высшего порядка новых объектов не создает. А итератор — это в первую очередь объект.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>>> и как его реализовать на C#1. VD>>>>Реализовать интерфейс? ANS>>>Поподробнее, пожалуйста. VD>>Что подробнее? В IEnumerator два метода и одно свойство. Их название говорят сами за себя. Плюсь в МСДН для особо одаренных целый рассказ о томк как реализовывать этот интерфейс.
ANS>Влад, реч идёт о внутреннем итераторе. Для его реализации нужен один метод.
Как я теперь понял "о внутреннем итераторе" — это ты пыташся приплести сюда функции высшего порядка. Ну, и причем тут это? Ощущение такое, что кому-то хочется попереключать тему, чтобы полностью всех запутать.
ANS>Во-первых, внешний итератор — 2 метода и одно свойство,
Во-первых, я не жалаю пользоваться этой терминологией. Во-вторых, методов может быть сколько угодно. В дотнете есть две реализации дженерик и обычная. Дженери расширяет обычную одним свойством.
ANS> внутренний — один метод. Вывод: внутренний итератор — абстракция более высокого уровня.
Агащазблин. Абстракция более высокого уровня должна устранять рассмотрение некоторых, не важных для некоторого случая, деталий. В данном случае ничего поднбго нет. Есть просто функция высшего порядка предназначеная для применения другой функции к списку и объект итератор. Т.е. разные интерфейсы абстракции перебора. Причем с разными характеристиками. Одно убоно в одном случае, другое в дургом.
ANS>Во-вторых, зачастую сложность реализации чего-либо это почти равнозначно невозможности реализации. То есть результат конечный один и тот же — неиспользование.
Замечательные абстрактные рассуждения ничего в прочем не дающие. IEnumerable в дотенете реализуется любой коллекцией. Сложности конечно есть, но не фатальные.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
