ЗХ>>Я давеча для себя сформулировал, что, вообще говоря, есть два "совсем разных" ООП — "мейнстрим-ООП" и "радикальное ООП".
ЗХ>>Мейнстрим-ООП — это то, что пошло от Симулы и наиболее чисто (почти без грязи-для-большей-практичности) выражено в Eiffel. У него ноги растут от "стремления структурности", главный лозунг — "основная единица организации кода — это класс" ("класс" здесь, — это в душе всегда "модуль на стероидах"). Т.е. предлагается думать о программе в терминах "декомпозиции на классы".
ЗХ>>Радикальное ООП — пошло от Smalltalk (точнее, от некоторых более ранних разработок, но эту деталь мы опустим). У него ноги растут от "стремления к естественности и простоте", главный лозунг — "все есть объект", "программа это взаимодействие объектов". Классы здесь могут быть (Smalltalk, Ruby), а может и не быть (Self, Io) — это как бы вторичная по отношению к объекту сущность; все потому, что классы — это тоже объекты, но со специализированной задачей.
BZ>имхо твоё разделение — на самом деле статические языки портив динамических, и все вытекаюбщие отсюда плюшки. в eiffel тоже everything is object, это c++/java — языки со смешанной парадигмой, в c# опять все данные — объекты, за исключением unmanaged кода
Хм. Похоже, мне пора фиксить mental model. Чегой-то у меня с everything is object в яве и эйфеле не укладывается в голове. Буду учиться.
ЗХ>>ЗЫ: кстати, высказывания на тему "Ruby — это правильный Smalltalk" считаю примерно настолько же экстремистскими как "Nemerle — это правильный Haskell" (хотя, кажется, я знаю человека, который с последним согласится).
BZ>руби порсто имеет все средства смолтока, насколько я в курсе. его объектная модель — именно смолтоковская. плюс к этому удобный синтаксис из паскале-подобных языков
Я же не зря, как аналогию, Хаскель привел В Руби идеи "радикального (динамического) ООП" несколько "запачканы" смешением нескольких методологий, удобством синтаксиса и т.п. (например, в Руби структурные конструкции типа if, while и проч. не являются сообщениями).
BZ>кстати, я впервые слышу про предшественников смолтока. не расскажешь зотя бы вкратце о них?
Ну, откуда "черпались идеи" — это были Lisp, Logo, та же Simula. Но вот откуда была взята основная идея "супа из объектов" — это (сюрприз!) программа Sketchpad, над которой Иван Сазерленд работал некоторое время совместно с Кеем (в смысле, ее написал Сазерленд, а Кей на каком-то этапе поучаствовал). Так вот там, на ассемблере PDP-11 (емнип), и был создан соответствующий DSL, понятие моря/супа объектов и т.п. Кои Кей впоследствии адаптировал к Smalltalk (привнеся классы из соображений, по-моему, эффективности — изначальные идеи Сазерленда были ближе к Self и "прототипной орканизации").
Примерно так.
E>Нет в C++ штатных средств получения аргументов метода в виде одного объекта (т.е. никакого экземпляра кортежа получить нельзя). Да, если компилятор не засовывает аргументы в регистры, то хаками на ассемблере можно получить копию стекового фрейма, но к языку это не имеет отношения.
У меня вопрос к господам, поставившим минусы на мое сообщение. Как известно, практика -- критерий проверки теории. Итак, хотелось бы увидеть практический пример интерпритации параметров функции в C++ в качестве объекта-кортежа (будь то передача параметров при вызове или получения всех параметров внутри функции в качестве объекта-кортежа). Стандартными средствами языка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>>Нет в C++ штатных средств получения аргументов метода в виде одного объекта (т.е. никакого экземпляра кортежа получить нельзя). Да, если компилятор не засовывает аргументы в регистры, то хаками на ассемблере можно получить копию стекового фрейма, но к языку это не имеет отношения.
E>У меня вопрос к господам, поставившим минусы на мое сообщение. Как известно, практика -- критерий проверки теории. Итак, хотелось бы увидеть практический пример интерпритации параметров функции в C++ в качестве объекта-кортежа (будь то передача параметров при вызове или получения всех параметров внутри функции в качестве объекта-кортежа). Стандартными средствами языка.
Минус не поставил, но могу Потому как не согласный я тоже.
Ты говорил о синтаксисе и деталях реализации. А сентенция "параметры функции суть кортеж" — говорит о _семантике_.
То есть, вот эту запись:
foo(1, "a", &c)
Вполне можно, с определенной точки зрения, рассматривать как "функцию foo, которая принимает на вход кортеж параметров и статически контролирует количество и тип элементов кортежа". Да, с точки зрения языка с полноценным кортежами — это весьма ограниченные возможности, но ведь и, к примеру, "функторы" в плюсах тоже странноватые, а ничего, пользуемся.
Ну и, возвращаясь к тому, с чего была поднята эта тема, метафора кортежа была употреблена вполне корректно, в диалоге "зачем возвращать из функции кортеж (список разнотипных значений)? — затем же, зачем мы передаем в функцию кортеж (список разнотипных значений)?"
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Вполне можно, с определенной точки зрения, рассматривать как "функцию foo, которая принимает на вход кортеж параметров и статически контролирует количество и тип элементов кортежа".
Так вот по моему мнению, в рассмотрении с такой точки зрения передачи параметрам функции в C++ нет никакого практического смысла. Т.е. это чистое теоритизирование, не имеющее сухого практического остатка. А посему -- теоритизирование, сильно оторванное от действительности.
Более того, приведенная тобой запись мало чего контролирует на самом деле:
ни при компиляции, ни при исполнении, никто не даст по рукам за то, что в функцию real был передан совсем другой кортеж.
ЗХ>Ну и, возвращаясь к тому, с чего была поднята эта тема, метафора кортежа была употреблена вполне корректно, в диалоге "зачем возвращать из функции кортеж (список разнотипных значений)? — затем же, зачем мы передаем в функцию кортеж (список разнотипных значений)?"
Ничего не имею против возврата кортежей из функций в языках с поддержкой кортежей. Но, имхо, проводя аналогии и используя примеры нужно придерживаться объективной реальности. На практике нет в C++ кортежей, поэтому использование C++ в качестве примера использования кортежей при вызове функции не корректно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>То есть, вот эту запись: ЗХ>
ЗХ>foo(1, "a", &c)
ЗХ>
ЗХ>Вполне можно, с определенной точки зрения, рассматривать как "функцию foo, которая принимает на вход кортеж параметров и статически контролирует количество и тип элементов кортежа".
С другой точки зрения это же можно рассматривать как "функцию foo, которая принимает на вход целое и возвращает функцию foo(1), которая принимает на вход строку и возвращает функцию foo(1, "a"), которая принимает на вход указатель...". Да, с точки зрения языка с полноценным ФВП — это весьма ограниченные возможности, но ведь и, к примеру, "функторы" в плюсах тоже странноватые, а ничего, пользуемся.
Здравствуйте, VladD2, Вы писали:
BZ>>ну а тезнически запрет таких вызовов, заодно с явным описанием плорядка вызова процедур, решается "эстафетной палочкой" — фиктивным значением типа RealWorld, передаваемым от порцедуры к процедуре, и недоступным функциям. т.е. функция не может вызвать процедуру потому, что она такую эстафетную палочку не получает сверху, и не может создать её сама
VD>В лес всю фикцию. Проблема рашается намного проще. Надо всего лишь отказаться от пуританства.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>семантика — смолток, синтаксис — эйфель, фичи — перл. вообще, руби — это просто фантастическая коллекция наиболее удачных решений из разнообразных языков.
Это можно сказать об очень многих ЯП. Вот только в случае с Руби, на мой взгляд, не все решения удачные. Много и не удачных.
BZ> например, в книге "жемчужины прогшраммирвания" описан гипотетический язык с очень удобным операторм case. нигда в реальных яхзыках такого так и не сделали. кроме руби!
Ты меня конечно извини, я возможно полохо знаю руби, но мне кажется, что никакой case не может сравниться с паттернм-мачтингом. Приведи, плиз, пример этой крутости.
BZ>не видел ни ту, ни другую, ни третью, так что могу ошибаться.
100% ошибаешся.
BZ>но фишка в том, что смолток динамчисекий язык и в его среде во-первых ты работал непосредтсвеенно с классами, а не исходными файлами, во-вторых, мог проверить работу любой функции непосредственно запустив её
Все то же самое сегодня доступно и для императивных языков. Единственное чего нет — это возможности менять классы на лету (во время исполения программы), но это уже не заслуга Смолтока и не ограничение C#-а, а заслуга Динамики и интерпретации и не ограничение статики и компиляции. Собственно эта фича так же приводит и к другому эффекту — невозможности контролировать ошибки до вызова методов. Что уже становится ограничением динамики, и заслугой статики.
BZ>что означает "уникальные идентификаторы"? я вообще лучше знаю английскую терминологию
Это относится к системе типов Хаскеля. Точнее примитивности системы Хинли-Миллера. Она конечно позволяет довольно ээфективно выводить типы, но страдает достадными ограничениями вроде невозможности перегрузки функций по имени. Например, мы не можем определить свойство (метод, поле, функцию) "x" у типа Point и скажем у типа Point3D. Разруливание на уровне модулей не катит, так как оба типа данных могут понадобиться в одном коде. Посему фукнции начинают вбирать в себя префиксы вроде pointX и point3dX. Сто лично мне очень не наравится. И вообще, я привык к "излишествам" рожденным С++: перегрузка, неявные приведения типов, объекты...
BZ>вместо C# и Delphi с теоретической точки зрения лучше изучать Eiffel, это дейсвтивительно красивый и мощный язык с чистой ООП идеологией.
А нафиг теоритическая точка зрения не нужна при выборе языков для обучения. Eiffel как и Смолток прошляпили свое время. Так что учить надо C# и Ruby, а про Eiffel и Смолток можно потом (или в процессе) рассказать и сказать, что мол так и так имеют такие-то особенности.
В конце концов проблем у этих языков выше крыши. Тот же Eiffel уступает Немерлу и Spec#-у в олласти декларации инваринатов и пред/пост-условий, так как Eiffel порождает только рантайм-проверки, а Немерле и Spec# повзоляют многое контролировать во время компялции с помощью Буги (утилиты из Spec#).
BZ> руби отличается от него динамической титпизацией, это отдельная парадигма со своими преимуществами и недостатками
Я уже сказал, что Руби и C# являются представителями разных подходов. Причем живыми предтавителями. Можно без проблем найти работу на обоих. Особенно на Шарпе.
BZ>есть. я вроде и говорил про эти два языка, ты не заметил?
Пунктик то?
VD>>С каких пор Пролог стал ФЯ?
BZ>логичнсеколе программирование — тоже мощная, хотя и медлительная парадигма
Парадигм не может быть медленной. Медленные реализации. И понятно почему. Но опять же, то что ЛП интересно не значит, что оно равно ФП. Это разные вещи.
BZ>имхо после выражений нужно переходить к более сложным выражениям
Вот тут мы с тобой расходимся. Я как раз читаю, что выражения — это база. А "сложне выражения" — это фукнциональная надстройка. И ее логично было бы давать параллельно с императивно-объектоориентированной надстройкой. Так человек не прикипит к одной парадигме и раньше поймет истенную суть вещей.
Блни, зать за обучение не платят хороших денег.
VD>>Что касается языка, то я бы как раз выделил на роль первого языка Немерле или Руби. Руби я бы посоветовал тем учетилям которые считают, что вначале людям не надо морочить голову с типизацией, а Немерле тем кто считает, что типизация важнеший аспект. Ну, и по той причине, что на немерле можно показать практически все приемы кроме разве что ЛП.
BZ>вот именно, и ничего хорошего я тут не вижу.
А что плохого? Хрошее же то, что все можно продемонстрировать в чистом виде по одтельности и в смесе.
BZ> мимхо, надо изучать разные параддигмы по их чистым представителям, а не язык, где они как-то сбиты вместе.
Ну, мы уже наблюдали как Хаскель сливает Немерлу .
Так что не надо этой предвзятости. Немерле позволят писать функционально ни чем не хуже чем Хаскель. И что характерно он так же качественно позволяет писать ОО- и иммеративные программы. Единственное существенное отличие от Хаскеля является то что ленивость в Немерле по умолчанию не используется. Но ее без проблем можно использовать там где надо. Так что все концепции объясняются "на ура".
BZ> что касается руби... он очень хорош для некадровых программистов. профессионалы должны думать более систематчисеким путём, они должны жить со сторгой типизщацией в уме, и для них руби будет полезен ближе к концу курса как красивый практический язык
Тут я с тобой полностью согласен. Темоблее, что все приемущества Руби в Немерле имеются по полной. Разве что контюниэшоны по слабей, но это опять таки заслука тинтерпретируемой природы Руби.
Но тут прлема в том, что есть назные учителя с разным взглядом на мир. И вот в том же MIT почему-то считают, что учить на нетипизированных Лиспе и Питоне лучше. В прочем, возможно они просто не видили Немерле .
BZ>а ты собираешься их смешанно давать, типа одно предложение их одной парадигмы, второе из другой?
Я предлагаю давать систематические знания. База — выражения, за которой ветвление в разные подходы. Возможно вообще не называть слова ФП, ИЯ и ООП, а просто демонстрировать паттерны, а затем показвать языковые их реализации. Ну, а когда люди уже освоют все что унжно просто классифицировать полученные знания введя эти самые ФП, ИЯ и ООП и отнеся фичи к ним.
BZ> имхо надо изучить каждую из них — ООП, ФП, ЛП в чистом виде,
И получим то что имеем. Фанатство и частичные знания. А так мы получаем взвешенных и всетаронних специалистов которые не будут орать "ФП фтопку!" или "ФП рулеззз!".
BZ>на чистых языках,
Да, нет в природе чистых языков. Нет вообще. Ты не назавешь мне ни одного языка на котором нельзя было бы писать в другой парадигме. Это все предпочтения. А они при неразумной подаче вызвают фанатизм. Безмозглый тупой фанатизм. Я уже этого на нашем сайте насмотрелся через край. Узкий специалист подобен флюсу. Полнота его одностороння. (с)
BZ> и затем уже идти к тому, как они могут сочетаться. иначе вчедловек, привыкший к ФП-поверх-ООП в Немерле будет *очень* обескуражен ООП-поверх-ФП в окамле, и скорей всего до него долго не дойдёт в чём тут приницпиальная разница
На самом деле единственный побочный эффект который будет при таком подходе — это то, что люди будут с недоверием относиться к "чистым" решениям. Так как будут чйтко осознавать их однобокость и искуственность. Но это, по-моему, как раз большой плюс. Проблемой это может стать только для фанатиков. Им будет трудно расширять свои ряды.
Такие специалисты смогут очень быстро изучать любые новые языки и успешно писать на них. Причем знание все подходов им поможет даже если выбранный язык не поддерживает ту или иную парадигму.
BZ>а ты читал книгу Вадлера или Худака или судишь по Хал-Ван Даму?
Что только я не пробовал читать. ФП по книгам не изучается в принципе. Там один булшит. Ну, разве что ты математик. Тогда может быть и прокатит. ФП изучается только на практике. Нужно освоить один язык где проддерживается ФП и пописать с его использованием. Но конечно же можно написать доступное введение. Просто пока что это никто не сделал. Видимо потоу, что за перо берутся однобокие фанатики созданные такими же однобокими фанатиками.
Можешь попробовать горькую чашу писателей. Может у тебя выйдет выше. Только учти, что если не поборишь догмы которые у тебя тоже есть, то выйдет очередная абракадабра которую прекрасно будут понимать посвященные и снова не поймут начинающие.
VD>>В общем, я виду к тому, что ООП и ФП надо давать параллельно и обязательно как развите стурктурного программирования.
BZ>почему? потому, что ты сам начинал с него?
Потому что я в этом убежден. В отличии от многих я умею остраняться от собственных предпочтений или опыта и давать чистые оценки. Данную мысль я анализировал не раз. И оно является отнюдь не спантанной. Я вижу плоды всех подходов. И вижу ломку сознания и неприятие. Так же сейчас я вижу откуда растут ноги. И считаю, что обучение по тем же направлениям даст людям ясность понимания и предупредит зацикливание.
В общем, это была моя мысль. Не согласен? Ну, и ладно. Один фиг я вряд ли буду кого-то обучать программировать.
BZ> в хаскеле неструктурное программирование вообще трудно поредставить, оно лежит в самой идеологии языка. то же самое в прологе
Хаскль столько же структурен как С даже больше. ЛП конечно другое. Но но то оно и ЛП. Я не призваю изучать ЛП как развитие структуроно подхода. ЛП вообще скорее средство решения конеретного класса задач. Оно по сути ближе к SQL-запросам, когда есть БД и мы пишем запросы отвечающие на те или иные вопрсы. ЛП можно давать как практику программирования вырадившуюся в конеркетный язык.
BZ>я вообще-то предлагал начать с Пролога, поскольку считаю ЛП наиболее высокоуровневой парадигмой.
Боюсь, что у людей сложится неверное отношение к программированию в целом.
BZ> и дальше идти по остальным парадигмам, чтобы человек с самого начала усвоидл каждую из них. но по отдельности, а не в виде nuj бутерброда, которы они приняли в том или ином конкретном языке. иначе он не научится видеть, что здесь принадлежит к ФП, что к ООП, и как их можно соединить иначе или вообще одну из них выкинуть
Еще раз. Я вообще против парадигм в обучении.
BZ>с.п. на данный момент уже можно считать частью ООП.
Ошибочный взгляд, на мой взгляд.
BZ>имхо, ты м сейчас мыслишь в императивном стиле, используя ФП только локально. на что несомненно откладывает отпечаток используемый тобой язык
А мне не надо мыслить функционально. Я мыслю как мыслю. Удобнее так думаю, так удобнее эдак думаю эдак. Остальное догмы.
BZ>т.е. сначала надо научить людей структурному программированию, чтобы они поняли что это бяка и освоили ООП?
Нет. Сначала учить писать выражения. Язык тут монопенисуален:
1 + 2 * (33 + 1)
затем разбавлять их переменными:
def a = 33 + 1;
def b = 1 + 2 * a;
затем дать понятие мзменяемой переменной:
mutable a = 33 + 1;
def b = 1 + 2 * a;
a = 22;
def c = 1 + 2 * a;
это и так будет рвать крышу по началу у всех.
Далее дать if-выражение. Потом if-стэйтмент (надеюсь ты понял о чем я говорю). Ну, и так далее. В конце концом начинаем давать более менее практические задачи. Ну, нарисовать окно. Показываем примитивы рисования и предлагаем создать окно в лоб. Далее предлагаем подумать над тем как создать универсальное окно и плавно подводим к паттенну "объект".
ФП дается примерно так же. Почти игра.
BZ> а перед этим научить их програмимровать на асме, чтобы затем преподнести им идеи стурктурного программирования? а перед этим — в машинных кодах, да?
Отнюдь. Это лишнее. Выражений более чем достаточно.
BZ>твой подход хорош для доучивания людей, которые уже владжеют некоей неэффектвиной парадигмой.
В тебе говорит фанатизм. Не могут быть парадигмы неэффективными. Неэффективными могут быть только человеческие мысли и программы. А парадигмы — это взгляд на проблему. Для одной проблемы лучше подойдет один вгляд, для другой другой. Как минимум с помощью ФП ты не напишешь эффективно сортировки по месту. А с помощью императива получишь неопревданно громоздкий код во многих случаях.
BZ> с нуля же их учить этой парадигме только чтобы продемонстрирвоать её неэффектинвость, нет никакого смысла. их надло сразу учить мыслить в правильном ключе, и pfmtv уже более простые подходы давать только для парктических нужд
В первую очередь нет смысла в фанатичной вере в парадигму. Это маразм и самообман. Человек должен обладать информацией и уметь сделать верный выбор. Вот тогда он будет отличным специалистом, а не фанадом отстаивающим ошибочную точку зрения не смотря ни на что.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Так вот по моему мнению, в рассмотрении с такой точки зрения передачи параметрам функции в C++ нет никакого практического смысла. Т.е. это чистое теоритизирование, не имеющее сухого практического остатка. А посему -- теоритизирование, сильно оторванное от действительности.
Значит, не видишь суслика. А он все-таки есть! Ведь зачем-то придумали в С++ функции нескольких аргументов, не так ли? Хотя вполне можно было упростить всё и потребовать чтобы был только один параметр. А если кому-то надо передавать сразу два — пусть явно опишут структуру. Иначе это архитектурная ошибка.
Соображения симметрии требуют, чтобы функция умела не только принимать, но и возвращать много значений. Ничего укуренного в этом нет. Нужно только немножко абстрагироваться от конкретного языка С/С++.
E>Более того, приведенная тобой запись мало чего контролирует на самом деле: E>ни при компиляции, ни при исполнении, никто не даст по рукам за то, что в функцию real был передан совсем другой кортеж.
Мы все в курсе, что компилятор С++, как и законы берегового братства, скорее рекомендует, нежели запрещает. Это скорее проблема, чем преимущество.
ЗХ>>Ну и, возвращаясь к тому, с чего была поднята эта тема, метафора кортежа была употреблена вполне корректно, в диалоге "зачем возвращать из функции кортеж (список разнотипных значений)? — затем же, зачем мы передаем в функцию кортеж (список разнотипных значений)?"
E>Ничего не имею против возврата кортежей из функций в языках с поддержкой кортежей. Но, имхо, проводя аналогии и используя примеры нужно придерживаться объективной реальности. На практике нет в C++ кортежей, поэтому использование C++ в качестве примера использования кортежей при вызове функции не корректно.
Корректно-корректно. Просто некоторые паттерны встроены в язык С++, и в частности использование кортежа при вызове функции.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
BZ>> мимхо, надо изучать разные параддигмы по их чистым представителям, а не язык, где они как-то сбиты вместе.
VD>Ну, мы уже наблюдали как Хаскель сливает Немерлу . VD>Так что не надо этой предвзятости. Немерле позволят писать функционально ни чем не хуже чем Хаскель. И что характерно он так же качественно позволяет писать ОО- и иммеративные программы. Единственное существенное отличие от Хаскеля является то что ленивость в Немерле по умолчанию не используется. Но ее без проблем можно использовать там где надо. Так что все концепции объясняются "на ура".
Если бы не список
, я бы решил, что ты предлагаешь человеку учть *только* "язык на букву N".
ИМХО, язык всегда заточен под определенную парадигму/стиль/как там еще назвать. Если программировать на нем в ключе этой парадигмы — хорошо, если нет — не очень.. Даже у Н есть свой стиль программирования, который ты так рассхваливаешь. Друое дело, что в Н очень малы затраты при программировании в чуждом ему ключе (например, строго императивно). В той же Жаве можно программировать функционально, но синтаксический оверхед (с) при этом будет огромным. Т.о. Жава подталкивает программиста к Жава-ООП(использую такое словосочетание, потому что меньше всего хочу спорить о терминах), Схема — к ФП и тд. Каждый язык разный и, ИМХО, фишки определенных подходов лучше показывать на языках, которые ориентированы на определенную парадигму.. Во всяком случае, я жалею, что у меня в институте учили Pascal, Delphi и С++ (поубивать бы за такое однобокое развитие! Я на пятом курсе института только узнал, что код программы — это не обязательно последовательность инструкций). Думаю, если бы мне преподавали только Немерле, я бы тоже жалел.. Да и, в конце концов, разные языки учить — это фан
Здравствуйте, AndrewVK, Вы писали:
L>>На счет того, что оба варианта — грамматически правильны я и не спорил. Просто было употребелно не то слово.
AVK>Там есть и толковые словари. И употреблено правильно.
Здравствуйте, Lloyd, Вы писали:
L>>>На счет того, что оба варианта — грамматически правильны я и не спорил. Просто было употребелно не то слово.
AVK>>Там есть и толковые словари. И употреблено правильно.
L>Нет, извини, но употреблено неправильно.
Вообще то тема "Альтернативные языки". Так что зависит от того, в каком языке употреблено
Здравствуйте, VladD2, Вы писали:
VD>А чем по-твоему иявляются параметры функций?
VD>Это ни что иноге как список фиксированной длинны разнонипных значений передающихся как единая сущность.
Ну ты понял, да?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
E>>На практике нет в C++ кортежей, поэтому использование C++ в качестве примера использования кортежей при вызове функции не корректно. S>Корректно-корректно. Просто некоторые паттерны встроены в язык С++, и в частности использование кортежа при вызове функции.
Скорее уж так: некоторые решения, встроенные в C++, могут интерпретироваться как реализации различных паттернов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
L>>Привел, но видимо сам их не прочитал. Вряд ли Влад имел в виду одно из течений в протестантизме.
AVK>Читал внимательно?
Осталось выяснить связь между моралью и стремлением к "чистоте" языка.
В Руби идеи "радикального (динамического) ООП" несколько "запачканы" смешением нескольких методологий, удобством синтаксиса и т.п. (например, в Руби структурные конструкции типа if, while и проч. не являются сообщениями).
1.2.0 alpha rev. 655
