Здравствуйте, eao197, Вы писали:
E>Не удержался...
Евгений, мне понятно Ваше раздражение. Когда что-то рекламируют как панацею, это всегда оказывается Гербалайф. Что поделаешь, как в любом приличном флейме, здесь было сказано много лишнего; не доросла, к сожалению, Философия до конструктивных обсуждений (да, поставьте мне за это 10 минусов) . Но тем не менее, ИМХО, ФП стоит на пороге (о чем говорит появление функциональных элементов в C#, Python и т.д.), и игнорировать его нельзя, ибо программисту надо идти в ногу со временем [пафос офф].
E>
E>Функциональное программирование прекрасно, оно — радость созерцания. Как только кто-то поймет функциональное программирование, он немедленно перейдет к нему. Массы, которые застряли в устаревшем императивном и объектно-ориентированном программировании, делают это из слепого предубеждения. Они просто не понимают.
E>Каким-то религиозным духом попахивает
Да, хороший программист должен быть поэтом и немножко фанатиком. Мне в этом плане нравится эпиграф из SICP (с вашего позволения, приведу целиком):
This book is dedicated, in respect and admiration, to the spirit that lives in the computer.
``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''
А с другой стороны, это не религия, а осознанный выбор. Люди вроде Филипа Уодлера знают достаточно языков не понаслышке, чтобы адекватно оценивать их достоинства. E>В свое время и ООП пыталось пробивать себе дорогу.
Вот-вот, и пробивало не один десяток лет. И успело устареть к моменту пика своей популярности (немного сильное утверждение, но доля истины в нем есть).
E>Хочется добавить, что C, C++ и Java успешно работают во всех этих областях
Здесь отвечу сумбурно, т.к. нормально сформулировать не удается да и времени нет, а сказать давно хотелось.
Да, C и C++ успешно применяются в этих областях, но есть ряд но.
Все знают избитую мудрость о том, что преждевременная оптимизация — это корень зла. А что такое выбор С++, как не преждевременная оптимизация? Ручное управление памятью, обратная совместимость с C (кроссплатформенный ассемблер) — зачем это в экспертной системе, например? Далее, все алгоритмически нетривиальные задачи имеют дело с "кудрявыми" (hairy) структурами данных — деревьями и графами, так или иначе. Их грамотная реализация на C++ (вроде boost::graph) — удел немногих избранных, нетривиальной задачей является и проектирование интерфейса (тут на всю катушку включается горячо любимое Вами метапрограммирование, шаблоны выражений и прочая красота, за которую мы так любим С++), и сама реализация (как-никак, ручное управление памятью, мучительная борьба за thread-safety, которой нет в Стандарте, UB на каждом шагу, и т.д.). И при этом выразительности, сравнимой с Хаскелем, все равно не получить. Елки-палки, в ОКамле я могу дерево записать в виде константы, а в С++ — только с помощью злой механики вроде шаблонов выражений и умных указателей, при этом подумывая о порядке инициализации и точках следования. Тем более безумием, с моей точки зрения, заниматься изобретением новых структур данных и алгоритмов на С++. Т.к. сегодня придется отвлекаться на несущественные детали вроде управления памятью больше, чем следует.
Да, у меня немного опыта, чтобы что-то утверждать. Я, можно сказать, просто купился на "маркетинг" функциональных языков. Я просто посмотрел на задачи, которые команды из 2-5 человек решают на ежегодных соревнованиях ICFP Contest и в какие сроки (конечно, моделирование поведения колонии муравьев на поле из шестиугольных клеток имеет мало общего с промышленным программированием, нудным сопровождением, написанием кода в соответствии с стандартами и гайдлайнами, чтобы любой индус мог понять, продолжите сами..., но это же интересно, черт побери, впечатляет! Я тоже хочу быть способным написать компилятор языка, управляющего муравьем, за 2 часа, или ray-tracer за полдня, это вам не XML-сериализация SOAP-envelope'ов, фукакаягадость У меня есть амбиции, хочу решать интересные задачи (как у McSeem2 — поймите меня правильно, я себя ни в коем лучае с Максимом не сравниваю, не дорос еще.) "У меня тоже голос, я тоже хочу петь" ).
Я одно время был очень сильно увлечен возможностями и новыми течениями в С++ (ну Вы знаете, списки типов, CT вычисления и т.д), но потом оказывается, что в реальной работе я их не применяю. А когда применяю, проекту это вредит. Они для элиты, которая пишет библиотеки типа буста. И на что тратит время эта элита? Они знают Стандарт, все 700 страниц, наизусть, знают все глюки и несоответствия стандарту популярных компиляторов, и могут часами обсуждать, имеет ли некоторый фрагмент кода Undefined behaviour — стоит ли тратить на это драгоценное время? (последний абзац не стоит понимать буквально, я уважаю элиту С++-сообщества, честно ).
Я думаю, не стоит объяснять, в чем разница между:
— логическим выводом, встроенным в язык, и реализацией оного на С++
— параллельностью и распределенностью, встроенной в язык — "вот, посчитай мне вот это выражение, а на скольки процессорах и как будет проводиться синхронизация, мне неинтересно" — и того же на С++, с учетом всех граблей ручной синхронизации, видимости памяти, инверсии приоритетов, ... (заметим, здесь тоже нуже человек с умственными способностями академика, но все свои способности он убьет на борьбу с машиной, а не с задачей)
— настоящими ленивыми вычислениями и их имитацией на С++
— продолжите список, посолить по вкусу.
Далее, о сложности и читабельности. Читабельность кода, несомненно, важна, но если не доводить до паранойи. Спорить, что лучше, фигурная скобка или begin, могут, ИМХО, люди с ограниченным мировоззрением. Истина (для меня) состоит в том, что сложность программы должна отражать сложность решаемой задачи, по возможности не добавляя к ней сложности самого языка программирования. Надоедают рассусоливания о том, стоит ли заключать тело однострочного if'а в фигурные скобки или не стоит, не вредит ли это понятности кода (да что там понимать! да, я знаю о стоимости сопровождения кода, в конце концов, с этого я начинал — доделывал и багфиксил монстра с 5-летней историей). Возьмем научную работу с применением современного мат. аппарата, ну, вы знаете, начинается со слов "Очевидно, что" — и пошли формулы на 10 страниц. Вопрос: математики, физики, химики, они нарочно, что ли, усложнить себе жизнь пытаются? Нет, просто для сложной задачи это самая краткая, однозначная и точная запись -> следовательно, самая понятная, адекватная задаче. Вспомним, как в школе заучивали правила дифференцирования/интегрирования, на естественном языке это длинное и непонятное месиво, на языке формул — все ясно, если привыкнуть. Точно так же решение алгоритмически сложной проблемы на С — длинное и непонятное, за деревьями леса не видно. Программы на ФЯ — это те же самые мат. формулы, только исполняемые. Отсюда популярность в академическом мире. Но я думаю, от них и неакадемический мир может получить определенные преимущества. Давайте откроем наши mind'ы новому (а по сути, хорошо забытому старому).
Я отлично понимаю, что ФЯ — это не силвер буллит. Я отдаю себе отчет в том, что для Явы и С++ задач еще на 20 лет хватит. А также о том, что мне еще долго писать на С++ и C# "за еду", оставив ОКамл/Хаскель в качестве хобби и для решения задачи в аспирантуре. Но Яве и особенно, С++ (при всем уважении) нужно подвинуться.
Уфф, о чем это я? Мне же через три дня сдавать редактор конфигурационных файлов в формате XML, с драг-н-дропом и проперти-гридом, а там еще конь не валялся, что я тут делаю? Раскланиваюсь, не судите слишком строго...
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, reductor, Вы писали:
AVC>Насколько я понимаю, Дейкстра, Хоар и Вирт были во многом единомышленниками и друзьями в жизни. AVC>Естественно, между ними существовало и определенное "разделение труда", и взаимное влияние. AVC>Например, многие идеи Хоара легли в основу языка Паскаль. AVC>Если хотите, присваивайте каждому из них тот или иной "вес" — это Ваше право.
Это что, обвинение в чем-то личном чтоли?
Хоар, Дийкстра и Вирт были принимали участие в создание Алгола (Основная роль была тем не менее все же за Бэкус с Науром)
Паскаль прямой потомок Алгола.
Но это все не имеет никакого значения. Вклад в Computer Science Дийкстры и Хоара несоизмерим с Виртовским. Точнее, Паскаль уже не являлся чем-то особенно заметным в CS. Упрощенный Алгол.
То, чем занимались Дийкстра, Хоар и Милнер сейчас лежит в основе SML, O'Caml и Haskell.
Не считая придуманных ими алгоритмов и сделаных открытий. Их влияние _огромно_.
А Вирт? Язык Оберон. Даже не смешно.
То есть реально я вообще затруднюсь сказать что сделал Вирт в CS после своего участия в группе алгола.
40 лет одна и та же песня.
R>>Это все потому, что Вирт, прямо скажем, иногда слышав звон интерпретировал его по-своему, причем, слишком активно интерпретировал.
AVC>Вы что-то конкретное имеете в виду?
Нет. Все вместе и по очереди.
AVC>Я понял, что Милнера (кто это?) и Маккарти Вы ставите выше, чем Вирта. Это Ваше неотъемлимое право.
Кто такой Милнер? Хороший вопрос на форуме, посвященном программированию.
Нет, правда. Робин Милнер — это такой человек, который в то время, когда Вирт делал Паскаль, совершил небольшую революцию в CS.
Создал язык ML и алгоритм вывода типов Хиндли-Милнера. А так же создатель пи-исчисления. Один из самых влиятельных и цитируемых ученых в мире. http://citeseer.ist.psu.edu/mostcited.html — Вот здесь он на 4 месте с 9711 научными статьями на него ссылающимися.
Для маленького сравнения — на доклад Вирта о языке Оберон ссыается 4 (четыре) статьи.
Ставлю ли я Милнера выше Вирта? Пожалуй.
AVC>Но вот насчет оплеух Вирту "по делу", может быть, скажете пару ласковых слов? AVC>Так сказать, перед смертью. :)
А почему перед смертью? Он умирать собрался?
Хорошего о Вирте могу сказать, конечно — хотел бы я иметь его упорство.
Здравствуйте, reductor, Вы писали:
R>А Вирт? Язык Оберон. Даже не смешно. R>То есть реально я вообще затруднюсь сказать что сделал Вирт в CS после своего участия в группе алгола. R>40 лет одна и та же песня.
Блин, ну как же много желающих кинуть в Вирта камень! Извините за ненормативную лексику, но это просто офигеть можно (с заменой офигеть на соответствующий нецензурный термин по вкусу).
Кто про нас знает за пределами RSDN?А ведь про Вирта знают...
Если кому-то кажется, что Вирт оставил малый след в программировании, то это его личное дело. Но вот смеятся над ним пусть будут те, кто создал что-нибудь аналогичное Паскалю, с выросшими из него Modula-ми, Oberon-ми, и выросшими из всего этого Object/Component Pascal-ями, Delphi-ями и Ada-ми.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Сегодня исправлял одну багу в ядре Линукса и в процессе наткнулся на C>такой пост:
C>У меня все больше уважения к этому товарищу!
Видно, Линусу проще добиться уважения критикой Вирта, чем выведением багов из ядра?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Да уж, дошли.
Как-то раз появился господин Губанов и распальцованно начал объяснять что все языки отстой, что вы все неправильно делаете и есть только Oberon и Вирт пророк его. И настолько настойчиво указывал на это, что у большинства населения rsdn сложилась сильная антипатия к Oberon(иногда незаслуженная). Но самое главное не это. Самое главное что точно такая же антипатия сложилась и в отношении г-на Вирта. Любое упоминание Вирта вызывает стойкую антипатию не взирая на обстоятельства. И такие флеймы постоянно кочуют в Священные войны. Народ уже перестал разбираться в чем вопрос. Если в этом участвовал Вирт — то значит отстой. Хотя не мы признавали Вирта одним из людей, которые внесли вклад в развитие Computer Science. Это делали другие, более профессиональные люди, и делали это более независимо. И они не знали о Губанове(и об Обероне правда тоже ).
Мне не нравится Оберон. Мне не нравится многие вещи Кнута. Ну не нравятся. Но я никогда не спущусь на нападки конкретно на этих людей. Я могу сообщить что мне не нравится. Это будет конструктивно. Но нападая на этих людей и обвиняя их в смертных грехах, я тем самым оскорбляю не только их, но и тех (скорее всего более умных чем я) людей которые признают их вклад в развитие Computer Science.
Поэтому предложил бы объявить людей, которые являются Нобелевскими лауреатами и лауреатами премии Тьюринга священными коровами. И баннить наезды на них по полной так же как и наезды на личности на rsdn. То есть добавить правило что личности из списка Премии Тьюринга священны, и личные нападки на этих людей есть нападки на все IT сообщество. Можно наезжать на поступки, нельзя наезжать на личность.
С уважением, Gleb.
ЗЫ. Это кстати сильно поубавило бы флеймистость Философии программирования.
Здравствуйте, reductor, Вы писали:
R>Хоар, Дийкстра и Вирт были принимали участие в создание Алгола (Основная роль была тем не менее все же за Бэкус с Науром)
А я уж было подумал, что Дейкстра и Хоар, в отличие от Вирта, Лиспом занимались. Или ML.
R>Паскаль прямой потомок Алгола. R>Но это все не имеет никакого значения.
Само собой.
По сравнению с самым влиятельным языком современности (ML, разумеется) мало что имеет значение...
R>А Вирт? Язык Оберон. Даже не смешно.
Действительно.
R>То есть реально я вообще затруднюсь сказать что сделал Вирт в CS после своего участия в группе алгола. R>40 лет одна и та же песня.
Вы, насколько я понимаю, мало интересуетесь императивными языками.
Конечно, Вам трудно что-то сказать по этому поводу (как мне — о функциональных языках).
Они для вас "как китайцы" — все на одно лицо.
R>>>Это все потому, что Вирт, прямо скажем, иногда слышав звон интерпретировал его по-своему, причем, слишком активно интерпретировал.
AVC>>Вы что-то конкретное имеете в виду?
R>Нет. Все вместе и по очереди.
То есть конкретно сказать нечего, кроме того, что Вам больше нравятся функциональные языки?
Ничего не имею против. Только обратил бы внимание, что и у императивных языков есть своя ниша.
В Оксфорде на "первое" подают Хаскель, на "второе" — Оберон. И при этом об Обероне отзываются очень хорошо.
R>Кто такой Милнер? Хороший вопрос на форуме, посвященном программированию. R>Нет, правда. Робин Милнер — это такой человек, который в то время, когда Вирт делал Паскаль, совершил небольшую революцию в CS.
Интересное словосочетание: "небольшая революция".
Комнатная, что ли?
R>Создал язык ML и алгоритм вывода типов Хиндли-Милнера. А так же создатель пи-исчисления. Один из самых влиятельных и цитируемых ученых в мире.
Ну, я догадывался, что Милнер — автор одного из функциональных языков, о которых Вы так восторженно говорите.
Только не знал — какого именно.
И на кого же он так повлиял (кроме других ученых, разумеется)?
А то его безмерное могущество не везде так сильно ощущается.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, reductor, Вы писали:
R>>Вообще в чем проблема, квалифицированному программисту выучить любой язык, если очень нужно — полдня максимум
Т>Тут недавно на смех подняли человека, который утверждал что знает C++, попрограммировав на нем всего год. Т>Где же правда
Правда и там и там.
Человек, для которого С++ — первый или второй язык программирования в жизни действительно не будет знать его хорошо даже за год (особенно, если не будет стараться проникнуть в язык поглубже).
Человек же, который знает необходимый набор классических (оказавших фундаментальное влияние на развитие других) языков + знаком с одним/двумя суперсовременными, выучит с++ очень быстро. Причем глубина его понимания запросто может оказаться побольше, чем у человека, который на с++ программировал 10 лет, но никаких языков больше не знает.
Ни один язык не является замкнутой системой — идеи и способы реализации кочуют туда-сюда и то, на понимание чего в случае первого знакомства требуется два месяца, человек эрудированный просто отметит про себя — ага, это как в языке x, а это как в x', но через механизм z из языка y
То же справедливо и для естественных языков. профессиональные лингвисты учат их очень быстро и так же забывают, когда отпадает необходимость.
Здравствуйте, reductor, Вы писали:
R>В моей обычной практике я использую около 30 языков программирования. Среди них хватает и императивных и функциональных и логических и стековых и гибридов всего этого смешанных вместе.
Можно ли развить эту тему по-подробнее?
Это действительно интересно, т.к. недавно я утверждал, что сложно одновременно использовать в проекте 3-5 языков (Re[2]: Предагаю мир!
).
Но здесь цифра просто на порядок большая . Можно ли подробнее, что это за языки, для каких целей используются, как применяются, какие замечены достоинства/недостатки использования такого количества языков, используется ли это все в рамках одного проекта, какова численность команды и пр.?
Я думаю, что это будет интересно не только мне.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Блин, ну как же много желающих кинуть в Вирта камень! Извините за ненормативную лексику, но это просто офигеть можно (с заменой офигеть на соответствующий нецензурный термин по вкусу).
E>И главное кто?
E>Кто такой reductor? Кто такой AVC? Кто такой eao197?
E>Кто про нас знает за пределами RSDN?А ведь про Вирта знают...
Во-первых, хотел бы заметить, что переход на личности — это дурной тон. Более чем.
Кроме того, кто такой лично я и кто меня знает, во-первых, информация, которую я здесь не указал, а во-вторых не имеет отношения к делу. Или CS это что-то вроде церковной иерархии, где истинность высказывания зависит от того кто сказал, а не от того что?
E>Если кому-то кажется, что Вирт оставил малый след в программировании, то это его личное дело. Но вот смеятся над ним пусть будут те, кто создал что-нибудь аналогичное Паскалю, с выросшими из него Modula-ми, Oberon-ми, и выросшими из всего этого Object/Component Pascal-ями, Delphi-ями и Ada-ми.
Мне ничего не "кажется". Оценить влияние Никлауса Вирта и его вес в научном сообществе можно посмотреть по адресу http://citeseer.ist.psu.edu/
И без истерик и идолопоклонничества.
Если же у вас есть свое мнение (наличие такового всегда вызывает уважение) по поводу того, что сделал Вирт, Паскаля, Оберона и тп — думаю, все бы рады были услышать подробный отчет со сравнениями тех языков, которые были актуальны в CS на тот момент.
Здравствуйте, reductor, Вы писали:
R>А что касательно системного софта — R>Сколько раз увидишь человека, который пишет ядро на С++, столько раз и убей его R>И что характерно, на том уровне уже неважно какие синтаксически навороченные аллокации в языке.
Уже несусь на форум C++. Буду убивать. Спасибо за информацию. Один маленький вопрос, я тоже писал ядра на С++. Каким способом покончить самоубийством? R>Важно другое. Вот например то, что в cyclone
Ооо. Последнее желание перед смертью. Увидеть человека который писал ядра на cyclone. Облобызаю по самое нехочу.
Здравствуйте, ArtDenis, Вы писали:
AD>Это что-то из области "булки на деревьях растут, а Россия-родина слонов"?
Ну, не нравится свинодобывающая промышленность — подставь кознестроительную или оброкосборочную.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Сегодня исправлял одну багу в ядре Линукса и в процессе наткнулся на
такой пост:
> However, I have always been taught, and have always believed that
> "goto"s are inherently evil. They are the creators of spaghetti code
No, you've been brainwashed by CS people who thought that Niklaus Wirth
actually knew what he was talking about. He didn't. He doesn't have a
frigging clue.
> (you start reading through the code to understand it (months or years
> after its written), and suddenly you jump to somewhere totally
> unrelated, and then jump somewhere else backwards, and it all gets ugly
> quickly). This makes later debugging of code total hell.
Any if-statement is a goto. As are all structured loops.
Ans sometimes structure is good. When it's good, you should use it.
And sometimes structure is _bad_, and gets into the way, and using a
"goto" is just much clearer.
For example, it is quite common to have conditionals THAT DO NOT NEST.
In which case you have two possibilities
— use goto, and be happy, since it doesn't enforce nesting
This makes the code _more_ readable, since the code just does what
the algorithm says it should do.
— duplicate the code, and rewrite it in a nesting form so that you can
use the structured jumps.
This often makes the code much LESS readable, harder to maintain,
and bigger.
The Pascal language is a prime example of the latter problem. Because it
doesn't have a "break" statement, loops in (traditional) Pascal end up
often looking like total shit, because you have to add totally arbitrary
logic to say "I'm done now".
Здравствуйте, reductor, Вы писали:
AVC>>Видно, Линусу проще добиться уважения критикой Вирта, чем выведением багов из ядра?
R>..монажная склейка.. R>Интересно, а что он на Вирта-то наехал? Вирт-то фигура далеко не самая заметная в этом плане. Что не сразу на Дийкстру, Хоара, Кнута и Милнера? Неужели не посмел? R>Слабак!
Как бы то ни было, из "великой троицы" (Дейкстра, Хоар и Вирт) неизменно атакуют именно Вирта.
То Керниган напишет запоздавшую на несколько лет статью "Why Pascal is not my favourite programming language".
То Пайк в статье о стиле программирования на Си два раза упомянет Паскаль, и оба раза в словосочетании "тирания Паскаля".
То вот Торвальдс выскажется, что goto — это хорошо, а Вирт занимается "промывкой мозгов", и вообще ничего не понимает. В отличие от него, Торвальдса. (Я так понял приведенную Cyberax'ом цитату.)
В связи с goto этот наезд хотя бы имеет некоторое основание:
1) в названии дейкстровской статьи "Goto considered harmful" фраза "considered harmful" (породившая столько подражаний) принадлежит именно Вирту;
2) начиная с Модулы-2 в виртовских языках действительно нет goto (и ведь ничего страшного с его исчезновением не случилось).
Могу предположить, что Вирта легче критиковать, потому что он "превращает теорию в практику", создает языки программирования и операционные системы. И про все это можно сказать с видом крайнего глубокомыслия: "а мне это не понравилось". А вот про теоретические работы так говорить не принято. Пришлось бы искать иные аргументы, помимо ругательств.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
reductor,
> E>Никогда не поверю, что C++ можно выучить очень быстро и начать на нем грамотно программировать. Особенно с сегодняшним уклоном в шаблоны, метапрограммирование и expression templates...
> Если вы считаете, что человек, знающий Common Lisp, Smalltalk и ML найдет для себя что-то новое и неизвестное в C++, то мне придется вас разочаровать. Не найдет.
Вероятно, Вам будет удобнее увидеть это новое, глядя не на спецификацию самого языка, а на формальное описание некоторой части его семантики. Вот попытка составления такого формализма; кстати, там явно прописаны отличия от Хаскеля. Есть и ряд отличий, существенных с практической точки зрения. Часть из них упоминал eao197, но, к сожалению, Вашего мнения по этому поводу каждого из отличий увидеть не удалось; поэтому я пока, пожалуй, воздержусь от их перечисления.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Никогда не поверю, что C++ можно выучить очень быстро и начать на нем грамотно программировать. Особенно с сегодняшним уклоном в шаблоны, метапрограммирование и expression templates...
На самом деле меня очень удивило замечание про "особенно шаблоны, метапрограммирование и expression templates" . С точки зрения человека, который учился функциональному программированию, шаблоны, метапрограммирование и expression templates — это как раз то, в чем он давно разобрался. Смутить его может только синтаксис. Метапрограмирование в С++ — это, например, в Scheme, просто програмирование. Сколько времени это занимает?
Возьмем к примеру пресловутый курс MIT 6.001 (первый курс). Понятие higher-order function — это шестая лекция первый семестр. Алгоритмы, применяемые к сиквенсам, — восьмая.
Ему несложно понять, что делает mpl::fold, более того, он может написать fold на Sсheme с закрытыми глазами:
(define (fold-right op initial seq)
(if (null? seq)
initial
(op (car seq)
(fold-right op initial (cdr seq)))))
Не нужно быть семи пядей во лбу, чтобы, посмотрев на:
template< typename Types, typename Unit, typename Root = mpl::none >
struct gen_linear_hierarchy
{
typedef typename mpl::fold<Types,Unit,Root>::type type; // here
};
//usage example: template< class Base, class T >
struct EventHander : public Base
{
virtual void OnEvent(T& obj, int eventID) = 0;
};
typedef gen_linear_hierarchy<
mpl::list<Window,Button,ScrollBar>
, EventHander<_1,_2>
>::type v;
понять, что gen_linear_hierarhy — это higher-order функция, которая принимает
аргументы через темплэйтные параметры. Т.е. примерный эквивалент на Scheme:
(define (gen_linear_hierarchy Types Unit Root)
(fold-right Unit Root Types))
(define (EventHandler Base T)
(list Base T))
;; usage example
(gen_linear_hierarchy (list 'Window 'Button 'ScrollBar) EventHandler '())
;; i.e (Window Button ScrollBar) -> (Window (Button (ScrollBar ())))
Т.е. мы просто преобразуем список в дерево. Абстракции тут просты и понятны. Синтаксис С++ темплэйтов ужасен.
Если начинать знакомиться с абстракциями типа filter, map, fold etc. по Александреску и Абрахамсу-Гуртовому (или даже по STL), то, для начинающего, синтаксис затмит все. Не говоря уже о том, что посмотреть на результат темплейтного метапрограмирования глазами мы можем, лишь скомпилировав файл с ключом -D, а потом еще и отформатировав вывод. Зная абстракции, пользоваться инструментами — просто.
Ну, например, вот немного линейной алгебры из домашнего задания первокурсника, который к тому времени уже целых два месяца учится программировать. Если это переписать на boost::mpl и запостить с форум по С++ — все закричат, что это извращение и среднему труженнику С++ этого ни в жисть не понять
(define (dot-product v w)
(accumulate + 0 (map * v w)))
(define (matrix-*-vector m v)
(map (lambda (x) (dot-product x v)) m))
(define (transpose m)
(accumulate-n cons null m))
(define (matrix-*-matrix m n)
(let ((cols (transpose n)))
(map (lambda (x) (matrix-*-vector cols x)) m)))
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> C>Например, если нельзя допускать пауз GC и большого оверхеда >> C>конкурентного GC. Или если существуют гораздо более эффективные методы >> C>управления памятью для данной задачи (preallocated пулы, например). Или >> C>если требуется *детерминированое* уничтожение объекта. >> Вы на чей вопрос здесь отвечаете? >> Я спрашивал для каких задач. Конкретнее.
C>Игры, требовательные десктопные приложения, системный софт.
Ну если требовательные, тогда конечно С++ нельзя, он медленный — куча тормозит из-за фрагментации. Да и на просто аллокацию у него времени уходит раза в три больше, чем у окамла.
Давайте уже договоримся — нечего делать в прикладном софте ручному управлению памятью.
Это очень дорого. Во всех смыслах.
А что касательно системного софта —
Сколько раз увидишь человека, который пишет ядро на С++, столько раз и убей его
И что характерно, на том уровне уже неважно какие синтаксически навороченные аллокации в языке.
Важно другое. Вот например то, что в cyclone
>> Опять же, про паузы интересно.
C>RTFM: http://www.memorymanagement.org/
Ну вот только не нужно этой пошлости.
Конкретно скажите у какого типа GC какие паузы и тп. И что где дороже того, что в С++ получается.
Ну вот пусть в том же окамле. А то там Лерой как-то выкладывал калькуляцию по этим вещам, хочу сравнить вашу и его.
>> C>А в С++ нет проблем с алиасингом. Более того, он тоже успешно >> C>используется для некоторых трюков. >> Переведите
C>В С++ нет проблем с накладывающимися массивами, так как они с помощью C>адресной арифметики могут быть использованы для интересных C>inplace-преобразований.
Абсолютно неинтересной невозможности компактнуть хип правильно сказать.
"интересных преобразований"
>> C>Вот вам прямо с About Haskell >> Что вы хотели сказать цитированием мне этого sales talk десятилетней >> давности?
C>А что, вы один должны гнать sales-talk десятилетней давности про GC?
Чооо? эт где?
>> C>В С++ продумано взаимодействие аллокаторов, стандартных контейнеров, >> C>алгоритмов и т.п. Например, как мне поместить в контейнер OCaml'а >> C>объект, созданый в блоке shared memory? Причем указатели в этом объекте >> C>представлены в виде смещений относительно начала блока, а null pointer >> C>представлен в виде указателя со смещением -1. >> Вы будете продолжать фантазировать или хотя бы прочитаете мануал по >> окамлу?
C>КАК мне разместить, скажем, список OCaml'а в shared memory и передать на C>Хотя я знаю, что вы скажете — дадите мне ссылку на документацию по FFI и C>станете рассказывать, что shared memory устарел и никому не нужен.
Здравствуйте, AVC, Вы писали:
AVC>Видно, Линусу проще добиться уважения критикой Вирта, чем выведением багов из ядра?
Слишком много людей пишут это ядро помимо Линуса. Этот пост, очевидно, адресовался им. И вполне правильно он поставил акцент, что читабельность и простота важднее, чем следование неким догмам.
Я, например, с легкостью использую goto там, где это действительно подходит. Это примерно 1-2 goto на проект из более сотни тысяч строк исходников. И почему меня должно это парить& Только потому, что goto может "привести куда угодно"? Указатели в С++ тоже могут привести куда угодно, при соответствующем отношении к ним. B для многих это повод не писать на С++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
R>>А Вирт? Язык Оберон. Даже не смешно. R>>То есть реально я вообще затруднюсь сказать что сделал Вирт в CS после своего участия в группе алгола. R>>40 лет одна и та же песня.
E>Блин, ну как же много желающих кинуть в Вирта камень! Извините за ненормативную лексику, но это просто офигеть можно (с заменой офигеть на соответствующий нецензурный термин по вкусу).
E>И главное кто?
E>Кто такой reductor? Кто такой AVC? Кто такой eao197?
E>Кто про нас знает за пределами RSDN?А ведь про Вирта знают...
Герострат тоже известен.
E>Если кому-то кажется, что Вирт оставил малый след в программировании, то это его личное дело. Но вот смеятся над ним пусть будут те, кто создал что-нибудь аналогичное Паскалю, с выросшими из него Modula-ми, Oberon-ми, и выросшими из всего этого Object/Component Pascal-ями, Delphi-ями и Ada-ми.
Если бы я был создателем Паскаля, я бы не стал этим гордится.
Здравствуйте, шапокляк, Вы писали:
Ш>Я тут конешно новенькая и меня легко затоптать. Но сложите 2 и 2. Лауреаты премии Тьюринга люди не святые. Но коли с ними переходят на личности то уж никак не от большова ума. И што тут спорить? Ну а научный уровень Линуса Торвальдса можно даже не обсуждать. Хотя я не удивлюсь если его протолкнут в лауреаты Тьюринга. Такова жизнь.
Честно говоря, я бы дал премию Страуступу. Можно долго мучится вопросом насчет недостатков и достоинств языка и научной ценности, но то что его детище кардинально повлиял на все сообщество на десятилетия — отрицать нельзя. Это влияние нельзя переоценить.
Здравствуйте, Pzz, Вы писали:
Pzz>Забавно, что C# это первый язык, который добился широкой известности, не Pzz>будучи перед этим рожденным в юниксовской среде.
Pzz>Интересно, можно ли на этом основании делать вывод, что C# умрет, так и Pzz>не осуществив возлагаемых на него надежд? Я склонен думать, что да.
Pzz>Микрософт при этом совершает совершенно героический поступок, поставив Pzz>все фишки на технологию, которая не была 20 лет обкатана на юниксе...
Она так или иначе была обкатана в виде Явы (а теперь точно минусов нахватаюсь).
0xDEADBEEF wrote: > > Это означает, что в развесистом исходнике, какой-то совершенно левый > индус, которого ты и в лицо не видел, решит задействовать ТВОЮ функцию > для СВОИХ целей. Естественно, он, как "грамотный программист" обьявит ее > в своем гадюшнике. А потом ТЫ (через полгода), маленько подправив СВОЮ > функцию, с удивлением обнаруживаешь что ты(именно ТЫ!!!) ЗАВАЛИЛ БИЛД! > Или на тебя свалилась куча БАГОВ.
Говорят, от этого помогает писать код в таком стиле, чтобы в нем ни один
индус не мог разобраться. Я сам не пробовал...
Еще, наверное, от части индусов должны помогать названия функций типа
kill_the_cow()
Здравствуйте, reductor, Вы писали:
GZ>>Не перевирай факты и узнаешь. R>Жду указания на вранье и доказательство такового. Чем быстрее, тем лучше.
Вирт никогда не участвовал в разработке Algola. Algol-60 появился до него. Его вариант в виде Algol-W был отвергнут комиссией. В результате была специфирована некая помойка в виде Algol-68 и без его участия. Algol-W потом перешел в Паскаль, и как результат, Паскаль стал промышленным языком, Algol-68 — только же как сборище ссылок. Некоторые вещи Algol-68 все таки повзаимствовал у Algol-W, но это был уже другой язык. Виртом был создан первый структурный язык с нормальным дизайном и с модульным принципом построения программ. Модульный принцип был недоработан, и как результат — появление Модулы.
Ну или возьмем EBNF. Это тоже упрощение Вирта. Сейчас уже де факто он используется вместо BNF.
Но вообще, наибольшее достижение Вирта — это школа построения компиляторов. Во многом те компиляторы которые мы используем — это детище Вирта. Потому как Паскаль и Модула, его работы связанные с ними и послужили примером что такое эффективный концептуальный компилятор.
R>Вообще-то оригинальные исследования принадлежат H. Curry, А Хиндли с Милнером имели независимые исследования. R>И давайте без этого "просто", да? А то так договоримся, что все математики просто реализуют идеи пифагора. R>Список работ Милнера и их оценку можно посмотреть на http://citeseer.ist.psu.edu/ R>И это никак не отображает заслуги тех же Хиндли и Карри.
Там же можешь посмотреть и список работ Wirth. Или лучше на ACM. Это более качественный источник, поскольку там публикуются только важные научные статьи а не все диссертации и подряд.
R>Дайте опровержение. Покажите работы Вирта, расскажите о их фундаментальности и влиянии. Или вам чье-то вранье все руки связало?
Можешь и сам их найти. Как Вирта так и его совместные работы. Например с тем же, твоим любимым Хоаром.
1. Когда собеседники меряются своими списками заслуг — это выглядит глупо, однако объяснимо.
Но когда стали выяснять — у кого из авторитетов рейтинг толще (Вирт vs Ульман vs Кодд vs Милнер)... только руками развести.
2. Необходимо учесть, что развитие программирования, CS, IT — это не только научные изыскания и не только технические разработки и не только коммерческие удачи. Это ещё просветительство и популяризация.
Так вот, что бы там Ульман не сделал другого — его (совместно с Ахо) серия книг по компиляторам уже выбила его имя на скрижалях CS.
Какими бы странными и даже ущербными не были языки Паскаль..Оберон, каким бы банальным не казалось "Программы=алгоритмы+структуры" — но своё дело Никлаус Вирт сделал. Без него — советские студенты начинали бы изучать программирование с фортрана (и фортраном же заканчивали).
Эти и другие люди прославились тогда, когда они о своей славе не заботились (шпилька в адрес Вирта нынешнего); упрекать их в том, что она не заслужена, — несерьёзно. Заслужена.
Если кому-то кажется, что Кодд обделён славой — вытаскивайте его заслуги на свет, сделайте ту работу, которую его современники не доделали. Зачем Коддом чморить Ульмана?
Я не хочу упрекнуть никого адресно. Это просто паттерн такой (нет, пожалуй, гештальт; да поди ж их разбери), в котором мы действуем.
(И в обсуждении политики то же самое: наши козлы-политики против ваших политиков-козлов — у наших борода длиннее. Либо: все козлы, но это уже крайность).
GlebZ wrote: > > Почти все правильно. Основной плюс функциональных языков — это > математика. Очень большой плюс. Основной минус функц. языков — это > математика. Слишком на эту математику все завязано. А это не панацея. > Большинство коммерческих продуктов — это большое количество сущностей с > простейшими алгоритмами. На императиве можно меньше думать и больше > делать. В случае функциональных языков для подобных задач приходится
Идея меньше думать и больше делать на мой взгляд губительна для
компутерной индустрии. У нее есть только один плюс: можно включить в
проект произвольное количество индусов, и производительность будет расти
прямо пропорционально количеству исполнителей (а не как, например,
логарифм от нее).
Остальное — сплошные минусы. Например то, что компутеры имеют устойчивую
репутацию ненадежной вещи, склонной к глюкам и отказам, это прямое
следствие широкого применения этой идеи.
Здравствуйте, eao197, Вы писали:
E>Не удержался...
Есть две темы по которым авторы обещают то что они в раю, и вот вам дорога как до него добраться. Это функциональные языки и XP. И эти люди очень обижаются. Они зовут в рай, а мы не идем. И что не идет туда народ, там же рай?
С уважением, Gleb.
ЗЫ сюда еще Oberon неплохо бы приписать.
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Cyberax, Вы писали:
C>>Сегодня исправлял одну багу в ядре Линукса и в процессе наткнулся на C>>такой пост:
C>>У меня все больше уважения к этому товарищу!
AVC>Видно, Линусу проще добиться уважения критикой Вирта, чем выведением багов из ядра?
Так это ж известно, главное — не мотивировать свои слова, а побольше харизмы.
Признавать, а тем более исправлять свои ошибки — это для лузеров и лохов.
Устанавливают правила и пишут историю победители, а как оно там на самом деле — никого не интересует
Пока майкрософт скупает всех этих CS people, которые согласны на них работать, мы плюнем им в спину и создадим свой подхо...kernel panic...
..монажная склейка..
Интересно, а что он на Вирта-то наехал? Вирт-то фигура далеко не самая заметная в этом плане. Что не сразу на Дийкстру, Хоара, Кнута и Милнера? Неужели не посмел?
Слабак!
R>Кстати. По поводу Дийкстры, Вирта, Goto, Real Programmers и CS people R>Не так широко известный случай, когда Frank Rubin написал в ACM: "Goto Considered Harmful" Considered Harmful R>вот это письмо (последнее там): R>http://paramount.www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf
Ответ Дейкстры еще не читал, но скажу что доводы автора не терпят никакой критики. Ту же самую программу я бы написал приблизительно вот так:
int main() {
for(int i = 0; i < N; i++) {
int j;
for(j = 0; j < M && !array[i][j]; j++);
if(j == M) {
printf("first non-zero line is %d\n", i);
return i;
}
}
printf("none found\n");
return 0;
}
За все мои N лет программирования, я использовал goto всего пару раз.
Я даже не сразу смог вспомнить, есть ли goto в C++.
Но я бы перегрыз глотку любому, кто попытался бы у меня отнять goto.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Cyberax, Вы писали:
>>> Интересно, а что он на Вирта-то наехал? Вирт-то фигура далеко не самая >>> заметная в этом плане. Что не сразу на Дийкстру, Хоара, Кнута и >>> Милнера? Неужели не посмел? >>> Слабак! C>Кстати, Кнут считает, что структурное программирование должно содержать break. Ну а имея break (особенно именованый) уже и goto становится фактически ненужным (за исключением случаев с оптимизацией).
Блин, религия это все. break, continue, return, goto — все они операторы безусловного перехода. Просто первые 3 его версии не позволяют выходить за границы блоков в структурном программировании.
Соответственно, в тех языках, где нет break, continue и return вполне можно можно использовать goto, если использовать ег ос той же "аккуратностью", какую мы получаем в случае break, continue, return.
Здравствуйте, reductor, Вы писали:
R>Видимо, вы много времени потратили на изучение этого вопроса. По вашему знание или незнание Java в то время, когда кроме нее знаешь еще языков 20 как-то может повлиять при программировании на С++? Ну если может, так только положительно. Потому что общего в них больше, чем различий. Несмотря на все различия.
По моему опыту, общего между Java и С++, после глубокого в них погружения, оказывается только синтаксис.
И есть у меня сильное подозрение, что когда речь идет о знаниях 20 языков, то речь идет именно о поверхносных знаниях. Которых может оказаться совершенно недостаточно для реализации системы объемом, к примеру, в 100 тысяч строк.
E>>Точно так же, как сравнивать приемы программирования на Ruby или C++. E>>Ну, например, какие грабли зарыты в следующем C++ коде:
R>Вы мне экзамен решили устроить?
Нет, хочу показать, как без знания тонких моментов конкретного языка можно потратить массу времени в отладке (еще хорошо, если такая проблема проявится в отладке, а не после 6-ти месяцев эксплуатации в системе 24x7, когда все уже уверились в ее надежности).
Или еще гипотетический пример из подсистемы кэширования таблиц СУБД. Представь себе код:
class cache_t {
public :
...
cache_page_t get_page( page_index_t index );
...
};
и его аналог на Java:
class Cache {
...
public CachePage getPage( PageIndex index );
...
}
На первый взгляд очень похожи, что и заставляет думать, что Java и C++ близки. На поверку, если C++ тип cache_page_t является не хитрым smart-pointer-ом или не реализован на основе PImpl (с тем же smart-pointer-ом внизу), то производительность C++ варианта будет катострофически низка. И для того, чтобы приблизиться к аналогу Java-варианта потребуется переписать C++ код как-то так:
class cache_t {
public :
...
cache_page_t & get_page( const page_index_t & index );
// Или так.
cache_page_t * get_page( const page_index_t * index );
...
};
Рад за него. Только я не Ульман. И сильно сомневаюсь, что мы сможем нанять на работу кого-нибудь с знаниями, талантом и возможностями Ульмана. Поэтому придется работать с тем, кто есть. И если человек заявляет (либо ведет себя), что "я, да 20 языков, да любой язык за полдня", то это либо горлопан, от которого нужно сразу избавляться, либо новичек, которого еще учить и учить. Гипотетически, конечно, возможно, что мне повстречается кто-то типа Ульмана или того же Вирта. Только, во-первых, шансы на это пренебрежительно малы. И, во-вторых, это сразу станет заметно, поэтому все сразу встанет на свои места.
Пока же мой опыт говорит, что результатов достигают не научно-мыслящие эрудиты и полиглоты, а трудяги, который умеют лямку тянуть. И, что характерно, мало кто из них заявляет о знаниях больше, чем нескольких языков.
R>>>Скажу, что монады мне не мешают разбираться в СУБД на достаточном для удовлетворения моего интереса уровне.
E>>Помогут ли они тебе при реализации, например, подсистемы кэширования таблиц РСУБД на языке C. При условии, что подсистема должна быть портабельна на Solaris, HP-UX, AIX, Linux, *BSD и Win32 (Win2k, XP, 2003)?
R>Однозначно, особенно кеширования R>Кстати, можно и MacOS туда вписать. Я всегда все на нее портирую тоже.
Если это ирония, то напрасная. Я как раз занимаюсь написанием софта, который вынужден работать на этих платформах (только до HP-UX и AIX пока не добрались , вместо них HP NonStop Kernel) и пишется на С++.
R>Вообще интересно, что вас заставляет _спорить_ с _моим_ опытом каким бы он ни был?
Я не спорю с твоим опытом (просто даже не знаю, как о нем вообще судить можно, на основании чего ). Меня двигает то впечатление, которое создают твои посты. "Вирт -- это смешно", "Программы верифицируемы по спецификациям", "Существует способ писать программы без ошибок", "Любой язык за полдня", "Что такого в C++ по сравнению с Common Lisp, Haskell, ML?", ...
Ты напоминаешь инженера из КБ, который привез новый станок на производство. Типа: "Он все сам, самые последние достижения научной мысли, эноргомика на высшем уровне, любые операции...". А потом выясняется, что здесь пол не очень ровный, и загазованность в помещении слишком высокая, и влажность недостаточно низкая, и за эту рукоятку промасленной перчаткой лучше не браться, и протирать его от пыли обычной тряпкой нельзя, и детали такого размера обрабатывать уже нельзя, и токаря дядю Ваню на три месяца на курсы повышения квалификации отправить нужно, а стажера Вовочку ближе трех метров подпускать не следует...
В общем, обычный разрыв между наукой и производством.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>А вот мне интересно, за какие открытия присуждают звания "кандидата технических наук"?
Любое внедрение чего угодно. Даже если ты "изобрел" сортировку пузырьком, для дисера вполне хватит "применение сортировки пузырьком в свинодобывающей промышленности". К списку публикаций добавляешь отзыв, подписанный зам.директора свинодобывающего завода о том, что "метод ... успешно применяется на нашем предприятии вот уже три дня, и все щасливы".
Единственный риск — что неподалеку уже защитили дисер ровно с таким же названием. В остальном ты неуязвим
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали:
Pzz>Микрософт при этом совершает совершенно героический поступок, поставив Pzz>все фишки на технологию, которая не была 20 лет обкатана на юниксе...
Как будто MS-DOS и Windows были обкатаны на Unix-е
И ничего, справились
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
V>>>Соответственно, в тех языках, где нет break, continue и return вполне можно можно использовать goto, если использовать ег ос той же "аккуратностью", какую мы получаем в случае break, continue, return.
VD>>Да, да. Полностью согласенж. Если писать с должной акуратностью, то х86-ассемблер лучший язык программирования.
V>х86-ассемблер — #авно полное, по сравнению со многими другими (Dec, MC68XXX, PICXX) но речь шла не об этом.
Ну, давай поспорим какой из ассеблеров лчший из языков программирования. Мне вот x86 нравится. У него код из далека выглядит стройнее. Такие три колоночки... очень эстетично знаете ли.
V>Но если в языке нет break, continue, return, то без goto порой получается тот самый синтаксический оверхед и лишняя "искусственная" запутанность кода.
Не, не. Не отвлекайся. Давай уж поговорим о превосходстве Дековского ассемблера над разумом.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
E>>>Не удивительно, что это говорит человек, которого даже от Ruby тошнит. А уж от чистого Smalltalk...
R>>?? R>>Можно попросить расшифровать мысль?
E>Ну просто разработчики Ruby не скрывают, что очень многое было взято из Smalltalk. Только язык попытались сделать прагматиченее.
Прагматичнее, да.
Мацумото во всеуслышание объявляет, что у него взорвался мозг, когда он пытался разобраться с хаскелем, после чего идет делать "прагматичный" язык.
Почему-то мне кажется, что хаскель он не смог освоить, потому что у него уже был разорванный мозг. Смоллтолком.
Я еще могу не слишком нервничать, когда вот это позиционируется как прагматичный смоллтолк.
В случае с руби — это прагматичная каша из остатков головы его создателя.
Здравствуйте, Cyberax, Вы писали:
C>Сегодня исправлял одну багу в ядре Линукса и в процессе наткнулся на C>такой пост:
C>[q] >> However, I have always been taught, and have always believed that >> "goto"s are inherently evil. They are the creators of spaghetti code
C>No, you've been brainwashed by CS people who thought that Niklaus Wirth C>actually knew what he was talking about. He didn't. He doesn't have a C>frigging clue.
: функциональные языки какие крутые (круче них, понятное дело, только яйца)! Вот почему они мейнстримом не стали понять до сих пор не могу?
Мейнстримом еще не стали. Почему? куча причин. Например, их туда никто не продвигал. Это всегда были два разных мира — IBM, пишущая операционные системы на ассемблере, и какие-нибуть самодостаточные МИТовские хакеры, которые на деньги Пентагона делали искусственный интеллект. ООП вот тоже появилось в 60-х годах, а мейнстримом стало в 90-х. Да и вообще, индустрия молодая, у нее еще все впереди.
Влияние функциональных языков, на мой взгляд, и сейчас весьма заметно. C++ STL, например. Или вот вам понравилось передавать функции как параметры в Руби — это оно самое и есть. Функциональный стиль программирования так или иначе
поддерживает большая часть вполне мейнстримных языков: Java Script, Python, Ruby, Perl, Lua, C#. Другое дело, что и на них большинство людей будут продолжать писать, как на своем предыдущем Впрочем, вы сами все это знаете.
Я хотел сказать, что, безотносительно практического применения, посмотреть простенький функциональный язык типа Scheme в сочетании с какой-нибудь очень хорошей вводной книгой типа SICP может быть очень полезно и для программирования на Руби, С++, boost::mpl и.т.д, т.к с концепциями и абстракциями лучше знакомиться по оригиналам, а не по имплементациям, сделанным для расширения Feature-list
E>А чего здесь вообще должно делаться? Матрица на матрицу перемножаться?
Ага.
E>Ну и сколько Scheme-программисту нужно будет изучать C++ и boost::mpl для того, чтобы сделать то же самое через C++ные expression templates?
Про expression-templates я тут не говорил. а так, чтобы compile-time перемножать матрицы...
Scheme-пограммисты, наверное, тоже бывают разные. Но тому, которого учили правильно, в идеале (достижимость идеала зависит от того, насколько качественно абстракции реализованы в MPL) — быстро.
Для начала он поищет в MPL нужные вещи: map (mpl::transform), acummulate(mpl::accumulate), list (mpl::list), lambda(mpl::lambda), let — нафиг не нужен, это синтаксический сахар, accumulate-n ему возможно придется дописать
(define (accumulate-n op init seqs)
(if (null? (car seqs))
null
(cons (accumulate op init (map car seqs))
(accumulate-n op init (map cdr seqs)))))
Понять, что метафункции возвращают типы, и прочее, вроде недолго. Потом ужасный синтаксис, и все.
Среднестатистический программист императивного склада попытается понять, как все это работает, заглянет в исходники MPL (6 мегабайт красивого бустовского кода) — и застрелится
RK>По-моему, последняя инкарнация выглядит чуть понятнее, чем начальная, но всё же... Какой у неё "физический" смысл? Как надо понимать её действие?
Нужно понять, что любой байндинг, любая конструкция в хаскеле, которая имеет свой синтаксис — это на самом деле просто аналог макроса в лиспе.
Компилятор одним из первых запускает процесс десахаризации (desugaring)
И у всего есть строгие правила трансляции.
let f x = x * x in f 10 -- это транслируется в:
(\f -> f) (\x -> x * x) 10
-- то есть в общем случае
let x = y in z -- это
(\x -> z) y
let f = (+ 5) . (* 10) in f 10 - это:
let f = (.) (+ 5) (* 10) in f 10 -- а потом:
let (.) = \x -> y -> z -> x (y z) и потом:
(\f -> f) (\x -> \y -> \z -> x (y z)) (+ 5) (* 10) 10
-- дальше можете потренироваться сами, там еще пара редукций :)
RK>А как можно посмотреть результаты трансляции в лямбду? И есть ли в интерпретаторе Хаскеля что-то типа (trace 'func-name)? Очень бы помогло.
ghc -ddump-ds
Но вообще лучше всего почитать про лямбда-исчисление и комбинаторы и SKI-исчисление Карри — вещь дико простая и когда ее понимаешь, даже документацию читать не надо, интуитивно ясно что происходит.
RK>Программировать в уме и я могу без ошибок. Правда такого ЯП ещё не выдумали :))
Хаскель :)
Настолько простой и математически чистый, что не дает возможности увильнуть в сторону :)
R>>Нет, хаскель — не продолжение лиспа. Это важно понять. Это продолжение ISWIM и Миранды.
RK>Таких зверей не знаем :) Тоже функциональные и ленивые?
Почти все правильно. Основной плюс функциональных языков — это математика. Очень большой плюс. Основной минус функц. языков — это математика. Слишком на эту математику все завязано. А это не панацея. Большинство коммерческих продуктов — это большое количество сущностей с простейшими алгоритмами. На императиве можно меньше думать и больше делать. В случае функциональных языков для подобных задач приходится думать поболее, что компенсирует то что, во многих случаях, кода на нем пишется меньше. Кроме того, в коммерческой разработке задача работы и адаптации ресурсов компьютеров встречается значительно чаще чем сложные и интересные мат. алгоритмы с мат. формулами.
Здравствуйте, eao197, Вы писали:
V>>Иногда прикручиваются еще всякие скриптовые или специфические, типа Пролог, MatLab, Forth и т.д.
E>А зачем? Можно ли примеры?
Пролог — был как ядро в системе распознавания смысла текстов в одной тематической области. Обработка была на С++, связь по COM на VB, а интерфейс GUI на Дельфи.
Как раз пример использования каждого из тулов по-месту.
MatLab одно время использовал регулярно в вычислительных/моделирующих тулзах (когда плотно занимался цифровой электроникой)
Forth — одно время вообще не было приемлимых альтернатив в качестве скриптовых-динамических.
AVC wrote: > > Pzz>Но влияние-то оказывает > > Меня как раз тут в свое время "уличали" (eao197 и CrystaX), что я пишу > на Си с классами, а не на "современном" Си++ (с шаблонами и большим > boost-ом). > Так что на меня шаблоны оказывают весьма умеренное влияние (в основном — > в виде ночных кошмаров).
А ночные кошмары, это не влияние?
> А ML — вообще никакого. (Допускаю, что обо этом как раз следует пожалеть). > Чтобы не выглядеть совсем уж троглодитом, немного поясню свою позицию. > Вот здесь Cyberax писал (в посте к reductor), что знание математики, > алгоритмов и т.д. должно быть где-то в "background". > Как видно, в foreground он любовно разместил ("современный") Си++ и > подобные ему языки. Весь этот, с позволения сказать, инструментарий > съедает 90% (а то и более) времени программиста. И выходит так, что > хвост виляет собакой. > Я же полагаю, что как раз язык следует разместить в background. А то и > вообще в "подкорке", чтобы не отвлекал от самой задачи.
Согласен.
И добавлю: C++ тем и плох, что приходится слишком много плясать вокруг
языка, а не собственно проблемы.
Можно сказать и по-другому, более оптимистично: для любой реальной
проблемы в языке C++ существует прямая поддержка (т.е., любая проблема в
какой-то момент превращается в проблему с языком).
Я как-то был поражен, зайдя в знакомую контору, и обнаружив, что там
собралась толпа программистов, и обсуждеает, как им выкрутиться из
очередной нетривиальной проблемы, которую поставил перед ними C++. Как
эта проблема содержательно соотносилась с решаемой задачей, я так и не
понял...
Здравствуйте, Глеб Алексеев, Вы писали:
E>>Нужно только понимать, что для каждой задачи нужен свой язык. ГА>Да, да, да! Так и есть! И можно а) выбрать его из всего доступного инструментария — (Питоны, ОКамлы, ХАскели, Перлы, и Явы, C и C++, естественно) или б)реализовать на единственном языке, который знаешь от и до. Мне вариант а) больше импонирует.
До тех пор, пока не придется впрягать в проект людей, менее увлеченных программированием, чем ты.
Или увлеченных другим направлением в программировании.
Проверено, на личном опыте
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Глеб Алексеев wrote: > > Как раз с точностью наоборот. Unix'ы были созданы в американских > университетах, и все новые языки появляются в первую очередь именно под > юниксами. С инструментальной поддержкой (отладчики, интегрированные
Забавно, что C# это первый язык, который добился широкой известности, не
будучи перед этим рожденным в юниксовской среде.
Интересно, можно ли на этом основании делать вывод, что C# умрет, так и
не осуществив возлагаемых на него надежд? Я склонен думать, что да.
Микрософт при этом совершает совершенно героический поступок, поставив
все фишки на технологию, которая не была 20 лет обкатана на юниксе...
Здравствуйте, Глеб Алексеев, Вы писали:
E>>Может Smalltalk был бы еще эффективнее :) ГА>Сомневаюсь, но мого быть, попробую. Потом, когда время будет. Если вы заметили, я целиком и полностью согласен с Арамисом (ой, с WFrag'ом): чтобы судить о языках, нужно на них попрограммировать (чуть не сказал пописать) чуток. Но не разорваться же мне, сначала одно, потом другое.
Смоллтолк — это такой мутировавший в ОО лисп без скобочек :)
Интересен в первую очередь своим image-based подходом "все свое ношу с собой" и существующими на рынке средами.
RAD на стероидах для всяких внутрикорпоративной фигни.
Хотя, есть просто очень интересные приложения типа Seaside (очень мощный web-фреймворк)
Ложками дегтя служат плохая совместимость между реализациями, древний стандарт, сильная коммерческая направленность коммьюнити и неуемный фанатизм некоторых представителей :)
И упаси бог где-нибудь что-нибудь сказать не так про Алана Кея.
Тем не менее, Squeak — довольно милая штука и хороший пример некоторых идей в области GUI (Он там правда вроде из self'a взят, но смешно — такая взбесившаяся динамичная рефлексивность)
ГА>А кроме того, в ОКамле меня привлекает мощная (а в Хаскеле — и того мощнее) система типов, которая не путается под ногами, а очень помогает при работе с навороченными структурами данных (если я не ошибаюсь, смолток — он динамически типизируемый, так?). А кроме того (опять же понаслышке, никакой категоричности), смолток — классика ОО, а ОО — не самое нужное при экспериментах со сложными алгоритмами. Пройтись по дереву в 3 строчки — вот что нужно.
ОО да, ОО напрягает в смоллтолке больше всего.
Правда за счет динамической направленности это не настолько давит как в Java, но все же.
И из-за этого в большинстве своем смоллтолкеры уверены, что отсутствие статической типизации — единственно верный путь :)
(это я все по материалам чтения конференций и фанклубов друзей смоллтолка :)
Кстати, я упомянул, что в смоллтолк-коммьюнити принято считать, что Java произошла от смоллтолка, а не от С++ или Оберона? ;)
ГА>А я до сих пор уверен, что там масса полезных вещей. И знаете, в чем между нами разница? Я буст попробовал. Просто его оказалось недостаточно. (Тут я осознаю, что у Вас опыта побольше, и в Ваших условиях он может быть категорично неприменим, просто у меня сложилось впечатление, что с некоторых пор Вы встречаете в штыки все радикальные веяния: в С++ не нужны шаблонные навороты, ФЯ нормальному человеку тоже не нужны, программисты-прагматики любят С++, Руби и юнит-тесты :). Просто впечатление, без обид).
Здравствуйте, reductor, Вы писали:
R>Это что, обвинение в чем-то личном чтоли? R>Хоар, Дийкстра и Вирт были принимали участие в создание Алгола (Основная роль была тем не менее все же за Бэкус с Науром) R>Паскаль прямой потомок Алгола.
Немножко неверно. Сначало бы сказал какого Алгола? R>Но это все не имеет никакого значения. Вклад в Computer Science Дийкстры и Хоара несоизмерим с Виртовским. Точнее, Паскаль уже не являлся чем-то особенно заметным в CS. Упрощенный Алгол.
Какой Алгол? R>То, чем занимались Дийкстра, Хоар и Милнер сейчас лежит в основе SML, O'Caml и Haskell.
Насчет Дейкстры и Милнера. Скорее их вклад в данные языки несооизмерим с вкладом Moses Schonfinkel, Alonso Church, Haskell Curry, H. Barendregt, Dana S. Scott, Peter J. Landin, и самое главное John McCarthy. R>Не считая придуманных ими алгоритмов и сделаных открытий. Их влияние _огромно_.
R>А Вирт? Язык Оберон. Даже не смешно. R>То есть реально я вообще затруднюсь сказать что сделал Вирт в CS после своего участия в группе алгола. R>40 лет одна и та же песня.
Не перевирай факты и узнаешь.
AVC>>Я понял, что Милнера (кто это?) и Маккарти Вы ставите выше, чем Вирта. Это Ваше неотъемлимое право. R>Кто такой Милнер? Хороший вопрос на форуме, посвященном программированию. R>Нет, правда. Робин Милнер — это такой человек, который в то время, когда Вирт делал Паскаль, совершил небольшую революцию в CS. R>Создал язык ML и алгоритм вывода типов Хиндли-Милнера. А так же создатель пи-исчисления. Один из самых влиятельных и цитируемых ученых в мире.
Милнер просто реализовал типизацию в комбинаторной логике исследованую Roger Hindley.
AVC>>Но вот насчет оплеух Вирту "по делу", может быть, скажете пару ласковых слов? AVC>>Так сказать, перед смертью. R>А почему перед смертью? Он умирать собрался? R>Хорошего о Вирте могу сказать, конечно — хотел бы я иметь его упорство.
Для начала вы бы посмотрели что же он делал, а потом высказывались бы .
У меня сложилось такое превратное впечатление что любое упоминание о Вирте вызывает неприятие независимо от причины. Мне это не кажется конструктивным.
C>No, you've been brainwashed by CS people who thought that Niklaus Wirth C>actually knew what he was talking about. He didn't. He doesn't have a C>frigging clue.
Ну это такое у нас любят. На Вирта собак спускать.
C>Any if-statement is a goto. As are all structured loops. Подмена понятия языка высокого уровня ассемблером до хорошего не доводят.
C>Ans sometimes structure is good. When it's good, you should use it.
C>And sometimes structure is _bad_, and gets into the way, and using a C>"goto" is just much clearer.
C>For example, it is quite common to have conditionals THAT DO NOT NEST.
C>In which case you have two possibilities
C>- use goto, and be happy, since it doesn't enforce nesting
C>This makes the code _more_ readable, since the code just does what C>the algorithm says it should do.
Ага, и его круто будет рефакторить.
C>- duplicate the code, and rewrite it in a nesting form so that you can C>use the structured jumps.
Или оборачивать в функцию.
C>This often makes the code much LESS readable, harder to maintain, C>and bigger.
C>The Pascal language is a prime example of the latter problem. Because it C>doesn't have a "break" statement, loops in (traditional) Pascal end up C>often looking like total shit, because you have to add totally arbitrary C>logic to say "I'm done now".
Я начинал с Паскаля. Скажу честно, после Паскаля еще года два три, вообще ни break ни continue в циклах не использовал. Не потому что не нравилось, конструкции нормальные, просто не нужно было. Как то автоматически рука была набита обходиться без них. Да и сейчас у меня редко встретишь эти инструкции. Хотя только сейчас обратил внимание на данный факт.
C>У меня все больше уважения к этому товарищу!
Зато у меня меньше.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, reductor, Вы писали:
GZ>>>И Ульман что изобрел. Учебник хороший, не скрою. Но какой у него вклад? Но самое интересное, где Кодд? Вобщем это не вклад, а филькина грамота. R>>Во-первых вы что-то с неумеренной частотой мне отвечаете. GZ>Не вам, а вашим сообщениям. R>>И без всякого смысла транслируете сюда рейтинг сайтсира по одному. GZ>Смысл в том, что там смысла в этом индексе нет. Ну делают дисеры по функциональным языкам значительно чаще чем по структурным. Ну и ссылок поэтому больше.
Во-первых, раз и навсегда — идея противопостовления структурного и функционального программирования — это крайне дикая идея. Функциональные языки, надо полагать, не вписываются в языки "структурные"?
Далее. Есть одна наука. Одна математика. Одна информатика. Одна логика. Одно программирование.
Если в науке нет публикаций на какую-то тему, значит эта тема неактуальна. Уже неактуальна, еще неактуальна, вообще неактуальна и несуществует или не имеет смысла — что угодно, значит темы нет. Почему нет дисеров по "структурном языкам"? По поиску философского камня? Торсионным полям? Биоэнергетике? Школьной арифметике? Полетам на альдебаран?
А вот потому.
Если кого-то душит ощущение несправедливости по этому поводу или он считает, что научные институты — это масонский заговор и настоящих ученых зажимают, то с этим к психиатру.
GZ>Если вы хотите знать кто больше повлиял, то это делается очень легко. В CS есть такая же премия как и нобелевка в остальных науках, или Oscar в кинематографии. Называется премия Тьюринга. Посмотрите туда.http://www.acm.org/awards/taward.html Надеюсь вы не будете говорить о том что этот источник не достоен доверия?(кстати там можно увидеть и милнера, беру свои слова назад. Неодоценивал его).
Во-первых, никакая премия не может считаться отражением чьих-то заслуг. Тем более чьего-то перед кем-то приоритета.
Любая премия — это мнение комитета или мецената, который эту премию выдает. Если это сложно понять, то это нужно просто запомнить. Как аксиому. Как отче наш.
Далее, сравнение с Оскаром тут совершенно правильное. ПТ — это скорее профессиональная и общественная премия, а не научная. "ACM's most prestigious technical award is accompanied by a prize of $100,000. It is given to an individual selected for contributions of a technical nature made to the computing community. The contributions should be of lasting and major technical importance to the computer field. Financial support of the Turing Award is provided by the Intel Corporation. "
К канским львам и нобелевке ни оскар ни ПТ не относятся.
Да и канские львы с нобелевкой — это скорее политическое явление.
И еще. Такие премии получают раз в жизни и как угодно сравнивать двух лауреатов без дополнительной информации нет никакой возможности. Поэтому, предлагаю больше не заниматься такой профанацией.
R>>Во-вторых, если вы чувствуете в себе дефицит образования и не можете ответить на вопрос чем заслужил второе место в списке Джеф Ульман, то лучше заняться своим образованием, чем пропагандировать здесь антиинтеллектуализм. GZ> Открою маленький секрет. В теория баз данных для меня нечто типа хобби. Поэтому я могу говорить о вкладах в теорию БД более квалифицированно. И могу судить о вкладах Codd'a и Ульмана.
Ну расскажите тогда о своем квалифицированном мнении о Кодде и Ульмане. С цитатами, примерами и подробным научным анализом. Чтобы уже ни у кого не оставалось сомнения в том почему создатель например реляционной модели недостоин иметь такое количество цитат на его работы.
А рекламу квалификации напишите кстати лучше в резюме. Здесь, я думаю, ее и без дополнительной рекламы способны оценить по тому что вы пишите.
Здравствуйте, AVC, Вы писали:
AVC>Конечно, "оберонщики" на rsdn.ru во многом сами виноваты. Нас здесь всего пара человек (Сергей да я), а такой стойкий негативный эффект. AVC>Но некоторая "антипатия к Вирту" существует давно, и с нашими проделками на rsdn.ru не связана.
По-моему, Вирт все же больше относиться к академикам (где его достижения
действительно весьма большие), а не к практикам.
Паскаль был абсолютным хитом в свое время — хороший, продуманый, простой
язык. Он оказал влияние на кучу последующих языков, и до сих пор
используется для обучения. Одно это тянет на премию Тьюринга
Добавлю, что, возможно, именно Паскаль помог уйти от разработки монстров типа PL/1. Иначе, был бы сейчас какой-нибудь PL/3, объединяющий все самое худшее из всех течений в программировании.
AVC>Возможно, здесь какая-то (бессознательная) неприязнь к "конкуренту", или что-нибудь другое.
Вирт учит делать то, что можно так, как нужно. Однако в жизни большинство программистов делают то, что нужно так, как можно (сроки поджимают, из бюджета вываливаемся и т. д.). Вот именно с этим противоречием и связана критика его работ. (В скобках заметим, что сторонники Вирта в долгу не оставались. В прессе одно врема такой флейм шел — Священнъе войны отдыхают)
AVC>Главное, присоединяюсь к призыву критиковать не личности, а поступки и высказывания.
Здравствуйте, Pzz, Вы писали:
>> ИМХО, этой пародией детей пугать можно...
Pzz>Но влияние-то оказывает
Меня как раз тут в свое время "уличали" (eao197 и CrystaX), что я пишу на Си с классами, а не на "современном" Си++ (с шаблонами и большим boost-ом).
Так что на меня шаблоны оказывают весьма умеренное влияние (в основном — в виде ночных кошмаров).
А ML — вообще никакого. (Допускаю, что обо этом как раз следует пожалеть).
Чтобы не выглядеть совсем уж троглодитом, немного поясню свою позицию.
Вот здесь Cyberax писал (в посте к reductor), что знание математики, алгоритмов и т.д. должно быть где-то в "background".
Как видно, в foreground он любовно разместил ("современный") Си++ и подобные ему языки. Весь этот, с позволения сказать, инструментарий съедает 90% (а то и более) времени программиста. И выходит так, что хвост виляет собакой.
Я же полагаю, что как раз язык следует разместить в background. А то и вообще в "подкорке", чтобы не отвлекал от самой задачи.
Вот я и нашел для себя Оберон. Такому дураку, как я, — в самый раз.
Личная производительность (моя, о других не говорю) с Обероном выше.
А если кому-то кажется, что это непрогрессивно или ненаучно, что ж... Краснею до корней волос, но делаю по своему.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, reductor, Вы писали:
C>>Только не в языках с GC. Там это норма.
R>в языках с GC норма — руками освобождать ресурсы? R>по-моему вы уже заговариваетесь.
Вообще-то, в словах "управление памятью" напрямую указано, каким именно ресурсом может оперировать сборщик мусора. Но, увы, ресурсом, является не только память программы.
Здравствуйте, reductor, Вы писали:
R>Прагматичнее, да. R>Мацумото во всеуслышание объявляет, что у него взорвался мозг, когда он пытался разобраться с хаскелем, после чего идет делать "прагматичный" язык.
И с этим можно согласиться, после такого:
append = foldr ((.).(:)) id -- вот как это понять, кроме как разложить (.) на лямбды? (дважды;)
и, в особенности, такого:
cfold' f z [] = z
cfold' f z (x:xs) = f x z (\y -> cfold' f y xs)
cfold f z l = cfold' (\x t g -> f x (g t)) z l -- это ж надо столько рекурсивных лямбд наворотить!
R>Почему-то мне кажется, что хаскель он не смог освоить, потому что у него уже был разорванный мозг. Смоллтолком.
Може и так. А у меня, значит, Лиспом
PS Я не против Хаскеля, он мне очень понравился, это хорошее продолжение традиций Лиспа, но некоторые вещи, с виду совсем простые, иногда очень не просто понять.
Здравствуйте, reductor, Вы писали:
R>Не совсем правильный подход (хотя даже так вирт уступает в 4 раза). R>Идем сюда: http://citeseer.ist.psu.edu/mostcited.html R>Там собраны самые цитируемые ученые вообще (суммарно все публикации). Видим, что Милнер там на четвертом месте. R>В окружении Ульмана, Кнута, Дийкстры, Хоара, Ривеста, Шамира, Лейзерсона и так далее (Надеюсь, представлять этих товарищей не нужно).
Занятно. А интересно Брукс что такого изобрел что его цитируют больше чем Дейскстру. И вообще, он является ученым? Даже серебрянную пулю смог изобрести.
Здравствуйте, GlebZ, Вы писали:
GZ>Занятно. А интересно Брукс что такого изобрел что его цитируют больше чем Дейскстру. И вообще, он является ученым? Даже серебрянную пулю смог изобрести.
ну уж Брукса не надо трогать
он еще в те древние времена писал про такие вещи, которые и сейчас до многих не доходят
GZ>> Виртом был создан первый структурный язык с нормальным дизайном и с модульным принципом построения программ.
R>Нет слов. Тихий ужас
Естественно, так как нет слов, то и ужас может быть только тихим.
GZ>>Ну или возьмем EBNF. Это тоже упрощение Вирта. Сейчас уже де факто он используется вместо BNF.
R>Знаете, всему нужно знать предел. Где в сочетании Backus-Naur зашифрована фамилия Wirth?
В Extended.
А еще имя Вирта хитро зашифровано в сочетаниях Эйлер, PL360, Паскаль, Модула, Модула-2, Оберон, LOLA, OLGA и т.д.
GZ>>Но вообще, наибольшее достижение Вирта — это школа построения компиляторов. Во многом те компиляторы которые мы используем — это детище Вирта. Потому как Паскаль и Модула, его работы связанные с ними и послужили примером что такое эффективный концептуальный компилятор.
R>После этого заявления, я прекращаю дальнейшее обсуждение с вами любых тема, касающихся Computer Science. R>Пардон, что личное, но мне дорого мое время. R>Школа компиляторов — Это Backus, McCarthy, Knuth, Turner, Milner, Strachey, Scott и так почему-то нелюбимый вами Ульман вот с этой книжкой: http://www.amazon.com/gp/product/0201100886/002-5958156-7611205?v=glance&n=283155&n=507846&s=books&v=glance R>Если очень хочется, туда еще можно Хомского записать. R>Не буду даже спрашивать, кто эти "мы", которые пользуются исключительно детищами вирта для компиляции.
Вот такие придурки как я и пользуются "детищами Вирта".
Чему тихо радуемся.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, GlebZ, Вы писали:
GZ>Поэтому предложил бы объявить людей, которые являются Нобелевскими лауреатами и лауреатами премии Тьюринга священными коровами. И баннить наезды на них по полной так же как и наезды на личности на rsdn. То есть добавить правило что личности из списка Премии Тьюринга священны, и личные нападки на этих людей есть нападки на все IT сообщество. Можно наезжать на поступки, нельзя наезжать на личность.
GZ>С уважением, Gleb. GZ>ЗЫ. Это кстати сильно поубавило бы флеймистость Философии программирования.
Я тут конешно новенькая и меня легко затоптать. Но сложите 2 и 2. Лауреаты премии Тьюринга люди не святые. Но коли с ними переходят на личности то уж никак не от большова ума. И што тут спорить? Ну а научный уровень Линуса Торвальдса можно даже не обсуждать. Хотя я не удивлюсь если его протолкнут в лауреаты Тьюринга. Такова жизнь.
У вас замечательная точка зрения. Самая лучшая точка!
R>>Дийкстру, с его стандартами программиста откопать и сжечь вместе с рукописями. R>>А MIT, CMU, Stanford и Yale — расстрелять из BFG, чтобы не плодили яйцеголовых умников.
E>Ну все, трындец. Хорошие программисты -- это только из MIT, CMU, Stanford, Yale... А вот мне, похоже не суждено. Не там уродился. :(
Да, извините, если я вас обидел. Я очень неполиткорректен. Вас я не учел. Скажите, и я тут же внесу указаное вами место в список расстрела BFG. Персонально, или у вас за альма-матер сердце болит?
Еще если хотите, чтобы искупить свою вину, могу внести в список выкапывания и сжигания вместе с рукописями.
reductor wrote:
> C>Хороший программист о них, конечно, должен знать, но это скорее просто > C>background knowledge (как мат.анализ или алгебра). > Да ладно. Конечно не должен! > Хороший программист — это когда в слюнявчике, утка, детское питание по > катетеру, мышь без колеса и клавиатура с одной кнопкой — для вызова > сиделки с проджект менеджером.
А если серьезно, где теория необходима прикладному программисту?
Например, я не помню, чтобы мне где-то понадобилось использовать
алгоритмы быстрой факторизации чисел или доказывать правильность алгоритма.
Полезного из теории могу вспомнить O-нотацию для оценки скорости, но я
до нее еще в школе сам додумался Я даже трехмерной графикой вполне
успешно занимался без знаний подробностей работы алгоритма триангуляции
Делоне или критериев оптимальности разбиения.
Бывают задачи (типа цифровой обработки сигналов, например), где без
теории — никуда. Но это уже исключения, подтверждающие правило.
Здравствуйте, eao197, Вы писали:
E>По моему опыту, общего между Java и С++, после глубокого в них погружения, оказывается только синтаксис.
Не могу не уступить вашему опыту.
E>И есть у меня сильное подозрение, что когда речь идет о знаниях 20 языков, то речь идет именно о поверхносных знаниях. Которых может оказаться совершенно недостаточно для реализации системы объемом, к примеру, в 100 тысяч строк.
На всякий случай скажу, что 100 000 — это очень небольшая система. Вообще.
E>Нет, хочу показать, как без знания тонких моментов конкретного языка можно потратить массу времени в отладке (еще хорошо, если такая проблема проявится в отладке, а не после 6-ти месяцев эксплуатации в системе 24x7, когда все уже уверились в ее надежности).
Спасибо за ценный урок.
E>Или еще гипотетический пример из подсистемы кэширования таблиц СУБД. Представь себе код:
Сижу, пытаюсь представить.
E>со всеми вытекающими отсюда последствиями, которыми так любят пугать в C++.
Да, незадача.
E>Поэтому придется работать с тем, кто есть. И если человек заявляет (либо ведет себя), что "я, да 20 языков, да любой язык за полдня", то это либо горлопан, от которого нужно сразу избавляться, либо новичек, которого еще учить и учить.
Если вы про меня, то я к вам пока на работу не устраивался. И вроде даже не заявлял о возможности такого намерения.
E>Гипотетически, конечно, возможно, что мне повстречается кто-то типа Ульмана или того же Вирта. Только, во-первых, шансы на это пренебрежительно малы. И, во-вторых, это сразу станет заметно, поэтому все сразу встанет на свои места.
Не упущу возможности заметить, что Ульман и Вирт слишком разных уровней "работники", чтобы вот так через "или".
А что про шансы, думаю да. Шансов у вас никаких.
E>Пока же мой опыт говорит, что результатов достигают не научно-мыслящие эрудиты и полиглоты, а трудяги, который умеют лямку тянуть. И, что характерно, мало кто из них заявляет о знаниях больше, чем нескольких языков.
Ну что же, против опыта не попрешь. Даже против такого.
E>>>Помогут ли они тебе при реализации, например, подсистемы кэширования таблиц РСУБД на языке C. При условии, что подсистема должна быть портабельна на Solaris, HP-UX, AIX, Linux, *BSD и Win32 (Win2k, XP, 2003)?
R>>Однозначно, особенно кеширования R>>Кстати, можно и MacOS туда вписать. Я всегда все на нее портирую тоже.
E>Если это ирония, то напрасная. Я как раз занимаюсь написанием софта, который вынужден работать на этих платформах (только до HP-UX и AIX пока не добрались , вместо них HP NonStop Kernel) и пишется на С++.
Кстати, про много платформ у вас такое же мнение как и про много языков?
E>Я не спорю с твоим опытом (просто даже не знаю, как о нем вообще судить можно, на основании чего ). Меня двигает то впечатление, которое создают твои посты. "Вирт -- это смешно", "Программы верифицируемы по спецификациям", "Существует способ писать программы без ошибок", "Любой язык за полдня", "Что такого в C++ по сравнению с Common Lisp, Haskell, ML?", ...
То ли впечатление такое сильное, то ли сила трения слабая, что аж прямо двигает...
E>Ты напоминаешь инженера из КБ, который привез новый станок на производство. Типа: "Он все сам, самые последние достижения научной мысли, эноргомика на высшем уровне, любые операции...". А потом выясняется, что здесь пол не очень ровный, и загазованность в помещении слишком высокая, и влажность недостаточно низкая, и за эту рукоятку промасленной перчаткой лучше не браться, и протирать его от пыли обычной тряпкой нельзя, и детали такого размера обрабатывать уже нельзя, и токаря дядю Ваню на три месяца на курсы повышения квалификации отправить нужно, а стажера Вовочку ближе трех метров подпускать не следует...
Какой однако смачный переход на личности. Причем, хочу заметить, не в первый раз.
Скажите, вас что-то в вашей работе не устраивает, что я уже в который раз замечаю такой напор личных претензий?
Хотите услышать кого вы мне напоминаете?
Впрочем, я отложу это признание ровно до следующего такого раза.
E>В общем, обычный разрыв между наукой и производством.
Нет, в моем случае я являюсь связью между наукой и производством. Я ее[науку] использую на этом производстве самым циничным способом.
Да, мне стыдно.
Здравствуйте, reductor, Вы писали:
E>>И есть у меня сильное подозрение, что когда речь идет о знаниях 20 языков, то речь идет именно о поверхносных знаниях. Которых может оказаться совершенно недостаточно для реализации системы объемом, к примеру, в 100 тысяч строк.
R>На всякий случай скажу, что 100 000 — это очень небольшая система. Вообще.
Ну да. А если этой системой занимается один человек и делает в течении года?
E>>Поэтому придется работать с тем, кто есть. И если человек заявляет (либо ведет себя), что "я, да 20 языков, да любой язык за полдня", то это либо горлопан, от которого нужно сразу избавляться, либо новичек, которого еще учить и учить.
R>Если вы про меня, то я к вам пока на работу не устраивался. И вроде даже не заявлял о возможности такого намерения.
Нет, не про тебя.
E>>Гипотетически, конечно, возможно, что мне повстречается кто-то типа Ульмана или того же Вирта. Только, во-первых, шансы на это пренебрежительно малы. И, во-вторых, это сразу станет заметно, поэтому все сразу встанет на свои места.
R>Не упущу возможности заметить, что Ульман и Вирт слишком разных уровней "работники", чтобы вот так через "или". R>А что про шансы, думаю да. Шансов у вас никаких.
Думаю, что не только у меня, но и у 80% посетителей RSDN (если не больше).
E>>Если это ирония, то напрасная. Я как раз занимаюсь написанием софта, который вынужден работать на этих платформах (только до HP-UX и AIX пока не добрались , вместо них HP NonStop Kernel) и пишется на С++.
R>Кстати, про много платформ у вас такое же мнение как и про много языков?
Хм... Не задумывался. Имхо, Unix сильно отличается от Windows, если речь идет о shell и использовании unix-way. NonStop -- это отдельная песня. В OSS там все как в Unix, а вот в Guardian -- мрак, сам не пробовал, ведел как другие работают. Это совсем другая планета.
R>Какой однако смачный переход на личности. Причем, хочу заметить, не в первый раз.
И? Про личность Вирта, значит, можно? А...
R>Скажите, вас что-то в вашей работе не устраивает, что я уже в который раз замечаю такой напор личных претензий?
Нет, работа замечательная, долго к такой стремился.
Меня призраки прошлого гнетут. Когда я решил повторить достижение Константина Книжника и защитить дисертацию по собственноручно написанной объектной СУБД (Косте удалось это сделать по своей СУБД GOODS). Никого не интересовали технические подробности ее реализации, ее возможности, оснащенность утилитами, полезность и реальные внедрения в реальные проекты. Все вопросы начинались с количества моих публикаций. Максимум, до чего доходило -- это до: "В чем состоит научная новизна?" и "Что было сделано лично вами?". Обычно разговор на вопросе "научной новизны" терял свою актуальность. А апофиозом моего обучения в аспирантуре был вопрос от зав.кафедрой: "Это хорошо, что ты занимаешься объектно-ориентированными базами данных, но на что конкретно они у тебя ориентированны?". Хотя дяденька был очень заслуженный и шамповал кандидатов по своему направлению как горячие пирожки. А еще я видел, как эти ученые дяденьки штампуют одну статью за другой, переставляя абзацы из своих старых работ и заставляя аспирантов или дипломников расчитывать для них очередную формулу или переоформляя какой-нибудь график. Поэтому количество публикаций или рейтинг цитирования для меня совершенно пустое место.
Так что когда кто-то в разговоре о программировании начинает заходить в высокие научные материи, то это уже вызывает у меня раздражение. А когда это делается так, как делаешь ты, высказываясь про Вирта или про свободное владения 20 языками программирования, то сдерживаться становиться совсем тяжело.
R>Хотите услышать кого вы мне напоминаете?
Да.
E>>В общем, обычный разрыв между наукой и производством.
R>Нет, в моем случае я являюсь связью между наукой и производством. Я ее[науку] использую на этом производстве самым циничным способом. R>Да, мне стыдно.
Ты меня подкалываешь по поводу личных наездов. А ведь твоя тонкая ирония и уходы от конкретных вопросов конструктивному диалогу так же не способствуют. Например, я спрашивал, как может использоваться связка Java+Prolog и что в этой связке выигрышного. Ответа не получил.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
E>> Вот так я и стал C++ником
ANS>На жалость давиш
Не-а, радуюсь
Благодоря этому я стал C++ником, а теперь еще и Rubyist-ом!
Жалко только, что в универе на изучение Oberon-ов, Smalltalk-ов, Lisp-ов и пр. было гораздо больше времени, чем сейчас, да и новые знания всасывались со страшной силой. А сейчас на это время выкроить тяжело, иногда не успеваешь изучать то, что по работе нужно.
Вот и vdimas недавно сказал что-то вроде: "Где бы время найти, чтобы с Haskell-ем познакомиться".
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Меня призраки прошлого гнетут. Когда я решил повторить достижение Константина Книжника и защитить дисертацию по собственноручно написанной объектной СУБД (Косте удалось это сделать по своей СУБД GOODS). Никого не интересовали технические подробности ее реализации, ее возможности, оснащенность утилитами, полезность и реальные внедрения в реальные проекты. Все вопросы начинались с количества моих публикаций. Максимум, до чего доходило -- это до: "В чем состоит научная новизна?" и "Что было сделано лично вами?". Обычно разговор на вопросе "научной новизны" терял свою актуальность. А апофиозом моего обучения в аспирантуре был вопрос от зав.кафедрой: "Это хорошо, что ты занимаешься объектно-ориентированными базами данных, но на что конкретно они у тебя ориентированны?". Хотя дяденька был очень заслуженный и шамповал кандидатов по своему направлению как горячие пирожки. А еще я видел, как эти ученые дяденьки штампуют одну статью за другой, переставляя абзацы из своих старых работ и заставляя аспирантов или дипломников расчитывать для них очередную формулу или переоформляя какой-нибудь график. Поэтому количество публикаций или рейтинг цитирования для меня совершенно пустое место.
любую систему или метод можно извратить и сделать бесполезными
а то, что наука в нашей стране окончательно прогнила и практически ни на что не годится — это и так известный факт
0xDEADBEEF wrote: > > ЗЫ. Когда приходят к нам наниматься, я прошу кандидата с написать с нуля > любой алгоритм сортировки. Как ни странно, встречаются экземпляры, > которые не могут. И их достаточно много.
Я бы написал сортировку пузырьком, чтобы не рисковать в стрессовых
условиях собеседования.
Интересно, вы бы это расценили как плюс или как минус?
P.S. Мы использовали аналогичный подход на своих собеседованиях, только
давалось штук 10 задач, и "подсудимому" самому предлагалось решить,
какие из них выполнять, а какие нет.
Вместо сортировки у нас был подсчет числа локальных максимумов в массиве
чисел. Впрочем, сортировка тоже была — но quick sort, и мало кто за нее
брался.
Опыт показал, что такой подход позволяет очень хорошо узнать человека
как специалиста, за час-полтора времени собеседования. Например, очень
хорошо видно, с чьим кодом будут постоянные проблемы из-за отсутствия
хоть каких-нибудь проверок во время исполнения.
reductor wrote: > > Кроме того, что некоторые вещи в С++ будешь делать год, чтобы > заработало, другие там еще и вовсе невозможны по фундаментальным причинам.
Не согласен. На C++ можно написать LISP за неделю, а все остальное
сделать на LISP'е
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
E>>>Да. И не только моему. Думаю, что многие из учасников форума C/C++ со мной согласятся.
R>>Перечислять эти 15 языков, которые вы знаете, вы, конечно, откажетесь?
E>Нет. Но я не знаю 15 языков. E>На сегодняшний момент я пользуюсь двумя: С++ и Ruby. Знаю их на относительно среднем уровне.
Так на каком тогда основании делается предположение, что С++ сложнее 15 языков?
E>Зато ты, как я понимаю, знаешь больше 15-ти, но C++ толком не знаешь. Хотя, как мне кажется, С++ в этот список будет входить.
А вы уверены, что вы знаете С++ достаточно, чтобы оценить насколько его знаю я?
Если уж вы так настойчиво хотите обсудить эту тему.
R>>чтобы сохранить получившийся AST в виде s-expressions.
E>Не, на уровне AST я пас. Никогда его не строил.
Потрясающее откровение.
Знаете что такое "знать язык" в моем понимании?
Это когда понимаешь как он работает — когда можешь написать компилятор или интерпретатор этого языка.
ГА>>В SML можно использовать состояние внутри функции GZ>Конкретнее.
В SML и (особенно) в O'Caml есть императивные конструкции (в OCaml есть даже for- и while- циклы).
Вот пример как не надо, но можно делать:
fun imperative fact (n:int) =
let
val result = ref 1
val i = ref 0
fun loop () =
if !i = n then
()
else
(i := !i + 1;
result := !result * !i;
loop ())
in
loop (); !result
end
Конечно, все это выглядит достаточно некрасиво и неудобно, чтобы в таком духе писать программы полностью, но в низкоуровневом коде встречается (в реализации массивов, хэш-таблиц, потоков I/O).
Весь ввод/вывод в ML является императивным. В стандарте языка есть библиотека функционального ввода-вывода, но реализации ее я не видел (ни в Moscow ML, ни в SML/NJ).
Кроме того, в базовых библиотеках как SML, так и OCaml есть массивы и хэш-таблицы — mutable структуры данных. Ну и т.д., reference cells — это и есть, собственно, "состояние внутри функции".
Что характерно, при этом клиентский код, который пользуется потоками, массивами и т.д., становится императивным без явного использования ref cells и оператора :=. Поэтому с одной стороны, языки семейства ML более легки в освоении для программистов-императивщиков и считаются более практичными, т.к. ввод-вывод нужен везде, и интерактивность, из которой следует глобальное изменяемое состояние, нужна очень часто; с другой стороны, нужна дисциплина, чтобы не перечеркнуть разом все преимущества ФП (в Хаскеле IO живет в гетто, выйти из которого не позволяет система типов).
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, GlebZ, Вы писали:
GZ>>Занятно. А интересно Брукс что такого изобрел что его цитируют больше чем Дейскстру. И вообще, он является ученым? Даже серебрянную пулю смог изобрести.
Д>ну уж Брукса не надо трогать Д>он еще в те древние времена писал про такие вещи, которые и сейчас до многих не доходят
Отзываю. Против ACM не попрешь.http://www.acm.org/announcements/turing99.html
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
R>>В моей обычной практике я использую около 30 языков программирования. Среди них хватает и императивных и функциональных и логических и стековых и гибридов всего этого смешанных вместе.
E>Можно ли развить эту тему по-подробнее?
Это был ответ на предположение, что я не знаю "императивных" языков.
Я буквально ответил, что знаю и много. Речь не про "в одном проекте"
E>Это действительно интересно, т.к. недавно я утверждал, что сложно одновременно использовать в проекте 3-5 языков (Re[2]: Предагаю мир!
Сложно, если кто-то в команде не знает какого-то языка и не желает его осваивать, а это необходимо.
Иногда это можно уважать и что-то придумать, иногда — изменяется состав команды.
В любом случае, у меня нет оснований считать, что количество языков в проекте каким-то образом влияет на его "сложность" при разработке. Хотя, возможно, более вероятно, что проблем будет больше при поддержке, если в ней участвует малое количество не очень восококвалифицированных программистов.
E>Но здесь цифра просто на порядок большая . Можно ли подробнее, что это за языки, для каких целей используются, как применяются, какие замечены достоинства/недостатки использования такого количества языков, используется ли это все в рамках одного проекта, какова численность команды и пр.?
Ничего, если я не буду перечислять все 30, что могут быть?
Одновременно в одном коммерческом проекте могут использоваться 3-5 полноценных, тьюринг-полных языков, особенно в клиент-серверном случае.
Как пример — Java/Prolog/Scheme/Python (Все могут быть и в пределах одной java-машины) на сервере и Smalltalk, Javascript, Tcl на клиенте. + еще VB на клиенте внутри Ms Office
Это конечно не считая кучи domain specific языков для конфигурации, интеропа, DB, GUI и тп
Вообще в чем проблема, квалифицированному программисту выучить любой язык, если очень нужно — полдня максимум
Команды 2-5 человек
Еще замечу, что количество человек в команде не такую уж и большую роль играет. 2 опытных человека используя правильные инструменты сделают работу быстрее, чем 20 не таких опытных с неподходящими инструментами.
Здравствуйте, Дарней, Вы писали:
E>>Вирт как раз является человеком, который умеет делать успешные продукты.
Д>"успешные продукты" (во множественном числе) — это Паскаль?
Давай определимся с критериями успешности. Если успешность продукта определяется количеством проданных/используемых копий, то, вероятно, только Паскаль подойдет под это определение.
Если же под успешностью продукта понимать возможность применения продукта там, где другие продукты не конкурентноспособны, то можно еще подсчитать и Modula-2 и Oberon-ы. Они же таки применяются. Пусть в органиченных областях, но применяются. Хотел бы я, чтобы результаты моих трудов были распространенны хотя бы так же, как Modula-2/Oberon.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, z00n, Вы писали:
Z>Влияние функциональных языков, на мой взгляд, и сейчас весьма заметно. C++ STL, например. Или вот вам понравилось передавать функции как параметры в Руби — это оно самое и есть. Функциональный стиль программирования так или иначе поддерживает большая часть вполне мейнстримных языков: Java Script, Python, Ruby, Perl, Lua, C#. Другое дело, что и на них большинство людей будут продолжать писать, как на своем предыдущем Впрочем, вы сами все это знаете.
Это все так, но здесь появляется другой фактор, который не следует упускать из виду: языки становятся мультипарадигменными (как C++, который много за это ругают). И успешное применение мультипарадигменного языка будет требовать от программиста других навыков, чем в чистом ООП или чистом функциональном стиле. В противном случае будут получаться монстры вроде Boost.Mpl или Boost.Lambda. А это означает, что во многих случаях придется "ломать" себя и отказываться от конструкций, которые в любимом Scheme очень удобны (какой-нибудь map или accumulate), а вот в C++ или Ruby корявы и малопонятны. Если эта ломка пройдет успешно, то и программы будут нормальными, и впечатление от работы хорошим. А если нет, то и программа будет корявой, и впечатление ужасным, и язык/среда разработки/операционка будут поноситься со страшной силой. А все потому, что со своим уставом -- в чужой монастырь.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>world1 = do_smth1 world0 ГА>world2 = do_smth2 world1 ГА>world3 = do_smth3 world2 ГА>[/code] ГА>Где-то смутно ощущаю, что IO-монада и do-нотация в Хаскеле примерно это и делает, только с синтаксическим сахаром (просьба ногами не бить, с теорией категорий не знаком, с Хаскелем знаком по туториалам и паре самостоятельно выполненных "Hello cruel world" в Hugs, это мое интуитивное понимание на сегодняшний день. А т.к. Haskell is a language of choice for discriminating hackers, я с ним еще обязательно разберусь получше ).
Нет-нет, в случае IO Monad все совсем не так, все гораздо проще
я чуть попозже напишу поподробнее почему ни состояния ни ввод-вывод не являются никакой проблемой в хаскеле вообще и в любом языке в принципе, поддерживает он императивный ввод вывод или нет. Сейчас времени нет — там немного длинно получится.
Тема безумно интересная и важная.
Здравствуйте, AVC, Вы писали:
К>>Не факт, что это язык поставил проблему. Может быть, проблема была в архитектуре, а специфика мировосприятия программистов перевела её на рельсы кодирования.
AVC>Переведи...
Давным-давно один человек (не буду тыкать пальцем ) придумал, что печать страницы с переменной информацией можно представить как вычислительную сеть, промежуточные узлы которой — счётчики, слушатели com-порта и т.п., главный источник — фотодатчик на конвеере, главный приёмник — модуль рендеринга страницы.
Изначально задумывалось, что сеть асинхронная (часть данных может приходить загодя, или вообще в ином темпе, чем осуществляется печать; кроме того, одновременно сосуществуют до четырёх задач печати — обычно изолированных друг от друга, но, может быть, и пересекающихся).
Поэтому каждый узел сам занимается рассылкой извещений. Соответственно, каждый из них защищает себя мьютексом.
Предполагалось, что сеть сначала развёртывается, затем работает, затем задача останавливается и сеть прибивают.
Но жизнь внесла свои коррективы: возможна такая ситуация, что сеть начали прибивать (со стороны приёмника в сторону передатчиков), а в это время один из передатчиков — внешний по отношению к задачам — заряжает туда данные. И в некотором месте они сталкиваются. Беда в том, что сталкиваются две лавины: если одну из них заблокировать, то получим дедлок. А если одну лавину обломить и затем повторить попытку ещё раз — не факт, что и эта попытка будет успешна. В самом худшем случае сеть просто рвалась, создавая объектов-вдов (которые принимали данные, но никуда их не отправляли — и стремительно выжирали память).
Так вот. На низком уровне — стоял вопрос: как бы так грамотно сделать, чтобы разослать данные потребителям, выйдя из-под мьютекса (но не порушив самого себя). Да ещё всё осложняется, что мьютекс рекурсивный, то есть,
не гарантирует, что в момент рассылки объект не заблокирован.
А сделать глобальный мьютекс на всю систему (типа, умерла так умерла, рассылаем так рассылаем) — нельзя, потому что лавина — штука медленная, и пока одна задача работает, остальные три будут куковать.
Как вариант, можно делать отложенное выполнение рассылки — тогда придётся отслеживать, жив ли объект-приёмник. Чтобы указатель на него в очереди был валидным, требуется контроль живучести — например, на подсчёте ссылок. Тогда приёмник должен различать, был ли он демонтирован (и теперь просто доживает последние миллисекунды) или он очень даже функциональный.
Видите, как архитектурный просчёт (выбор избыточной и плохо контролируемой модели, а затем забыли юз-кейс свёртывания-развёртывания на лету) свалился до уровня вопросов "какие подфункции и как вытащить из-под мьютекса" и даже "как бы так сделать трёхступенчатую деструкцию объектов (узлов сети / COM-объектов / С++-объектов)", и чтобы это было детерминированным (проблема объектов-вдов) и в то же время не совсем ручками (приветствуются GC и RAII).
Засада, правда, в том, что не только архитектуру менять, но и "в основном работающий" код переписывать — нельзя. Первая бета прошла, по срокам не впишемся.
(Это ещё и характеризует баг менеджмента — но тут уж нам ничего не поделать).
ГА>Где-то смутно ощущаю, что IO-монада и do-нотация в Хаскеле примерно это и делает, только с синтаксическим сахаром (просьба ногами не бить, с теорией категорий не знаком, с Хаскелем знаком по туториалам и паре самостоятельно выполненных "Hello cruel world" в Hugs, это мое интуитивное понимание на сегодняшний день. А т.к. Haskell is a language of choice for discriminating hackers, я с ним еще обязательно разберусь получше ).
Кстати забыл сказать. что-то типа этого в общем случае делает монада State
Причем, это вовсе не magic trick компилятора, а вполне самостоятельно реализуемая функциональность.
Еще в хаскеле естьб пара "задних ходов" для непосредственного сохранения состояния — те же Refs, обернутые в закрытые монады, чтобы не шалилось, но в общем случае можно симулировать среду для написания очень похожего на ML кода (но прямо так — смысла нет, можно красивее).
Здравствуйте, reductor, Вы писали:
AVC>>Видно, Линусу проще добиться уважения критикой Вирта, чем выведением багов из ядра?
R>Так это ж известно, главное — не мотивировать свои слова, а побольше харизмы. R>Слабак! R>
Здравствуйте, Дарней, Вы писали:
Д>насколько я помню, EBNF не добавляет к возможностям BNF ничего нового, кроме небольшого количества синтаксического сахарка Д>в общем, не то это достижение, которым стоит гордиться
Во первых я хотел показать роль. Я не знаю насколько сам Вирт гордится таким достижением, но то что это сделал он — это факт. Я тоже не стану говорить насколько это было важно. Для меня важнее было, что оно есть. Во-вторых, Вирт с его страстью к упрощению здесь сыграл положительную роль. И я сомневаюсь что кто-то меня опровергнет.
reductor wrote:
> C>А если серьезно, где теория *необходима* прикладному программисту? > C>Например, я не помню, чтобы мне где-то понадобилось использовать > C>алгоритмы быстрой факторизации чисел или доказывать правильность > алгоритма. > Не знаю, по-моему везде. > Например, чтобы понимать нерешаемость какой-то задачи.
Какие нерешаемые задачи приходится решать прикладному программисту?
Кроме отечественной бухгалтерии, естественно.
> Или чтобы понимать какой аппарат или алгоритм для какой задачи больше > подходит.
Теория нафиг не нужна. Нужно знание требований данного алгоритма
(O-нотация по скорости и памяти) и деталях реализации.
Например, только что я использовал в своей программе алгоритм
vtkDecimate из VTK (http://www.vtk.org/) — мне не интересно знать как он
внутри работает. А то что мне о нем нужно знать теории не требует.
> Да мало ли какая задача попадется.
Вы знаете свойтсва дробных производных? А если придется их использовать?
У нас в программе есть небольшой модуль для некой цифровой обработки
сигнала. Я попытался разобраться с алгоритмами и понял, что мне
потребуется пара месяцев на реализацию этого модуля. Мне было проще
убедить руководство нанять специалиста, который написал этот модуль за
две недели. Это я к тому, что существует такое понятие как "разделение
труда".
> Что вообще такое программист в конечном итоге?
Тот кто пишет программы.
> Да все мы занимались чем-то для чего потом выясняли, что существует > название. > Но по-моему заранее знать это название несколько удобнее.
Да, но далеко не критично.
> C>Бывают задачи (типа цифровой обработки сигналов, например), где без > C>теории — никуда. Но это уже исключения, подтверждающие правило. > Что-то мне не кажется, что DSP такое уж исключение в плане > требовательности к теоретической подготовке. > К тому же основы тех же сигналов ни одному программисту и просто так > не повредят. Для общей эрудиции.
Основы — не повредят (как я говорил — background knowledge). А вот
подробности конкретных алгоритмов — совсем другое дело.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>А от вас, я тоже хотел бы услышать ответ на вопрос: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
Если я правильно понял, то вот так:
inline bool shift_mask( data::byte_type & mask, data::byte_type const * & ep, data const * en )
{
if( 0 == (mask >>= 1) ) {
if( --ep < en->data_ ) return false;
mask = 1 << (data::bits-1);
}
return true;
}
//rn = (an ** en) mod mn
umodexp(data* rn, data const* an, data const* en, data const* mn)
{
data *n1 = rn; n1->copy(an);
data *n2 = data::alloc(rn->capacity);//пусть этот меморилик вас не смущает
//код немного упрощен для наглядности
data::byte_type const* ep = en->data + en->size - 1;
data::byte_type mask = 1 << (data::bits-1);
while( 0 == (*ep & mask) )
mask >>= 1;//skip to first '1' bit
reduction_algo reduce(mn);
// Все равно один раз reduce(n2, n1) выполнять нужно, поэтому делаем это сразу. Не заходя в цикл.
reduce(n2, n1);
if( shift_mask( mask, ep, en ) )
// Т.к. маска не закончилась, то выполняем основной цикл.do {
umul(n1, n2, n2);
reduce(n2, n1);
if( *ep & mask ) {
umul(n1, n2, an);
reduce(n2, n1);
}
} while( shift_mask( mask, ep, en ) );
rn->copy(n2);
}
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pzz, Вы писали:
Pzz>Идея меньше думать и больше делать на мой взгляд губительна для Pzz>компутерной индустрии. У нее есть только один плюс: можно включить в Pzz>проект произвольное количество индусов, и производительность будет расти Pzz>прямо пропорционально количеству исполнителей (а не как, например, Pzz>логарифм от нее).
Абсолютно верно. Но давай посмотрим на процесс разработки больших программ.
1. Постановка функциональных требований
2. Архитектура
3. Дизайн и программирование (часто они идут вместе, но если дизайн делает знающий человек, то тут ни один индус не поможет).
4. Тестирование и стабилизация.
Пункт 3 не самый затратный. Остальные пункты значительно важнее в смысле ответсвенности и качества. Да, я вынужден признать что в силу ограниченности функциональных языков(а поднятие императива на функциональном языке мне очень не сильно нравится) требуется повышенное внимание к дизайну. Тут хочешь или не хочешь будешь им заниматься. А для большой программы, будешь заниматься долго и нудно. И именно это компенсирует ту быстроту написания кода которую дают функциональные языки. Для небольшой программы все будет OK. Если тебе надо связать большое количество сущностей и взаимосвязей, то будет уже не все так весело.
reductor,
> ПК> Пожалуй, правильнее говорить об управлении временем жизни объектов, с чем C++, действительно, справляется лучше ряда других языков благодаря детерминированному разрушению объектов. GC этой задачи не решает. > > Я все же не понимаю кое-чего. Для каких задач нужно такое управление?
Для любых, включающих необходимость своевременного освобождения внешних по отношению к программе ресурсов: файлы, сокеты, соединения с базами данных, хэндлы операционной системы и т.п. Основная проблема не столько в том, чтобы не забывать освобождать внешние ресурсы, а в том, чтобы надежно делать это в реальных условиях, когда, фактически, любая функция может выбросить исключение.
> Но даже если так, почему С++ здесь справляется лучше тех языков, у которых нет проблем с алиасингом?
Не вижу связи с aliasing, но в C++ этому помогает возможность использования RAII.
В том же Окамле, насколько я понимаю, лучшее, что получится сделать для автоматизированного освобождения ресурсов в присутствии исключений -- некоторый аналог using из C# (взято отсюда):
let using resource thunk =
try
let
result = thunk resource
in
dispose resource;
result
with
any_exception ->
dispose resource;
raise any_exception
конечно, это лучше, чем ничего, но очень далеко до RAII, т.к. не позволяет управлять временем жизни ресурсов, хранящихся в членах классов.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Здравствуйте, vdimas, Вы писали:
V>>n+1 надо сделать у кеш-счетчика каждого элемента списка ГА>Нет, не надо. Точно так же, как не надо это в С++. ГА>А спорить дальше не вижу смысла, уже все сказал и не знаю, как по-другому:
Извини, но я как программист могу захотеть получить cdddr списка и далее работать с ним. Твоя кешированная схема не сработала. А если делать коррекцию n+1 каждого элемента списка, после вставки в конец, то это все теряет свой первоначальный смысл.
ГА>Вам нравится утверждать, что С++, Ява и C# — достаточно универсальные языки, и все остальные можно посылать подальше, даже не попробовав их на тех задачах, в которых они сильны (кстати, вы писали, что разрабатываете парсеры — так это же задача номер раз для ML-языков, примеров найдете немало).
Да, находил. И пробовал (правда давно). Быстродействие не выдерживало никакой критики и ресурсы тоже. Когда-то это было критично, поэтому я писал парсеры/лексеры на С/С++.
Понимаешь, если делать парсер по классике (лексический + синтаксический анализ, автоматные модели или с предпросмотром K), то глубоко пофиг на чем его писать. Другое дело, что на некоторых инструментах удобно моделировать (играть) с грамматикой. Это есть и именно для этого и использовалось.
Кстати, когда-то я подобную "игруху" делал и на С++, т.е. программа выглядела примерно так:
NTerm A, B, C;
A = 'a' | 'b';
A = C & B;
C = 'c' | C & 'c';
B = A & C | C & C & A | A;
B = 'b'
И нисходящий разбор к нему. Вполне позволяла "играть", менять приоритет правил и т.д. Куда уж минимальнее.
ГА>Я убежден в обратном.
Я вообще ни в чем не убежден и по-сути действую по обстоятельствам.
Виртуально есть обсуждение подходов, реально у меня стоит задача подбора людей в свою команду и я даже не могу найти нормальных спецов на С++/C#/Java. Про обсуждаемые языки вообще говорить не приходится. Не все, к сожалению живут в Москве, где срабатывают законы больших чисел, и находятся несколько человек даже на экзотику.
--------
Сам я слежу за ходом дисскуссий с удовольствием и уже планирую "как только так сразу" поближе познакомиться с Haskel.
Здравствуйте, R.K., Вы писали:
RK>Здравствуйте, reductor, Вы писали:
R>>Прагматичнее, да. R>>Мацумото во всеуслышание объявляет, что у него взорвался мозг, когда он пытался разобраться с хаскелем, после чего идет делать "прагматичный" язык.
RK>И с этим можно согласиться, после такого: append = foldr ((.).(:)) id -- вот как это понять, кроме как разложить (.) на лямбды? (дважды;)и, в особенности, такого: cfold' f z [] = z
Я даже на секунду не задумался, а в чем проблема?
В хаскеле вообще нет неоднозначностей и быть не может — у него строгая семантика. 100% лямбда.
а понять (.).(:), если первое время не понимаешь, очень просто — переписать.
append = foldr (compose . cons) id
where compose = (.)
cons = (:)
-- что то же самое, что и
append = foldr (compose . cons) id
where compose left right = left . right
cons left right = left : right
Если че, то взятие оператор в скобки — смена его ассоциативности и сдвиг.
(.) a b = a . b
В общем случае это выражается комбинатором:
comb a b = b a
-- так что
comb x y z
-- рирайтится в
y x z
[code]
Элементарно и без вариантов (в сомнительных случаях см. спецификацию хаскеля).
RK>cfold' f z (x:xs) = f x z (\y -> cfold' f y xs)
RK>cfold f z l = cfold' (\x t g -> f x (g t)) z l -- это ж надо столько рекурсивных лямбд наворотить!
_Вся_ программа на хаскеле после desugarer'a превращается в чистую лямбду. Нужно только выучить правила трансляции.
Ничего сложного здесь нет.
R>>Почему-то мне кажется, что хаскель он не смог освоить, потому что у него уже был разорванный мозг. Смоллтолком. RK>Може и так. А у меня, значит, Лиспом :)
Не знаю, я и лисп и хаскель люблю. Хаскель, правда, если честно, больше ;)
Я на нем могу программировать в уме — не ошибаясь :)
RK>PS Я не против Хаскеля, он мне очень понравился, это хорошее продолжение традиций Лиспа, но некоторые вещи, с виду совсем простые, иногда очень не просто понять.
Нет, хаскель — не продолжение лиспа. Это важно понять. Это продолжение ISWIM и Миранды.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Cyberax, Вы писали:
>>> Интересно, а что он на Вирта-то наехал? Вирт-то фигура далеко не самая >>> заметная в этом плане. Что не сразу на Дийкстру, Хоара, Кнута и >>> Милнера? Неужели не посмел? >>> Слабак! C>Кстати, Кнут считает, что структурное программирование должно содержать break. Ну а имея break (особенно именованый) уже и goto становится фактически ненужным (за исключением случаев с оптимизацией).
А имея вычислимый goto уже и break не нужен.
И вообще тоже нашли о чем спорить. Краеугольный камень. Где-то нужен, где-то нет. В Haskell вот вообще не нужен — не имеет там никакого смысла.
А вот более важные свойства языка (с лихвой покрывающие любые break) некоторые вводят только почему-то в версии 3.0
Или не вводят даже в версии 5.0. И тишина.
AVC>Как бы то ни было, из "великой троицы" (Дейкстра, Хоар и Вирт) неизменно атакуют именно Вирта.
Что бы там ни было, ставить Вирта в один ряд с Дийсктрой и Хоаром я бы не стал. "Немного" разных высовых категорий как люди так и их заслуги.
AVC>То Керниган напишет запоздавшую на несколько лет статью "Why Pascal is not my favourite programming language". AVC>То Пайк в статье о стиле программирования на Си два раза упомянет Паскаль, и оба раза в словосочетании "тирания Паскаля". AVC>То вот Торвальдс выскажется, что goto — это хорошо, а Вирт занимается "промывкой мозгов", и вообще ничего не понимает. В отличие от него, Торвальдса. (Я так понял приведенную Cyberax'ом цитату.)
Это все потому, что Вирт, прямо скажем, иногда слышав звон интерпретировал его по-своему, причем, слишком активно интерпретировал.
AVC>В связи с goto этот наезд хотя бы имеет некоторое основание: AVC>1) в названии дейкстровской статьи "Goto considered harmful" фраза "considered harmful" (породившая столько подражаний) принадлежит именно Вирту;
Фраза принадлежит тому, кому принадлежит. Сам Дийкстра ссылается как на дополнительный источник такого мнения на доклад Хоара и Вирта по алголу (Comm. ACM 9 (June 1966), 413-432.)
AVC>Могу предположить, что Вирта легче критиковать, потому что он "превращает теорию в практику", создает языки программирования и операционные системы. И про все это можно сказать с видом крайнего глубокомыслия: "а мне это не понравилось". А вот про теоретические работы так говорить не принято. Пришлось бы искать иные аргументы, помимо ругательств.
Можно попробовать покритиковать наиболее влиятельного language designer ever — Робина Милнера. Или Джона Маккарти.
Если найдется за что.
Вирт получает свои оплеухи совершенно по делу.
Здравствуйте, reductor, Вы писали:
AVC>>Как бы то ни было, из "великой троицы" (Дейкстра, Хоар и Вирт) неизменно атакуют именно Вирта.
R>Что бы там ни было, ставить Вирта в один ряд с Дийсктрой и Хоаром я бы не стал. "Немного" разных высовых категорий как люди так и их заслуги.
Насколько я понимаю, Дейкстра, Хоар и Вирт были во многом единомышленниками и друзьями в жизни.
Естественно, между ними существовало и определенное "разделение труда", и взаимное влияние.
Например, многие идеи Хоара легли в основу языка Паскаль.
Если хотите, присваивайте каждому из них тот или иной "вес" — это Ваше право.
AVC>>То Керниган напишет запоздавшую на несколько лет статью "Why Pascal is not my favourite programming language". AVC>>То Пайк в статье о стиле программирования на Си два раза упомянет Паскаль, и оба раза в словосочетании "тирания Паскаля". AVC>>То вот Торвальдс выскажется, что goto — это хорошо, а Вирт занимается "промывкой мозгов", и вообще ничего не понимает. В отличие от него, Торвальдса. (Я так понял приведенную Cyberax'ом цитату.)
R>Это все потому, что Вирт, прямо скажем, иногда слышав звон интерпретировал его по-своему, причем, слишком активно интерпретировал.
Вы что-то конкретное имеете в виду?
AVC>>Могу предположить, что Вирта легче критиковать, потому что он "превращает теорию в практику", создает языки программирования и операционные системы. И про все это можно сказать с видом крайнего глубокомыслия: "а мне это не понравилось". А вот про теоретические работы так говорить не принято. Пришлось бы искать иные аргументы, помимо ругательств.
R>Можно попробовать покритиковать наиболее влиятельного language designer ever — Робина Милнера. Или Джона Маккарти. R>Если найдется за что. R>Вирт получает свои оплеухи совершенно по делу.
Я понял, что Милнера (кто это?) и Маккарти Вы ставите выше, чем Вирта. Это Ваше неотъемлимое право.
Но вот насчет оплеух Вирту "по делу", может быть, скажете пару ласковых слов?
Так сказать, перед смертью.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, vdimas, Вы писали:
AVC>>Видно, Линусу проще добиться уважения критикой Вирта, чем выведением багов из ядра?
V>Слишком много людей пишут это ядро помимо Линуса. Этот пост, очевидно, адресовался им. И вполне правильно он поставил акцент, что читабельность и простота важднее, чем следование неким догмам.
С мыслью, что простота и читабельность важнее следования догмам, я полностью согласен.
Вот что мне непонятно, так это Cyberax'овские крики восторга и подбрасывание в воздух чепчика при чтении торвальдсовского вранья про Паскаль. Уверен, что Cyberax и про goto в Паскале знал, и про EXIT в Модуле-2.
Т.е. знает, что Торвальдс неправду пишет, и все больше его за это уважает.
М-да, загадка.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, eao197, Вы писали:
C>>Кроме того, критикам C>>Линуса стоит напомнить, что есть куча *BSD-систем, которые так и не C>>набрали популярность (в отличие от Линукса).
E>А вот это для меня до сих пор не понятно, как же стабильные BSD системы продули вчистую первым версиям Linux-а.
Ты под ядро FreeBSD программировал? посмотри на исходники, плиз. Это же застрелиться. (Мне одно время пришлось плотно поработать) Стиль 70-х годов. Сумашедшая разница по качеству организации кода в FreeBSD и Linux в пользу последней. Я понимаю, что в первую было вложено куча ср-в и времени, но это тупиковое направление. Не зря они новую BSD пишут с 0-ля.
E>Видно, Unix wars тех времен сыграли свою отрицательную роль.
Да нет, просто надо быть настящим мазохистом, чтобы участвовать в развитии BSD. Это можно делать только за деньги. Развивать Linux значительно приятнее, вполне можно участвовать для интереса и общего саморазвития.
reductor wrote:
> E>А мы только про CS говорим или про программирование вообще? > А что, можно отделить CS от программирования без ущерба для последнего? > программирование напрямую следует из CS и без него было бы невозможно.
Можно, очень даже. Причем без всякого ущерба — для того, чтобы писать
код вовсе не нужно знать что такое тезис Черча-Тьюринга, нормальные
алгоритмы Маркова и EBNF.
Хороший программист о них, конечно, должен знать, но это скорее просто
background knowledge (как мат.анализ или алгебра).
Здравствуйте, Игoрь, Вы писали:
И>Здравствуйте, minorlogic, Вы писали:
M>>Так вот в том то и дело что метку можно назвать хорошо а МОЖНО ПЛОХО , а return не допускает вольной интерпретации, логика его работы прозрачна. И>Ну и что из этого следует? Я же выше сказал, что и функцию МОЖНО ПЛОХО назвать, но главное что можно и хорошо. И>По-моему тема с goto высосона из пальца. Просто не стоит ими злоупотреблять вот и все. А прогу запутать легко и без явных меток, что многие успешно делают.
Я как мне кажется наглядно продемонстрировал , какой вред могут нести goto по сравнению с return. Ели ты не согласен, у меня нет задачи пеерубедитью.
Вот еще мвсль, хороший язык программирования отличается от плохого, тем что в хорошем труднее запутать прогармму.
Вот это и мне непонятно. С одной стороны, разбирая ту или иную задачу, Вирт прежде всего думает о правильной организации данных, т. е. такой, чтобы их было как можно проще обрабатывать. Т. е. данные первичны, программный код — вторичен. (См. например, "Алгоритмы + структуры данных"). И тут же требование писать служебные слова в Обероне большими буквами. По этому поводу я высказался как-то здесь
. Явное противоречие.
Д>Может быть, все-таки не станем устраивать идолопоклонничество?
Можно обобщить изречение, услышанное мною на еще на 1-м курсе: "Не сотвори себе кумира из начальника. Знай, что ты и сам не дурак". Однако, я против личных нападок.
Здравствуйте, reductor, Вы писали:
R>Человек, для которого С++ — первый или второй язык программирования в жизни действительно не будет знать его хорошо даже за год (особенно, если не будет стараться проникнуть в язык поглубже). R>Человек же, который знает необходимый набор классических (оказавших фундаментальное влияние на развитие других) языков + знаком с одним/двумя суперсовременными, выучит с++ очень быстро. Причем глубина его понимания запросто может оказаться побольше, чем у человека, который на с++ программировал 10 лет, но никаких языков больше не знает.
И если вы спросите у Сани умеет ли он играть на гитаре, то он вероятно скажет что он виртуоз, и что еще он гений бас-гитары и кудесник барабанов.
Никогда не поверю, что C++ можно выучить очень быстро и начать на нем грамотно программировать. Особенно с сегодняшним уклоном в шаблоны, метапрограммирование и expression templates...
Я и сам "13 Years of C++ and still learning"
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
E>>Я и сам "13 Years of C++ and still learning"
R>Я вас правильно понимаю, что вы не знаете ни одного из вышеназванных языков?
Правильно.
И знаешь что? Мне совершенно не стыдно. Всего знать не возможно.
Знать что-то про язык, знать стандарт языка, знать что-то про его библиотеки, но в теории -- это одно.
Применять язык на практике -- совершенно другое.
Мало знать про такие вещи, как RAII или сильную гарантию безопасности исключений. Мало знать про то, как это работает. Нужно уметь это применять. Постоянно, целенаправлено и последовательно. Могу тебя уверить -- далеко не у всех это получается. И я не исключение, удачный код у меня выходит не так часто как хотелось бы. Поэтому и говорю, что все еще изучаю C++.
Про знания языков (в смысле их успешного промышленного применения) я высказывался здесь: Re[3]: BlackBox всерьёз
.
А на практике это выливается в то, что нужно много времени потратить на изучение и практическое применение C++ чтобы уметь реально создавать код, в духе Compile-time template library
Поскольку рассказ про монады в функциональных языках -- это только одна грань такой обширной вещи, как программирование. А другая грань -- это, например, СУБД. И какая бы теория за какой-нибудь СУБД не стояла, без качественной реализации такая СУБД -- это так, поделка. А для качественной реализации нужно много разных качеств у разработчика. Среди которых эрудиция, имхо, далеко не на первом месте.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
Д>>там в частности было высказывание, что функции высшего порядка применяются крайне редко и в принципе не очень то нужны GZ>И что, это неправда? Для императивных это так.
как насчет С++/STL?
Д>>про такие вещи как лямбда, макросы и т.п. — вообще ни слова, хотя это как раз одни из самых сильных сторон ФЯ GZ>А он и не пояснял функциональные языки. Похоже у него стойкое неприятие к ним.
да, похоже на то
в любом слуаче, оценивать языки, отбросив их самые сильные стороны — довольно странная идея
E>>Видишь ли, к научному миру я отношения не имею. А когда пытался иметь это отношение, то у меня остались не самые хорошие воспоминания об этом деле. В частности о системе оценки работы по количеству публикаций.
R>По количеству ссылок на публикации. Впрочем, количество работ у вирта тоже не фонтан.
Прохоже сейчас в универе Science, Technology and Society. Так вот, количество ссылок на публикации является удобным, но очень неточным критерием оценки вклада того или иного ученого в науку.
Точное описание, почему, сейчас не приведу — книга дома. Но так и есть.
Здравствуйте, Дарней, Вы писали:
Д>я очень сильно сомневаюсь, что оберон задумывался как нишевой язык изначально
Так ведь давай оценивать Modula-2 и Oberon на момент их создания (1978 и, если не ошибаюсь, 1988). Не знаю, как Лисп-ы и Smalltalk-и, а C++ в 1978 вообще не было, а в 1988 он был далек от того, что мы имеем сейчас. Java, точнее Oak, возможно, зачиналась в самых смелых мечтах Грослинга. На звания промышленных языков того времени они, имхо, вполне могли претендовать. А вот почему не получилось? Вероятно, у Вирта просто-напросто технических талант, а не маркетинговый.
Я лично помню, что где-то в 1993 году на меня сильное впечатление произвела статья про Оберон. Особенно про его модульную природу. Мне тогда, после перехода на C/C++ с Turbo Pascal сильно турбо-паскалевских unit-ов не хватало. А в Обероне это было, как мне показалось, доведено до логического завершения.
Жалел тогда, что в нашем университете ничего, кроме MS-DOS, Turbo Pascal и Turbo C (затем Borland C++) ничего не было Не довелось в то время ни с Обероном познакомиться, ни со Smalltalk-ом, ни с Lisp-ом. Вот так я и стал C++ником
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>Назвал Пролог функциональным языком — явный промах.
Кто назвал? Вирт? Когда?
Д>там в частности было высказывание, что функции высшего порядка применяются крайне редко и в принципе не очень то нужны Д>про такие вещи как лямбда, макросы и т.п. — вообще ни слова, хотя это как раз одни из самых сильных сторон ФЯ
Здравствуйте, eao197, Вы писали:
E>Боюсь, что сказать это с полной определенностью ты мог бы, если бы был создателем Паскаля. E>А так это только слова.
что поделаешь — автор Паскаля в природе имеется только один
так что ты не оставляешь ему ни единого шанса
GlebZ wrote: > Честно говоря, я бы дал премию Страуступу. Можно долго мучится вопросом > насчет недостатков и достоинств языка и научной ценности, но то что его > детище кардинально повлиял на все сообщество на десятилетия — отрицать > нельзя. Это влияние нельзя переоценить.
Тогда уж еще и Биллу Гейтсу — влияние его империи еще сильнее.
Здравствуйте, Cyberax, Вы писали:
C>У goto есть минус — очень сложно отслеживать переходы "назад". И C>вложенные goto тоже страшновато выглядят.
Дело не в страшноватости вида. А в том, что очень трудно определить зависимости. Совершенно неважно, прыгает goto вперед или назад. Проблема в том, что в любую метку ты можешь попасть из неопределенного количества мест, и совершенно непонятно, какие ветки кода к этому моменту были выполнены, и сколько раз. Конечно, goto — не единственный способ запутать программу. Но если ограничиться "безопасным" использованием goto, то оно как раз и сведется к while, if, return.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, z00n, Вы писали:
E>>Никогда не поверю, что C++ можно выучить очень быстро и начать на нем грамотно программировать. Особенно с сегодняшним уклоном в шаблоны, метапрограммирование и expression templates...
Z>На самом деле меня очень удивило замечание про "особенно шаблоны, метапрограммирование и expression templates" . С точки зрения человека, который учился функциональному программированию, шаблоны, метапрограммирование и expression templates — это как раз то, в чем он давно разобрался.
Внимательно прочитай то, что я написал. Попытка использовать метапрограммирование на C++ в духе Scheme или Lisp-а будет приводить, как ты правильно заметил, к
все закричат, что это извращение и среднему труженнику С++ этого ни в жисть не понять
Вот чтобы такого не было, желательно метапрограммировать на C++ так, чтобы это оставался нормальный C++, а не испорченный C++ным синтаксисом Scheme.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну вообще, по-моему, это правильно. Диссертация все же должна быть про Pzz>науку, а не про то, какую замечательную программу можем мы написать. И Pzz>оцениваться диссертация, по-моему, должна в первую очередь с точки Pzz>зрения научного вклада.
А вот мне интересно, за какие открытия присуждают звания "кандидата технических наук"?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > > Pzz>Ну вообще, по-моему, это правильно. Диссертация все же должна быть про > Pzz>науку, а не про то, какую замечательную программу можем мы написать. И > Pzz>оцениваться диссертация, по-моему, должна в первую очередь с точки > Pzz>зрения научного вклада. > > А вот мне интересно, за какие открытия присуждают звания "кандидата > технических наук"?
E>Функциональное программирование прекрасно, оно — радость созерцания. Как только кто-то поймет функциональное программирование, он немедленно перейдет к нему. Массы, которые застряли в устаревшем императивном и объектно-ориентированном программировании, делают это из слепого предубеждения. Они просто не понимают.
E>Каким-то религиозным духом попахивает
Вообще то, это цитата из раздела "не причины". Я воспринял это как сарказм.
>> Последний раз — GC не запрещает вручную выделять память. И попробуйте >> сказать обратное. C>Не запрещает. Но делает это очень неудобным для использования, да еще и
Это чем оно делает неудобным?
C>добавляет проблем — GC во время циклов сборки должен сканировать C>выделенные пользователем блоки памяти.
Да ну?
C>Это создает проблемы с расшареной памятью — может возникнуть race C>condition с другим процессом.
Сразу видно человека, который не любит теорию. Это кстати и к сканированию памяти относится.
C> Массивы объектов тоже должны особым C>образом инициализироваться. В общем, RTFM стандарт C++/CLI — там C>подробно эти сложности расписаны.
Меня не интересует С++/CLI
В общем-то меня не интересует как С++, так и CLI по отдельности.
Я люблю высокие технологии, а не непонятно с какого века оставшиеся.
Так что их проблемы — не мои проблемы. И проблемы С++ — не мои.
А вы мне зачем-то пытаетесь продать эти проблемы под видом конфет.
>> При это по ссылке приведены функции, аналог которых попробуйте найдите >> в С++.
C>С++/CLI или Boehm GC — для тех кому это нужно. В большинстве случаев GC C>_не_ нужен.
Знаете, я вам вот что скажу. GC — это вещь фундаментальная для языков программирования. Она или есть или ее не может быть. В с++ — не может. Boehm проблем не решает как организационно, так и с производительностью.
Говорить мне, что мне GC не нужен — не стоит. Он мне нужен и прямо сейчас.
И что его не только отсутствие, а невозможность сделать в принципе — это достоинство, это полная дичь.
>> C>В С++ для этого есть другие средства. Зачастую более адекватные. >> Покажите как в С++ дефрагментировать кучу
C>1. Не фрагментировать ее. Тем более, что в С++ достаточно для этого средств.
гениально. получите апплодисменты.
C>2. Использовать memcpy-moveable-объекты.
где использовать-то? внутри third party библиотек?
C>3. Сделать move constructor объектам и дефрагментировать на здоровье.
о да, это тоже гениально
C>4. Использовать уплотняющий GC.
ну дайте же мне уплотняющий GC для C++
дайте tracing copying incremental mark-n-sweep GC, пусть он будет двадцатилетней давности
я ведь такую мелочь прошу, я ведь не прошу вас обеспечить С++ region inference
C>5. Еще что-то можно придумать.
Конечно, что мы, не гении чтоли, впрямь
>> Скажите зачем вам нужно выделять руками память и освобождать ее.
C>Это не требует GC. Консервативный GC ведь вам не нравится, а точный GC C>тянет за собой слона.
Не тянет. Если это не С++
>> C>Руками освобождать ресурсы. Дикость в современном С++. >> Это дикость везде.
C>Только не в языках с GC. Там это норма.
в языках с GC норма — руками освобождать ресурсы?
по-моему вы уже заговариваетесь.
>> Но в данном случае вы говорили про ручное управление. Вас шатает из >> стороны в сторону. Держитесь.
C>Простите, но связь между этими двумя понятиями — одно из самых больших C>преимуществ. И вы после этого говорите, что знаете С++????
Я там вам выше уже все написал про продажу прошлогоднего снега.
Еще раз — С++ не является самым оптимальным как в плане мемори менеджмента, так и в плане расширяемости языком.
Если С++ смогли как-то расширить, чтобы засунуть в библиотеки какие-то вещи (потому что без них он совсем отстой), это еще не значит, что нигде это больше невозможно. А вот нормальный GC в С++ невозможен. А у других он просто есть.
>> Или хотите сказать, в Cyclone нельзя делать этого автоматически?
C>Нет. В Cyclone нет деструкторов с С++ной семантикой вызова.
да вы что. серьезно? чего еще там нет?
>> C>Нет, благодаря *средству языка* (а именно placement new) можно >> C>реализовать свое управление памятью для объектов. И в частности данную >> C>систему. >> Вот этого я не понял. Хотите сказать, синтаксическая возможность >> написать new (buffer) — это достижение и уникальная особенность?
C>Да (достижение, хотя и не уникальное). Как мне такое сделать в OCaml? Вы C>подумайте как это сделать, и что это за собой влечет для GC.
Что, как отщипнуть от готового буфера кусок? написать функцию new?
Или hello world написать?
А че для камловского GC это влечет? по-моему, вообще ничего. А по-вашему?
>> C>И что? Можно и точный GC для С++ сделать, но это потребует >> кооперации со >> C>стороны программиста. В библиотеке Boost.Regex, например, есть такой >> C>один (хотя и примитивный). >> Нельзя.
C>Можно. Смотрите tracking_ptr.hpp из xpressive в Boost'е, например. В C>xpressive используется простой _точный_ GC.
Вы видимо принципиально не понимаете о чем вообще речь.
Что со своими аллокациями я могу разобраться, я в курсе. Но речь не обо мне, а о С++
и о чужих объектах с адресной арифметикой и прочим говном.
И не нужно говорить, что проблема решаема. Поскольку вы предпочитаете обычно теорию не знать, я вам скажу, что эта проблема в общем случае не решается. Можете конечно потратить пару лет своей жизни, чтобы доказать всем какой С++ крутой и убедиться в конце в этом на практике.
>> Или покажите мне как взять например wxwidgets и запустить его под >> инкрементальным GC который еще автоматом отучит каждый объект при >> создании требовать указания родителя.
C>А нафига это в wxWidgets нужно? Там вполне хватает ручного управления C>памятью.
НЕТ. МНЕ не хватает. Я не хочу ничем управлять и создавать объекты в строгой последовательности.
хочу красивой жизни как в нормальных средах.
>> C>Да? Читаем: автоматические объекты — одна из центральных фич языка. >> Это не фича, это баг.
C>Ну да. Их же нет в OCaml'е....
Ха.
>> C>Умные указатели — требуют перегрузки оператора разыменования, так что >> C>это тоже языковая особенность. Placement new — одна из форм ключевого >> C>слова new. >> И таким образом все эти уникальные особенности сводятся к возможности >> перегружать операторы?
C>Как мне в OCaml перегрузить оператор обращения к члену структуры?
Что вы там говорили про свое программирование на окамле? не повторите?
Вы на нем программировали и на хаскеле еще и решили, что они — так себе?
Видимо нужно заканчивать эту глупую беседу.
>> C>Вы не понимаете значение слова "гибкость"? Или наивно полагаете, что >> C>можно предусмотреть все случаи использования заранее? >> Это не гибкость, это затычки для тех дыр, которые можно кое как >> заткнуть в С++. >> Сделать такое хоть в хаскеле не представляется проблемой. >> но там это просто _не нужно_.
C>Почему-то вы считаете GC — панацеей. И в упор не видите проблем, которые C>он создает.
Это у вас странное представление как о GC так и об окамле с хаскелем.
И вы в упор не видите проблем, которые не только вам, но и всем вокруг создает С++ и весь этот закат солнца вручную.
>> C>Имеем: библиотека VTK, все объекты в ней создаются с помощью >> C>статического метода New, а уничтожаются методом Delete. Требуется >> C>написать функцию, которая будет создавать объект, чего-то с ним >> делать и >> C>возвращать его. При этом я не должен заботиться о необходимости ручного >> C>вызова Delete. >> Хотите сказать, где-то так нельзя? C>Да.
Вообще здорово. А че мешает? Никогда вот delete не вызываю.
C>Например в OCaml. Внимание на строчку про "не должен заботиться о C>необходимости ручного C>вызова Delete". В финализаторе, естественно, это делать тоже нельзя.
дада, операторы не перегрузишь, потому что их нет, следовательно рефкаунтер не сделаешь
бросьте эти дурацкие языки, действительно.
>> Я вам там кидал ссылку на то, что в стандартной библиотеке хаскеля это >> делает.
C>Ткните пальцем.
тык: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign.html
>> C>Когда я в последний раз смотрел — еще не было. Теперь добавили, но все >> C>равно с ограничениями. >> Знаете, это не разговор. Ручное управление памятью — это очень низкого >> уровня класс задач. >> И Cyclone при этом дает ее выполнять с помощью гораздо более >> высокуровневых инструментов, чем С++ >> и гораздо мощнее.
C>Не вижу тучи проектов на этом супермощном языке. А лет ему немало уже — C>я его в 2001 еще смотрел (если не раньше).
а я вот не вижу моря из окна
>> C>Это _использование_ C через проксики, а не полноценная >> C>интероперабельность с ним. А то так можно взять SOAP и сказать, что с >> C>помощью него можно с С интероперировать. >> Можно, а что вас не устраивает, кстати?
C>1. Скорость. C>2. Уровень интеграции. C>3. Трудоемкость сложной интеграции.
Скорость чего? врапперов?
Прикольно.
>> C>Битовые поля? union'ы? #pragma pack? Поддержка __stdcall, __fastcall и >> C>других calling conventions. Поддержка сторонних аллокаторов. >> ЭЭ... foreign import stdcall в хаскеле? Ну и я там ссылку кидал на >> модуль Foreign.*
C>А __thiscall с __fastcall'ом? В доке по FFI написано про всего две C>конвенции — "по умолчанию" и stdcall. Я кстати еще про распространенную C>pascal-конвенцию забыл.||*||*
>> Что мешает _кому угодно_ завести такую поддержку?
C>Так ведь не сделали? Значит, что-то мешает.
А еще не сделали оператор delete, наверное что-то мешает
и auto_ptr
>> Да, C# движется, пока не дойдет до F# >> а F# движется пока не дойдет до окамла.
C>Мечтатель...
>> О чем вы там вообще? Что еще за JIT и каким образом это относится к >> окамлу? >> Ну и мельчайшие подробности. Вы откуда это взяли?
C>Кхм. Вообще-то JIT — это Just-In-Time компляция, не знать этого стыдно C>(кстати, в OCaml'е оно есть для байт-кодов). И читайте всю тему, а не C>одно сообщение.
@#$%@#$% я знаю что такое JIT, я не понял какого хрена он делает в разговоре об окамле и его GC
и тему не хочу читать. я и так слишком много всего прочитал уже лишнего и глупого.
C>Ну да, если я уверен, что в моем коде нет алиасинга, то я могу дать хинт C>оптимизатору с помощью атрибута restrict.
Я в общем-то желаю вам программировать на С++ как можно дольше. Мне кажется это правильно вообще, да.
Я вообще сторонник здоровой экологии.
ГА>This book is dedicated, in respect and admiration, to the spirit that lives in the computer.
ГА>``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''
Здравствуйте, Pzz, Вы писали:
Pzz>Забавно, что C# это первый язык, который добился широкой известности, не будучи перед этим рожденным в юниксовской среде. Pzz>Интересно, можно ли на этом основании делать вывод, что C# умрет, так и не осуществив возлагаемых на него надежд? Я склонен думать, что да. Что-то мне подсказывает что ты сильно недооцениваешь мощь мелкософта. Pzz>Микрософт при этом совершает совершенно героический поступок, поставив все фишки на технологию, которая не была 20 лет обкатана на юниксе...
Мелкософт в .NET вкладывает столько науки и денег что юниксовым языкам и не снилось. Плюс всей своей мощью проталкивает .NET в качестве основной платформы для Windows разработки, а мелкософт да еще и на своем поле...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pzz, Вы писали:
Pzz>Ну, Страуструп тоже не ученый.
Кто тебе такое сказал? Создание C++ это есть исследовательская работа. И оно сильно повлияло на CS. Pzz>Мы же говорили о _влиянии_. Влияние Билла Pzz>Гейтса, без сомнения, сильнее.
Билли — глава корпорации, но не непосредственный создатель продуктов. А среди тех корпораций, которые наиболее повлияли на CS, правильнее назвать IBM. И я думаю, по этому показателю вряд ли кто их переплюнет.
Здравствуйте, vdimas, Вы писали:
V>Соответственно, в тех языках, где нет break, continue и return вполне можно можно использовать goto, если использовать ег ос той же "аккуратностью", какую мы получаем в случае break, continue, return.
Да, да. Полностью согласенж. Если писать с должной акуратностью, то х86-ассемблер лучший язык программирования.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, reductor, Вы писали:
R>>Каков, а! R>>Ловко перевел тему опять на Вирта. R>>Дийкстру не трогает. Боится. И правильно делает. Могут урыть.
VD>Кстати, а может кто-нибудь объяснить феномен того, что рынок альтернативной ОС захватил Линукс, а не какая-нибудь ФриБСД или еще что-нибудь? Может быть это такой подпольный проект МС?
А вот благодаря скандальности создателя и захватил.
Это у него не в первый раз такое.
Здравствуйте, Pzz, Вы писали:
Pzz>Я как-то был поражен, зайдя в знакомую контору, и обнаружив, что там Pzz>собралась толпа программистов, и обсуждеает, как им выкрутиться из Pzz>очередной нетривиальной проблемы, которую поставил перед ними C++. Как Pzz>эта проблема содержательно соотносилась с решаемой задачей, я так и не Pzz>понял...
Не факт, что это язык поставил проблему. Может быть, проблема была в архитектуре, а специфика мировосприятия программистов перевела её на рельсы кодирования.
AVC wrote: > > Не понял связи истории с "левым индусом" с данным случаем. (Хотя сама > история весьма поучительна.) > Разве нельзя объявить функцию, которая используется только в данном > файле, как static?
А что, индусам что-то может помешать удалить слово static, и даже
добавить прототип функции в какой-нибудь хидер (а еще лучше — в свой
собственный сишник, и никому об этом не сказать).
Индусы, они очень хитрый и изворотливый народец. Особенно в плане того,
чтобы двумя-тремя простыми правками изуродовать программу до
неузнаваемости...
Здравствуйте, Pzz, Вы писали:
Pzz>C++, по-моему, не прощает ошибок в проектировании интерфейсов. Причем о Pzz>самой ошибке приходится узнавать, когда уже много чего понаписано...
Нет, не прощает ошибок хреновая голова. Да — стиль проектирования в C# и C++ разный. Но поубивать программу легко и там и там. Средств достаточно как для построения хорошего интерфейса, так и плохого.
reductor wrote:
> V>Но если в языке нет break, continue, return, то без goto порой > получается тот самый синтаксический оверхед и лишняя "искусственная" > запутанность кода. > Вот в ML и Haskell нет ни break ни return ни continue ни goto — ну по > крайней мере в прямом смысле
Здравствуйте, GlebZ, Вы писали:
GZ>А в чем тут баг менеджмента?
В том, что довели до беты, а потом взялись тестировать по-настоящему. Ну и поправки к спецификациям в последний момент — как образ жизни.
Я бы сейчас на пушечный выстрел не подошёл к той идее, которую закладывали ещё аж в 1997 году. Слишком много тонких мест в ней. Впрочем, если бы тогда её не воплотили — не факт, что узнал бы об этих тонких местах вообще.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, reductor, Вы писали:
V>>>Но если в языке нет break, continue, return, то без goto порой получается тот самый синтаксический оверхед и лишняя "искусственная" запутанность кода.
R>>А по-моему все наоборот становится понятнее R>>Вот в ML и Haskell нет ни break ни return ни continue ни goto — ну по крайней мере в прямом смысле
V>Опять ты про функциональный стиль? Нафига вообще козе баян? А замечание про отсекающие условия я уже делал.
Я когда-нибудь того человека, который придумал термин "функциональное программирование" отловлю и скормлю крокодилам.
Ненавижу, когда начинают разделять тут — одно дело, когда модель языка — чистая лямбда, как в случае с хаскелем, а другое, когда некоторые конструкции просто удобны везде.
просто удобно, когда if и switch возвращают значения, дико удобен pattern matching, очень полезно, когда раскручивается хвостовая рекурсия и тп.
и самое главное — все эти goto теряют смысл, когда есть замыкания и ты можешь просто передать куда-то функцию для дальнейшей обработки.
Можно подумать, Nemerle или C# 3.0 — это "функциональные" языки. Или там ruby...
"Функциональных" языка толком два — это Haskell и Clean, в остальных случаях — это просто языки без комплексов
V>Ясен пень. Вся императивщина скрыта в недрах компилятора/интерпретатора.
Ну скрыта или не скрыта — это как считать. Си вот тоже некоторым образом "функциональный" язык. все функция, всегда есть возвращаемый тип, функции передавать можно. ну и тп. большая абстракция.
v>Но согласись, пока что еще слишком много императивных задач, хотя бы из соображений эффективности. Вон даже длину списка подсчитать в Лисп или Пролог нетривиально (с т.з. ресурсов), подозреваю, что такая же хрень в Haskell.
Длину связного списка посчитать везде стоит одинаково.
а описывается задача очень просто:
length [] = 0
length (x:xs) = 1 + length xs
Попроще, чем в си.
другое дело, что длину знать их — это очень редко, когда нужно. по индексу их никто не итерирует и т.п
мощная штука, жаль, пока что без аппаратной поддержки медленнее, чем массивы (те в кеш разом зафигачить проще)
резюме:
Императивных задач же конечно много, но это не повод лишать себя удобства в виде матчинга, замыканий и хвостовой рекурсии.
Причина существования окамла, между прочим (который не менее императивный, чем функциональный)
E>Нужно только понимать, что для каждой задачи нужен свой язык. Где-то функциональные языки рулят неимоверно. Когда таких задач станет большинство, тогда и эти языки будут мейнстримом. Хотя, скорее, в существующие императивные языки будут добавлены лучшие качества функциональных.
Именно так и будет скорее всего. Идиоматически "чистые" языки весьма узконаправленные by design, отсюда их низкая популярность. Не знаю как это будет выражаться синтаксически и какова будет сложность компиляторов, но 100%-но будут совмещать разные идиомы в программном коде.
V>Тогда остановимся на термине "функциональный стиль". Мы же должны оперировать какими-нибудь краткими терминами.
зачем? :)
R>>и самое главное — все эти goto теряют смысл, когда есть замыкания и ты можешь просто передать куда-то функцию для дальнейшей обработки.
V>Синтаксически это присутствует уже в C# 2.0, никто не спорит. В С++ та же идиома обыгрывается функторами и там тоже goto не нужен. Это не те случаи и мы отклонились.
Почему не те, по-моему, очень даже.
R>>Можно подумать, Nemerle или C# 3.0 — это "функциональные" языки. Или там ruby... R>>"Функциональных" языка толком два — это Haskell и Clean, в остальных случаях — это просто языки без комплексов ;)
V>>>Ясен пень. Вся императивщина скрыта в недрах компилятора/интерпретатора.
R>>Ну скрыта или не скрыта — это как считать. Си вот тоже некоторым образом "функциональный" язык. все функция, всегда есть возвращаемый тип, функции передавать можно. ну и тп. большая абстракция.
V>В С++, повторю, есть еще и функторы. Весь STL писан в расчете на них (ф-ии и функторы).
Я видел :)
Я опять к тому, что делить функциональное и императивное программирование почти невозможно в том смысле, что пусть тот, кто сможет провести грань, первым бросит в меня камень.
v>>>Но согласись, пока что еще слишком много императивных задач, хотя бы из соображений эффективности. Вон даже длину списка подсчитать в Лисп или Пролог нетривиально (с т.з. ресурсов), подозреваю, что такая же хрень в Haskell. R>>Длину связного списка посчитать везде стоит одинаково.
V>Самое время задуматься, почему связанные списки редко где используются в императвных участках кода.К тому же — побочный эффект насчет попаданий в кеш тоже играет свою роль. Далее, "сплошные" массивы более компактны, value-типы в .Net будет гораздо эффективней хранить в массивах и т.д.
Потому что их не так удобно там использовать.
Если не обращать вниания на эффективность, то списки вообще вещь гораздо удобнее, чем массивы для 90% задач.
Не просто же так все эти итераторы и прочее появились в "императивных" языках — своего рода эмуляция списков.
V>В STL есть итераторы, причем работа с ними в основных алгоритмах не зависит от способа организации списка. Разница м/у итераторами — суть длина списка. Неплохая абстракция.
Да не проблема. Только list interface в функциональных языках — это не от их бедности и скупости, он сам по себе очень экспрессивное средство.
Это самый низкий уровень работы со списками. Никто своей функции length конечно не пишет, она уже есть :)
А определить класс со стандартным интерфейсом ничего не стоит, но оно не особо нужно — в большинстве случаев все равно списки. А когда массивы, это уже слишком другая семантика, чтобы вводить такую абстракцию.
R>>Попроще, чем в си.
V>
V>it2-it1
V>
V>С++ V>:)
ну тогда
length xs
ну или
bounds ar
для массивов
R>>другое дело, что длину знать их — это очень редко, когда нужно. по индексу их никто не итерирует и т.п
V>Если у меня свой собственный распределитель памяти, или я вызываю ф-ии АПИ ОС, или я пишу свой загрузчик и т.д.?
Это к чему?
R>>мощная штука, жаль, пока что без аппаратной поддержки медленнее, чем массивы
V>Есть инциденты аппаратной поддержки кеширования списочных структур?
Ну, смотря что считать... http://citeseer.ist.psu.edu/187280.html
Вообще это большая тема с затрагиванием фон ноймана против гарварда и тп
ну ее...
подальше :)
R>>резюме: R>>Императивных задач же конечно много, но это не повод лишать себя удобства в виде матчинга, замыканий и хвостовой рекурсии.
R>>Причина существования окамла, между прочим (который не менее императивный, чем функциональный) :)
V>а что серьезного уже написано на окамле? (не стеб, если есть навскидку инфа — поделись)
А так, кое в каких очень немаленьких компаниях используется в очень немаленьких внутренних системах.
Но те же молчат и другим велят :)
V>Пролог — тоже весьма мощная штука, но блин чего-то не пошел в массы, даже удивительно... Даже с ОО- и императивными расширениями.
У пролога трагическая судьба :)
Его загубили PC и слишком большие ожидания. Как и лисп
Пролог-машины, лисп-машины, Красота. а тут персоналки, мать их.
И все, всем считать байты :)
reductor,
> ПК>Для любых, включающих необходимость своевременного освобождения внешних по отношению к программе ресурсов: файлы, сокеты, соединения с базами данных, хэндлы операционной системы и т.п. Основная проблема не столько в том, чтобы не забывать освобождать внешние ресурсы, а в том, чтобы надежно делать это в реальных условиях, когда, фактически, любая функция может выбросить исключение. > > http://www.rsdn.ru/Forum/Message.aspx?mid=1522461&only=1
Вы, вероятно, недочитали, или же я Вас недопонял. На мой взгляд, в конце сообщения и было нечто в таком же духе, но как сказано далее, такой подход не позволяет управлять временем жизни ресурсов, хранящихся в членах классов. Не могли бы Вы привести пример, аналогичный следующему (C++):
В случае исключения в любой точке, как в этой функции, так и далее, где будет приниматься и использоваться MyObj, все занятые ресурсы будут автоматически освобождены вовремя. В общем случае время жизни MyObj вовсе необязательно ограничено лексической областью видимости или временем исполнения некоторой функции.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Нет, я, к сожалению, учился не там, где это могли преподавать (эх, если бы я заканчивал MIT, я бы прошел SICP на первом курсе, а сейчас по ночам приходится ). На 90% все свои обрывочные знания о программировании добыл самостоятельно. Разве что мой будущий научный руководитель посоветовал обратить внимание на Пролог и подкинул пару тестовых задачек.
Понятно. А нам читали Пролог. Может быть поэтому у меня примеры программ в функциональном стиле вызывают неприятие
Как в школе: чтобы отвратить человека от русской литературы, нужно ему эту литературу насильно преподавать.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, z00n, Вы писали:
Z>>Здравствуйте, vdimas, Вы писали:
V>>>Нет, не можно. Голова списка (cons) — это может быть середина другого списка.
Z>>Про фичи тоже сильно написано, но тут не смог удержаться: cons — это конструктор, и не списка, а пары
V>cons — это термин ячейки, которые образуют связанный список, состав этой ячеки — элементы car и cdr. Имхо, ты перепутал термины с названиями одноименных ф-ий.
V>Одна ячейка cons — это и есть список. Ничто другое списком не является, кроме nil.
Мне не жалко, я повторю: cons — это функция, название которой есть сокращение от constructor, которая является конструктором пары.
car и cdr — функции, а не "состав ячейки".
То, что вы называете "термин ячейки", называется "pair" или "dotted pair"
Или давайте зайдем с другого конца, (cons 42 43) — по вашему это связанный список? А так: (cons nil (cons 42 43))?
Не верите мне, наберите в гугле "cons definition", например.
Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>Кроме читабельности кода, если ещё один аспект — использование goto даёт возможность написания кода, который не приводится к вложеной структуре циклов (циклы с несколькими входами). А это делает анализ такого кода на порядок более сложной задачей, а следовательно заметно усложняется задача оптимищации кода компилятором.
Старым оптимизаторам это возможно мешало. А современным оптимизаторам это по барабану.
Посмотри хотябы на MSIL который потом обрабатывает JIT... там только условные и безусловные переходы... никаких циклов там нет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
C>Сегодня исправлял одну багу в ядре Линукса и в процессе наткнулся на C>такой пост:
Общество интересуют детали бага.
Проблемы портирования модуля?
Последний раз я сталкивался с багой самбы. В последних версиях её пофиксили. Но самба это не ядро.
А по-моему хорошо, когда есть возможность самому исправить багу в ядре
Гораздо хуже, когда известо, что бага есть и ничего поделать не можешь, можно только ожидать, когда за тебя её пофиксят.
MShura wrote:
> C>Сегодня исправлял одну багу в ядре Линукса и в процессе наткнулся на > C>такой пост: > Общество интересуют детали бага. > Проблемы портирования модуля? > Последний раз я сталкивался с багой самбы. В последних версиях её > пофиксили. Но самба это не ядро.
Нет, у меня похоже race condition в драйвере для спутниковой карты. У
нас просто две карты воткнуто (SkyStar2) — по одной идет Интернет, по
другой — телевизор Все изредка падает в Kernel Panic, причем в
основном при изменения настроек (смене каналов).
По отдельности работает все вообще идеально. При попытке включить
отладку проблемы тоже пропадают.
> А по-моему хорошо, когда есть возможность самому исправить багу в ядре > Гораздо хуже, когда известо, что бага есть и ничего поделать не > можешь, можно только ожидать, когда за тебя её пофиксят.
Кто же спорит Вот было бы еще окружение в Линуксе нормальное...
reductor wrote:
> C>>Сегодня *исправлял одну багу в ядре Линукса* и в процессе наткнулся на > C>>такой пост: > C>>У меня *все больше уважения к этому товарищу*! > AVC>Видно, Линусу проще добиться уважения критикой Вирта, чем > выведением багов из ядра? > Так это ж известно, главное — не мотивировать свои слова, а побольше > харизмы. > Признавать, а тем более исправлять свои ошибки — это для лузеров и лохов.
Не ошибается тот, кто ничего не делает. Как Вирт, например...
> Интересно, а что он на Вирта-то наехал? Вирт-то фигура далеко не самая > заметная в этом плане. Что не сразу на Дийкстру, Хоара, Кнута и > Милнера? Неужели не посмел? > Слабак!
> I thought Edsger Dijkstra coined the "gotos are evil" bit in his
> structured programming push?
Yeah, he did, but he's dead, and we shouldn't talk ill of the dead. So
these days I can only rant about Niklaus Wirth, who took the "structured
programming" thing and enforced it in his languages (Pascal and Modula-2),
and thus forced his evil on untold generations of poor CS students who had
to learn langauges that weren't actually useful for real work.
(Yeah, yeah, most _practical_ versions of Pascal ended up having all the
stuff necessary to break structure, but as you may be able to tell, I was
one of the unwashed masses who had to write in "standard Pascal" in my
youth. I'm scarred for life).
Здравствуйте, Cyberax, Вы писали:
>> Интересно, а что он на Вирта-то наехал? Вирт-то фигура далеко не самая >> заметная в этом плане. Что не сразу на Дийкстру, Хоара, Кнута и >> Милнера? Неужели не посмел? >> Слабак!
Кстати, Кнут считает, что структурное программирование должно содержать break. Ну а имея break (особенно именованый) уже и goto становится фактически ненужным (за исключением случаев с оптимизацией).
Здравствуйте, Cyberax, Вы писали:
C>Не ошибается тот, кто ничего не делает. Как Вирт, например...
Правильно, за Вирта все "щучье веление" делает.
>> Интересно, а что он на Вирта-то наехал? Вирт-то фигура далеко не самая >> заметная в этом плане. Что не сразу на Дийкстру, Хоара, Кнута и >> Милнера? Неужели не посмел? >> Слабак!
C>
>> I thought Edsger Dijkstra coined the "gotos are evil" bit in his
>> structured programming push?
C>Yeah, he did, but he's dead, and we shouldn't talk ill of the dead. So
C>these days I can only rant about Niklaus Wirth, who took the "structured
C>programming" thing and enforced it in his languages (Pascal and Modula-2),
C>and thus forced his evil on untold generations of poor CS students who had
C>to learn langauges that weren't actually useful for real work.
C>(Yeah, yeah, most _practical_ versions of Pascal ended up having all the
C>stuff necessary to break structure, but as you may be able to tell, I was
C>one of the unwashed masses who had to write in "standard Pascal" in my
C>youth. I'm scarred for life).
C>Linus
Я вообще не могу понять, о чем тут талдычит Торвальдс, кроме той светлой мысли, что вот Дейкстра уже умер, давайте покончим с Виртом.
(Как и в другой его цитате, приведенной еще в первом посте топика.)
В стандартнон Паскале есть goto, в Модуле-2 и Обероне EXIT (=break).
Что вызвало такие "страдания молодого Линуса", что даже отшибло память о конструкциях языка?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
C>Не ошибается тот, кто ничего не делает. Как Вирт, например...
Да кто бы спорил. Вирт вообще мало чем был полезен и заметен в Computer Science.
А Линусу пути назад уже нет. Он слишком много чего нелестного сказал о CS еще в пору своих прений с Таненбаумом.
>> Интересно, а что он на Вирта-то наехал? Вирт-то фигура далеко не самая >> заметная в этом плане. Что не сразу на Дийкстру, Хоара, Кнута и >> Милнера? Неужели не посмел? >> Слабак!
C>[q]
>> I thought Edsger Dijkstra coined the "gotos are evil" bit in his >> structured programming push?
C>Yeah, he did, but he's dead, and we shouldn't talk ill of the dead. So C>these days I can only rant about Niklaus Wirth, who took the "structured C>programming" thing and enforced it in his languages (Pascal and Modula-2),
Каков, а!
Ловко перевел тему опять на Вирта.
Дийкстру не трогает. Боится. И правильно делает. Могут урыть.
Неужели им там в финляндии так же мозги конопатят виртом, как у нас в вузах.
Я не уверен, что все люди, которым он это говорит, слышали такую фамилию :)
sch wrote:
> Ответ Дейкстры еще не читал, но скажу что доводы автора не терпят > никакой критики. Ту же самую программу я бы написал приблизительно вот > так: > >int main() { > for(int i = 0; i < N; i++) { > int j; > for(j = 0; j < M && !array[i][j]; j++); > if(j == M) { > printf("first non-zero line is %d\n", i); > return i; > } > } > > printf("none found\n"); > return 0; >} > >
Ну так это и есть goto Просто в виде multiple return statement.
> За все мои N лет программирования, я использовал goto всего пару раз.
Вместо него обычно достаточно break/continue (как более нормальных форм
goto).
AVC wrote:
> Как бы то ни было, из "великой троицы" (Дейкстра, Хоар и Вирт) > неизменно атакуют именно Вирта. > То Керниган напишет запоздавшую на несколько лет статью "Why Pascal is > not my favourite programming language". > То Пайк в статье о стиле программирования на Си два раза упомянет > Паскаль, и оба раза в словосочетании "тирания Паскаля".
Так может быть это заслуженная критика?
> То вот Торвальдс выскажется, что goto — это хорошо, а Вирт занимается > "промывкой мозгов", и вообще ничего не понимает. В отличие от него, > Торвальдса. (Я так понял приведенную Cyberax'ом цитату.)
Угу. Причем мнение практика для меня значит намного больше, чем
рассуждения теоретиков.
> 2) начиная с Модулы-2 в виртовских языках действительно нет goto (и > ведь ничего страшного с его исчезновением не случилось).
Угу, там еще нет и break/continue. Только во всех реальных практических
реализациях они неизменно появляются.
> Могу предположить, что Вирта легче критиковать, потому что он > "превращает теорию в практику", создает языки программирования и > операционные системы.
Ну языки я и сам на досуге создаю А с операционными системами у
Торвальдса явно лучше результат.
AVC wrote:
> Я вообще не могу понять, о чем тут талдычит Торвальдс, кроме той > светлой мысли, что вот Дейкстра уже умер, давайте покончим с Виртом. > (Как и в другой его цитате, приведенной еще в первом посте топика.) > В *стандартнон* Паскале есть goto, в Модуле-2 и Обероне EXIT (=break).
and array begin case const div do
downto else end file for function goto
if in label mod nil not of
or packed procedure program record repeat set
then to type until var while with
break/continue здесь нет. Есть goto, но он conisdered harmful (и
вероятно за него студентов били ногами).
> Что вызвало такие "страдания молодого Линуса", что даже отшибло память > о конструкциях языка?
AVC wrote:
> В *стандартнон* Паскале есть goto, в Модуле-2 и Обероне EXIT (=break).
Или вот еще:
The appearance of goto labels as integers might be considered a sort of arcane
plot to punish people for using "goto"s. Many or most implementations allow
goto labels to appear in the same form as identifiers...
C>Угу. Причем мнение практика для меня значит намного больше, чем C>рассуждения теоретиков.
Не касаясь ничего остального просто замечу, что представляя, как это говорит авиаконструктор, я испытываю интересные ощущения.
Или врач, архитектор. Даже электрик :)
minorlogic wrote:
> C>Ну так это и есть goto Просто в виде multiple return statement. > Неумесная аналогия, return более безопасен и явно указывает на логику > выполнения, чего не скажешь про goto. Неумесная даже для шутки
reductor wrote:
> C>Угу. Причем мнение *практика* для меня значит намного больше, чем > C>рассуждения теоретиков. > Не касаясь ничего остального просто замечу, что представляя, как это > говорит авиаконструктор, я испытываю интересные ощущения.
У меня отец работал авиаконструктором — они там так примерно и говорят
> Или врач, архитектор. Даже электрик
Уж про врачей я вообще молчу — у них там анекдоты ходят, что на первой
практике студентов отучают лечить по учебникам.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> C>Угу. Причем мнение *практика* для меня значит намного больше, чем >> C>рассуждения теоретиков. >> Не касаясь ничего остального просто замечу, что представляя, как это >> говорит авиаконструктор, я испытываю интересные ощущения.
C>У меня отец работал авиаконструктором — они там так примерно и говорят :)
Я тоже могу так могу сказать про академиков в информатике — особенно, когда речь заходит о юникоде в GHC.
Но перегибать палку все же не стоит :)
>> Или врач, архитектор. Даже электрик :)
C>Уж про врачей я вообще молчу — у них там анекдоты ходят, что на первой C>практике студентов отучают лечить по учебникам.
Да, их учат быть научниками, относиться к учебнику как к последней истине — это одно из самого худшего, что может случиться с медиком.
Их учат опираться прежде всего на результаты исследований или здравый смысл и здоровую интуицию, когда чего-то нет ни в учебнике ни в исследованиях. http://www.pubmed.com — центральная база с последними отчетами.
Но теория играет там огромную роль. Недаром, чтобы стать врачом, нужно учиться 8 лет.
Здравствуйте, reductor, Вы писали:
R>Мне ничего не "кажется". Оценить влияние Никлауса Вирта и его вес в научном сообществе
А мы только про CS говорим или про программирование вообще?
R> можно посмотреть по адресу http://citeseer.ist.psu.edu/ R>И без истерик и идолопоклонничества.
Поиск в citeseer:
Niklaus Wirth:
CiteSeer: 45
Google: 157000
Robin Milner:
CiteSeer: 181
Google: 110000
R>Если же у вас есть свое мнение (наличие такового всегда вызывает уважение) по поводу того, что сделал Вирт, Паскаля, Оберона и тп — думаю, все бы рады были услышать подробный отчет со сравнениями тех языков, которые были актуальны в CS на тот момент.
Я не собираюсь ничего сравнивать. Мне просто интересно, на основании каких достижений ты позволяешь себе смеятся над работами Вирта?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Я начинал с Паскаля. Скажу честно, после Паскаля еще года два три, вообще ни break ни continue в циклах не использовал. Не потому что не нравилось, конструкции нормальные, просто не нужно было. Как то автоматически рука была набита обходиться без них. Да и сейчас у меня редко встретишь эти инструкции. Хотя только сейчас обратил внимание на данный факт.
А эти инструкции вообще в циклах крайне редки. Их применение — это когда предполагается одновременное изменение внешней среды во время выполнения тела цикла, и по каким-то причинам нецелесообразно на эти изменения реагировать в начале или конце цикла, а нужно именно посередине. У меня чаще всего встречается в некоем низкоуровневом коде.
Часто на всех уровнях можно встретить только break в switch-case.
Действительно, в большинстве случаев можно обойтись без них, вместо:
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
R>>Мне ничего не "кажется". Оценить влияние Никлауса Вирта и его вес в научном сообществе
E>А мы только про CS говорим или про программирование вообще?
R>> можно посмотреть по адресу http://citeseer.ist.psu.edu/ R>>И без истерик и идолопоклонничества.
E>Поиск в citeseer: E> Niklaus Wirth: E> CiteSeer: 45 E> Google: 157000 E> Robin Milner: E> CiteSeer: 181 E> Google: 110000
Не совсем правильный подход (хотя даже так вирт уступает в 4 раза).
Идем сюда: http://citeseer.ist.psu.edu/mostcited.html
Там собраны самые цитируемые ученые вообще (суммарно все публикации). Видим, что Милнер там на четвертом месте.
В окружении Ульмана, Кнута, Дийкстры, Хоара, Ривеста, Шамира, Лейзерсона и так далее (Надеюсь, представлять этих товарищей не нужно). Вопрос: на каком месте там Никлаус Вирт? Сколько его работ процитированы и легли в основу других? Сколько работ цитируют его работы? Сколько вообще работ у Вирта и сколько у Милнера?
E>Я не собираюсь ничего сравнивать. Мне просто интересно, на основании каких достижений ты позволяешь себе смеятся над работами Вирта?
А какое это имеет значение?
Если я скажу, что моя фамилия Плоткин — это будет иметь большее значение, чем если я скажу, что моя фамилия Пупкин?
На каком основании? Заслуги Никлауса Вирта зависят от чьей-то фамилии?
Я способен оценить и прочитать то, что пишет Вирт, этого достаточно.
Здравствуйте, reductor, Вы писали:
R>В окружении Ульмана, Кнута, Дийкстры, Хоара, Ривеста, Шамира, Лейзерсона и так далее (Надеюсь, представлять этих товарищей не нужно).
И Ульман что изобрел. Учебник хороший, не скрою. Но какой у него вклад? Но самое интересное, где Кодд? Вобщем это не вклад, а филькина грамота.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, reductor, Вы писали:
R>>Но это все не имеет никакого значения. Вклад в Computer Science Дийкстры и Хоара несоизмерим с Виртовским. Точнее, Паскаль уже не являлся чем-то особенно заметным в CS. Упрощенный Алгол. GZ>Какой Алгол?
Уже никакой.
R>>То, чем занимались Дийкстра, Хоар и Милнер сейчас лежит в основе SML, O'Caml и Haskell. GZ>Насчет Дейкстры и Милнера. Скорее их вклад в данные языки несооизмерим с вкладом Moses Schonfinkel, Alonso Church, Haskell Curry, H. Barendregt, Dana S. Scott, Peter J. Landin, и самое главное John McCarthy.
Вы точно ничего не путаете? Мы здесь не о математиках и логиках. Здесь обсуждается Computer Science и дизайн языков программирования. Хотя конечно заслуги того же Landin и McCarthy сложно переоценить. Вообще список имен можно продолжать бесконечно.
В чем суть вашего замечания?
R>>Не считая придуманных ими алгоритмов и сделаных открытий. Их влияние _огромно_.
R>>А Вирт? Язык Оберон. Даже не смешно. R>>То есть реально я вообще затруднюсь сказать что сделал Вирт в CS после своего участия в группе алгола. R>>40 лет одна и та же песня. GZ>Не перевирай факты и узнаешь. :)
Жду указания на вранье и доказательство такового. Чем быстрее, тем лучше.
AVC>>>Я понял, что Милнера (кто это?) и Маккарти Вы ставите выше, чем Вирта. Это Ваше неотъемлимое право. R>>Кто такой Милнер? Хороший вопрос на форуме, посвященном программированию. R>>Нет, правда. Робин Милнер — это такой человек, который в то время, когда Вирт делал Паскаль, совершил небольшую революцию в CS. R>>Создал язык ML и алгоритм вывода типов Хиндли-Милнера. А так же создатель пи-исчисления. Один из самых влиятельных и цитируемых ученых в мире. GZ>Милнер просто реализовал типизацию в комбинаторной логике исследованую Roger Hindley.
Вообще-то оригинальные исследования принадлежат H. Curry, А Хиндли с Милнером имели независимые исследования.
И давайте без этого "просто", да? А то так договоримся, что все математики просто реализуют идеи пифагора.
Список работ Милнера и их оценку можно посмотреть на http://citeseer.ist.psu.edu/
И это никак не отображает заслуги тех же Хиндли и Карри.
AVC>>>Но вот насчет оплеух Вирту "по делу", может быть, скажете пару ласковых слов? AVC>>>Так сказать, перед смертью. :) R>>А почему перед смертью? Он умирать собрался? R>>Хорошего о Вирте могу сказать, конечно — хотел бы я иметь его упорство. GZ>Для начала вы бы посмотрели что же он делал, а потом высказывались бы :)
Я смотрел. Что дальше. Опять намек непонятно на что как в случае с враньем выше? Еще раз напомню, что жду фактов.
. GZ>У меня сложилось такое превратное впечатление что любое упоминание о Вирте вызывает неприятие независимо от причины. Мне это не кажется конструктивным.
Дайте опровержение. Покажите работы Вирта, расскажите о их фундаментальности и влиянии. Или вам чье-то вранье все руки связало?
Здравствуйте, reductor, Вы писали:
E>>Я не собираюсь ничего сравнивать. Мне просто интересно, на основании каких достижений ты позволяешь себе смеятся над работами Вирта?
R>А какое это имеет значение?
Жаль, что ты не ответил на мой вопрос:
А мы только про CS говорим или про программирование вообще?
Видишь ли, к научному миру я отношения не имею. А когда пытался иметь это отношение, то у меня остались не самые хорошие воспоминания об этом деле. В частности о системе оценки работы по количеству публикаций.
Так что, если мы говорим только о научных публикациях, то ради бога, пусть Милнер будет в пять раз более цитируемым.
Размер вклада Вирта в программирование вообще это никак не умаляет.
R>Если я скажу, что моя фамилия Плоткин — это будет иметь большее значение, чем если я скажу, что моя фамилия Пупкин?
Будет. По этой фамилии можно будет сделать поиск в citeseer.
R>На каком основании? Заслуги Никлауса Вирта зависят от чьей-то фамилии? R>Я способен оценить и прочитать то, что пишет Вирт, этого достаточно.
Вот не зря же некоторые люди становятся авторитетами. И прислушиваются к их словам потому, что они что-то понимают, знают и умеют лучше остальных.
Вот буквально недавно был случай, в форуме про C++. 0xDEADBEEF изложил свой способ определения типа исключения (Re: подход к try-catch
), классный способ, интересный, многим понравился в своей простоте и удобстве. Мне в том числе. Да только оказалось, что этот способ уже был озвучен Страуструпом намного раньше (Все новое украдено до нас! :)))
. Не исключено, что и не Страуструпом был придуман. Но то, что после выхода книги Страуструпа этим способом стало пользоваться больше программистов -- это, имхо, однозначно.
Какое отношение этот конкретный прием имеет к CS? Да никакого. А вот к реальному, каждодневному программированию -- самое непосредственное. Вот и Вирт. Ты утверждаешь, что он никудышный ученый? Да бог его знает, не мне судить. А вот то, что он сделал много инструментов, на которых научилось работать (причем хорошо научилось и хорошо работать) масса программистов -- это бесспорно. И лично я думаю, что Вирт вполне заслужил уважительного отношения как к своей персоне, так и к своим высказываниям.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, reductor, Вы писали:
GZ>И Ульман что изобрел. Учебник хороший, не скрою. Но какой у него вклад? Но самое интересное, где Кодд? Вобщем это не вклад, а филькина грамота.
Во-первых вы что-то с неумеренной частотой мне отвечаете. И без всякого смысла транслируете сюда рейтинг сайтсира по одному.
Во-вторых, если вы чувствуете в себе дефицит образования и не можете ответить на вопрос чем заслужил второе место в списке Джеф Ульман, то лучше заняться своим образованием, чем пропагандировать здесь антиинтеллектуализм.
Там есть список работ и цитаты на них каждого автора. Почитайте.
То же касается и остальных упомянутых вами.
Здравствуйте, Cyberax, Вы писали:
>> В *стандартнон* Паскале есть goto, в Модуле-2 и Обероне EXIT (=break).
C>Или вот еще: C>
C>The appearance of goto labels as integers might be considered a sort of arcane
C>plot to punish people for using "goto"s. Many or most implementations allow
C>goto labels to appear in the same form as identifiers...
Т.е. Торвальдса замучили метки в виде чисел? (Никаких других "трудностей" вроде бы нет.)
Например:
while ... do
begin
while ... do
begin
...
if a[i][j] = 0 then(* ура, нашли! *)goto 999;
...
end
end;
999:
Как же часто надо было использовать goto, чтобы так настрадаться!
Что-то в отношении стиля молодого Линуса меня начинают терзать смутные подозрения...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, reductor, Вы писали:
GZ>>И Ульман что изобрел. Учебник хороший, не скрою. Но какой у него вклад? Но самое интересное, где Кодд? Вобщем это не вклад, а филькина грамота. R>Во-первых вы что-то с неумеренной частотой мне отвечаете.
Не вам, а вашим сообщениям. R>И без всякого смысла транслируете сюда рейтинг сайтсира по одному.
Смысл в том, что там смысла в этом индексе нет. Ну делают дисеры по функциональным языкам значительно чаще чем по структурным. Ну и ссылок поэтому больше.
Если вы хотите знать кто больше повлиял, то это делается очень легко. В CS есть такая же премия как и нобелевка в остальных науках, или Oscar в кинематографии. Называется премия Тьюринга. Посмотрите туда.http://www.acm.org/awards/taward.html Надеюсь вы не будете говорить о том что этот источник не достоен доверия?(кстати там можно увидеть и милнера, беру свои слова назад. Неодоценивал его).
R>Во-вторых, если вы чувствуете в себе дефицит образования и не можете ответить на вопрос чем заслужил второе место в списке Джеф Ульман, то лучше заняться своим образованием, чем пропагандировать здесь антиинтеллектуализм. Открою маленький секрет. В теория баз данных для меня нечто типа хобби. Поэтому я могу говорить о вкладах в теорию БД более квалифицированно. И могу судить о вкладах Codd'a и Ульмана.
Здравствуйте, minorlogic, Вы писали:
C>>И где здесь отсутствие логики в goto?
M>Тем что логика заключена в названии метки , а если бы было
C>>while(...) C>>{ C>> for(...) C>> { C>> if(...) goto label1; C>> } C>>}
M>Тогда , код уже не был бы таким понятным, особенно если метка не видна, и поди думай куда этот переход пошел ?
А если бы была куча функций, типа
function1, function2,..., functionn, которые друг-дружку вызывают. Так что, из-за этого мы должны отказаться от функций? Наоборот, возможность именования меток есть неоспоримое преимущество, так как по названию сразу становится понятно ху из ху. А вот куча всяких break'ов и continue наоборот может запутать логику и нужны будут дополнительные комментарии. Короче говоря, goto изредка может быть предпочтительнее, просто нужно знать где и как их стоит использовать, а где нет.
minorlogic wrote:
> Тем что логика заключена в названии метки , а если бы было > C>while(...) > C>{ > C> for(...) > C> { > C> if(...) goto label1; > C> } > C>} > Тогда , код уже не был бы таким понятным, особенно если метка не > видна, и поди думай куда этот переход пошел ?
А если функции у вас будут называться function1, function2 или a(),b(),c()?
eao197 wrote:
> C>А с операционными системами у > C>Торвальдса явно лучше результат. > Интересно, где бы был Торвальдс со своим ядром, если бы он делал > собственную ОС, а не очередной клон Unix-а?
Надо сказать, что ядро к окружению отношение не очень большое имеет (а
Unix — это прежде всего окружение). То есть на Linux'е можно запустить и
встроеное устройство вообще без файловой системы. Кроме того, критикам
Линуса стоит напомнить, что есть куча *BSD-систем, которые так и не
набрали популярность (в отличие от Линукса).
Технически, ядро в Линуксе весьма неплохое, а сейчас еще в нем
появляются новые фичи (типа возможности добавления пользовательских
scheduler'ов), которых до этого в mainstream'е не было.
Здравствуйте, Cyberax, Вы писали:
C>Надо сказать, что ядро к окружению отношение не очень большое имеет (а C>Unix — это прежде всего окружение).
Не сказал бы. Unix shell и утилиты -- да, это все окружение. А вот разные fork, open/close и вообще идеология open/read-write/close и все есть файл -- это же Unix-овый подход. Как же здесь без ядра?
C>Кроме того, критикам C>Линуса стоит напомнить, что есть куча *BSD-систем, которые так и не C>набрали популярность (в отличие от Линукса).
А вот это для меня до сих пор не понятно, как же стабильные BSD системы продули вчистую первым версиям Linux-а.
Видно, Unix wars тех времен сыграли свою отрицательную роль.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
E>>А вот это для меня до сих пор не понятно, как же стабильные BSD системы продули вчистую первым версиям Linux-а.
ANS>afaik, тогда freeBSD не было. Короче, на старте год потеряли и всё. Кривой линукс оказался в нужном месте в нужное время.
Подробнее здесь: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/history.html
Важно, что до 1994 года были юридические проблемы с BSD-шным кодом. Когда в 1995-м году появилась нормальная FreeBSD она была все равно, имхо, более продвинутой системой чем Linux. А монстры (типа IBM) стали вкладываться в Linux еще позже. Вот что их заставило выбрать именно Linux?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
> C>Надо сказать, что ядро к окружению отношение не очень большое имеет (а > C>Unix — это прежде всего окружение). > Не сказал бы. Unix shell и утилиты -- да, это все окружение. А вот > разные fork, open/close и вообще идеология open/read-write/close и все > есть файл -- это же Unix-овый подход. Как же здесь без ядра?
Ну fork и на Винде можно сделать, которая на это рассчитана не была. С
идеологией "все есть файл" — действительно нужна поддержка VFS в ядре. А
все остальное типа mmap фактически есть в любых ядрах с поддержкой
страничной памяти.
> C>Кроме того, критикам Линуса стоит напомнить, что есть куча > *BSD-систем, которые так и не > C>набрали популярность (в отличие от Линукса). > А вот это для меня до сих пор не понятно, как же стабильные BSD > системы продули вчистую первым версиям Linux-а. > Видно, Unix wars тех времен сыграли свою отрицательную роль.
Ну да, были проблемы с copyright. Плюс Линус смог создать команду
энтузиастов и достаточно открытый процесс разработки.
Здравствуйте, eao197, Вы писали:
E>Подробнее здесь: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/history.html
Важно, что до 1994 года были юридические проблемы с BSD-шным кодом. Когда в 1995-м году появилась нормальная FreeBSD она была все равно, имхо, более продвинутой системой чем Linux. А монстры (типа IBM) стали вкладываться в Linux еще позже. Вот что их заставило выбрать именно Linux?
Community? Котороя "инициализировалась" именно на этапе лицензионных проблем у BSD?
eao197 wrote:
> Подробнее здесь: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/history.html > Важно, что до 1994 года были юридические проблемы с BSD-шным кодом. > Когда в 1995-м году появилась нормальная FreeBSD она была все равно, > имхо, более продвинутой системой чем Linux. А монстры (типа IBM) стали > вкладываться в Linux еще позже. Вот что их заставило выбрать именно Linux?
В том числе и технические достоинства. Ядро Линукса в то время было
более расширяемым (FreeBSD был более совершенным, но менее расширяемым).
GlebZ wrote:
> Хотя не мы признавали Вирта одним из людей, которые внесли вклад в > развитие Computer Science.
Никто не отрицает вклад Вирта в Computer Science (например, можно на ISO
стандарт на BNF посмотреть).
Вот только CS и реальное программирование не совсем совпадают В
теории goto не нужен, так как заменяется структурами,
которые в теории лучше читаются. Но на практике часто бывает наоборот.
> Можно наезжать на поступки, нельзя наезжать на личность.
Ну так вроде бы лично на Вирта никто не наезжает. Наезжают на его
работы — а это уже совсем другое.
Здравствуйте, Cyberax, Вы писали:
>> Можно наезжать на поступки, нельзя наезжать на личность. C>Ну так вроде бы лично на Вирта никто не наезжает. Наезжают на его C>работы — а это уже совсем другое.
Нет. Наезды идут конкретно на самого Вирта. Начинают его пузом мерять. Дескать кто это такой, он не фига не сделал а нам только мешает получать удовольствие. Если бы это было в первый раз, то я бы промолчал. А так это уже не первый такой флейм. Несколько подобных флеймов уже перекочевало в священные войны. Есть и здесь.
Здравствуйте, GlebZ, Вы писали:
GZ>Да уж, дошли. GZ>Как-то раз появился господин Губанов и распальцованно начал объяснять что все языки отстой, что вы все неправильно делаете и есть только Oberon и Вирт пророк его. И настолько настойчиво указывал на это, что у большинства населения rsdn сложилась сильная антипатия к Oberon(иногда незаслуженная). Но самое главное не это. Самое главное что точно такая же антипатия сложилась и в отношении г-на Вирта. Любое упоминание Вирта вызывает стойкую антипатию не взирая на обстоятельства. И такие флеймы постоянно кочуют в Священные войны. Народ уже перестал разбираться в чем вопрос. Если в этом участвовал Вирт — то значит отстой. Хотя не мы признавали Вирта одним из людей, которые внесли вклад в развитие Computer Science. Это делали другие, более профессиональные люди, и делали это более независимо. И они не знали о Губанове(и об Обероне правда тоже ).
Конечно, "оберонщики" на rsdn.ru во многом сами виноваты. Нас здесь всего пара человек (Сергей да я), а такой стойкий негативный эффект.
Но некоторая "антипатия к Вирту" существует давно, и с нашими проделками на rsdn.ru не связана.
И Керниган, и Пайк, и Торвальдс, и многие другие — они же не rsdn начитались.
Я этого никак не могу понять. По первому впечатлению, большинство критиков относится к сторонникам Си-подобных языков.
(Сам Ритчи составляет достойное исключение из этого правила.)
Возможно, здесь какая-то (бессознательная) неприязнь к "конкуренту", или что-нибудь другое.
Главное, присоединяюсь к призыву критиковать не личности, а поступки и высказывания.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Игoрь, Вы писали:
И>Здравствуйте, minorlogic, Вы писали:
C>>>И где здесь отсутствие логики в goto?
M>>Тем что логика заключена в названии метки , а если бы было
C>>>while(...) C>>>{ C>>> for(...) C>>> { C>>> if(...) goto label1; C>>> } C>>>}
M>>Тогда , код уже не был бы таким понятным, особенно если метка не видна, и поди думай куда этот переход пошел ? И>А если бы была куча функций, типа И>function1, function2,..., functionn, которые друг-дружку вызывают. Так что, из-за этого мы должны отказаться от функций? Наоборот, возможность именования меток есть неоспоримое преимущество, так как по названию сразу становится понятно ху из ху. А вот куча всяких break'ов и continue наоборот может запутать логику и нужны будут дополнительные комментарии. Короче говоря, goto изредка может быть предпочтительнее, просто нужно знать где и как их стоит использовать, а где нет.
Так вот в том то и дело что метку можно назвать хорошо а МОЖНО ПЛОХО , а return не допускает вольной интерпретации, логика его работы прозрачна.
Например так станет намного хуже чем во втором примере:
Здравствуйте, eao197, Вы писали:
E>Подробнее здесь: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/history.html
Важно, что до 1994 года были юридические проблемы с BSD-шным кодом. Когда в 1995-м году появилась нормальная FreeBSD она была все равно, имхо, более продвинутой системой чем Linux. А монстры (типа IBM) стали вкладываться в Linux еще позже. Вот что их заставило выбрать именно Linux?
FreeBSD очень, нет ОЧЕНЬ трудно развивать. Абсолютно нечитабельные исходники. В каждой второй строке хочется воскликнуть "ну что за бред, я бы сделал так-то и так-то", смотришь с исходники Линуха, и там именно так-то и так-то сделано.
Здравствуйте, GlebZ, Вы писали:
R>>Во-вторых, если вы чувствуете в себе дефицит образования и не можете ответить на вопрос чем заслужил второе место в списке Джеф Ульман, то лучше заняться своим образованием, чем пропагандировать здесь антиинтеллектуализм. GZ> Открою маленький секрет. В теория баз данных для меня нечто типа хобби. Поэтому я могу говорить о вкладах в теорию БД более квалифицированно. И могу судить о вкладах Codd'a и Ульмана.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
E>>Подробнее здесь: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/history.html
Важно, что до 1994 года были юридические проблемы с BSD-шным кодом. Когда в 1995-м году появилась нормальная FreeBSD она была все равно, имхо, более продвинутой системой чем Linux. А монстры (типа IBM) стали вкладываться в Linux еще позже. Вот что их заставило выбрать именно Linux?
ANS>Community? Котороя "инициализировалась" именно на этапе лицензионных проблем у BSD?
Да, выглядит как самая вероятная версия.
Имхо, слишком много людей получили возможность стоять у истоков Linux-а. В отличии от уже стабильного BSD, влиться в который было гораздо сложнее.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
R>Далее. Есть одна наука. Одна математика. Одна информатика. Одна логика. Одно программирование.
А вот мнений о них много.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, reductor, Вы писали:
GZ>>>Не перевирай факты и узнаешь. R>>Жду указания на вранье и доказательство такового. Чем быстрее, тем лучше. GZ>Вирт никогда не участвовал в разработке Algola.
А что тогда его фамилия делает в Revised Report on the Algorithmic Language ALGOL 68
это вот здесь: http://members.dokom.net/w.kloke/RR/rrAck.html#Ack
?
GZ> Algol-60 появился до него. Его вариант в виде Algol-W был отвергнут комиссией. В результате была специфирована некая помойка в виде Algol-68 и без его участия.
А, ну да. Куча идиотов отвергла гениальное предложение гениального вирта в виде Algol-W, поэтому никакого отношения к алголу вирт не имеет. В том числе и к Algol-W.
GZ> Algol-W потом перешел в Паскаль, и как результат, Паскаль стал промышленным языком, Algol-68 — только же как сборище ссылок. Некоторые вещи Algol-68 все таки повзаимствовал у Algol-W, но это был уже другой язык.
Какой?
GZ> Виртом был создан первый структурный язык с нормальным дизайном и с модульным принципом построения программ.
Нет слов. Тихий ужас
GZ>Ну или возьмем EBNF. Это тоже упрощение Вирта. Сейчас уже де факто он используется вместо BNF.
Знаете, всему нужно знать предел. Где в сочетании Backus-Naur зашифрована фамилия Wirth? И еще переделка _стандарта_ как лучшее научное достижение, заставляет трепетать душу и сердце.
GZ>Но вообще, наибольшее достижение Вирта — это школа построения компиляторов. Во многом те компиляторы которые мы используем — это детище Вирта. Потому как Паскаль и Модула, его работы связанные с ними и послужили примером что такое эффективный концептуальный компилятор.
После этого заявления, я прекращаю дальнейшее обсуждение с вами любых тема, касающихся Computer Science.
Пардон, что личное, но мне дорого мое время.
Школа компиляторов — Это Backus, McCarthy, Knuth, Turner, Milner, Strachey, Scott и так почему-то нелюбимый вами Ульман вот с этой книжкой: http://www.amazon.com/gp/product/0201100886/002-5958156-7611205?v=glance&n=283155&n=507846&s=books&v=glance
Если очень хочется, туда еще можно Хомского записать.
Не буду даже спрашивать, кто эти "мы", которые пользуются исключительно детищами вирта для компиляции.
R>>Вообще-то оригинальные исследования принадлежат H. Curry, А Хиндли с Милнером имели независимые исследования. R>>И давайте без этого "просто", да? А то так договоримся, что все математики просто реализуют идеи пифагора. R>>Список работ Милнера и их оценку можно посмотреть на http://citeseer.ist.psu.edu/ R>>И это никак не отображает заслуги тех же Хиндли и Карри.
GZ>Там же можешь посмотреть и список работ Wirth. Или лучше на ACM. Это более качественный источник, поскольку там публикуются только важные научные статьи а не все диссертации и подряд.
Мы видимо про разные науки говорим. А список работ вирта я видел и даже наверное смогу перечислить по памяти — благо, он совсем короткий.
R>>Дайте опровержение. Покажите работы Вирта, расскажите о их фундаментальности и влиянии. Или вам чье-то вранье все руки связало?
GZ>Можешь и сам их найти. Как Вирта так и его совместные работы. Например с тем же, твоим любимым Хоаром.
Это доклад по алголу-то? Это все? Впрочем, не отвечайте. Достаточно.
M>Так вот в том то и дело что метку можно назвать хорошо а МОЖНО ПЛОХО , а return не допускает вольной интерпретации, логика его работы прозрачна.
Ну и что из этого следует? Я же выше сказал, что и функцию МОЖНО ПЛОХО назвать, но главное что можно и хорошо.
По-моему тема с goto высосона из пальца. Просто не стоит ими злоупотреблять вот и все. А прогу запутать легко и без явных меток, что многие успешно делают.
Здравствуйте, reductor, Вы писали:
R>Во-первых, раз и навсегда — идея противопостовления структурного и функционального программирования — это крайне дикая идея. Функциональные языки, надо полагать, не вписываются в языки "структурные"?
Нет. Не противопоставляет. Это параллельные направления. Ну например, вделали в С# делегаты. Стал ли он от этого функциональным? Нет. Это всего лишь штука удобная в использовании которую иногда используют в полуфункциональном виде(даже повторюсь, именно полуфункциональном). Или например, представь себе если в SML или лиспе уберут списки и разрешат использовать состояние внутри функции.
Безусловно есть вещи которые едины во всех ипостасях, но само разделение между функциональным и структурным программированием будет поскольку поскольку между этими двумя стилями существуют противоречия.
R>Далее. Есть одна наука. Одна математика. Одна информатика. Одна логика. Одно программирование. R>Если в науке нет публикаций на какую-то тему, значит эта тема неактуальна. Уже неактуальна, еще неактуальна, вообще неактуальна и несуществует или не имеет смысла — что угодно, значит темы нет. Почему нет дисеров по "структурном языкам"? По поиску философского камня? Торсионным полям? Биоэнергетике? Школьной арифметике? Полетам на альдебаран? R>А вот потому. R>Если кого-то душит ощущение несправедливости по этому поводу или он считает, что научные институты — это масонский заговор и настоящих ученых зажимают, то с этим к психиатру.
Нет никакого заговора. С функциональными языками значительно интересней. У нее есть мат. модель. Эту мат. модель очень удобно использовать. Так зачем использовать модель в которой нельзя ничего доказать(как это со структурными языками)? Поэтому все мат. обоснованные фичи появляются прежде всего на функциональных языках.
R>И еще. Такие премии получают раз в жизни и как угодно сравнивать двух лауреатов без дополнительной информации нет никакой возможности. Поэтому, предлагаю больше не заниматься такой профанацией.
Отчего же все стремятся получить данные премии? Безусловно, некоторая полит. составляющая есть. Только она незначительна. Посмотри список и скажи кто там лишний. У меня есть идеи кого там не хватает, некоторых людей я не знаю(не работал в их областях) но тех кто там есть и я их знаю, они там есть вполне заслуженно. Там кстати написано за какие конкретные заслуги они получили премии.
R>Ну расскажите тогда о своем квалифицированном мнении о Кодде и Ульмане. С цитатами, примерами и подробным научным анализом. Чтобы уже ни у кого не оставалось сомнения в том почему создатель например реляционной модели недостоин иметь такое количество цитат на его работы.
Ну и чего. Кто такой Кодд(на которого ссылок нет). Сей недостойный человек описал реляционную модель которой мы пользуемся. Ну еще кое что. Так фигня всякая. Типа Olap. Ну описал он математику этого Olap. А так больше ничего не сделал. Ссылки на него просто никому не нужны.
Ульман. Вот это великий человек. Написал книгу о теории баз данных. Продвигал идею Data Mining. Работал над оптимизацией многомерных запросов(правда R индексы открыл не он). Ну там, входил в группу Lorel.
Как сравнивать несравнимое? Ульман крут. На него ведь столько ссылок.
А если серьезно, я вполне корректно и с уважением отношусь к Ульману(особенно к его участию в Lorel проекте), но если сравнивать его вклад с работами Кодда — то это небо и земля. Это противоставление я сделал для того, чтобы показать что ваш список некорректен.
R>А рекламу квалификации напишите кстати лучше в резюме. Здесь, я думаю, ее и без дополнительной рекламы способны оценить по тому что вы пишите.
Ваше право.
R>>А какое это имеет значение?
E>Жаль, что ты не ответил на мой вопрос:
затер в суматохе.
E>
E>А мы только про CS говорим или про программирование вообще?
А что, можно отделить CS от программирования без ущерба для последнего?
программирование напрямую следует из CS и без него было бы невозможно.
А если речь идет о заслугах перед индустрией, то в таком случае скорее нужно устроить культ поклонения биллу гейтсу и ларри эллисону.
Или на худой конец страуструпу или ларри уоллу — их детища имели гораздо больший коммерческий успех.
E>Видишь ли, к научному миру я отношения не имею. А когда пытался иметь это отношение, то у меня остались не самые хорошие воспоминания об этом деле. В частности о системе оценки работы по количеству публикаций.
По количеству ссылок на публикации. Впрочем, количество работ у вирта тоже не фонтан.
E>Так что, если мы говорим только о научных публикациях, то ради бога, пусть Милнер будет в пять раз более цитируемым. E>Размер вклада Вирта в программирование вообще это никак не умаляет.
Так какой же это все-таки вклад? Коммерческий успех турбо-паскаля? Дельфи? У Visual Studio больше.
R>>Если я скажу, что моя фамилия Плоткин — это будет иметь большее значение, чем если я скажу, что моя фамилия Пупкин?
E>Будет. По этой фамилии можно будет сделать поиск в citeseer.
И что? Как от этого изменятся заслуги объекта дискуссии?
R>>На каком основании? Заслуги Никлауса Вирта зависят от чьей-то фамилии? R>>Я способен оценить и прочитать то, что пишет Вирт, этого достаточно.
E>Вот не зря же некоторые люди становятся авторитетами. И прислушиваются к их словам потому, что они что-то понимают, знают и умеют лучше остальных.
Авторитетами среди кого? Среди некоторой части российских индустриальных программистов?
Ну да. А еще Билл Гейтс.
E>Вот буквально недавно был случай, в форуме про C++.
Вы извините, если я не буду читать? Я не уверен, что форум поможет нам в исторических изысканиях.
E>Какое отношение этот конкретный прием имеет к CS? Да никакого. А вот к реальному, каждодневному программированию -- самое непосредственное. Вот и Вирт. Ты утверждаешь, что он никудышный ученый? Да бог его знает, не мне судить. А вот то, что он сделал много инструментов, на которых научилось работать (причем хорошо научилось и хорошо работать) масса программистов -- это бесспорно. И лично я думаю, что Вирт вполне заслужил уважительного отношения как к своей персоне, так и к своим высказываниям.
Да сколько угодно. Только я знаю людей, которые сделали большее количество и более удобных инструментов.
Но речь изначально шла не о том.
Здравствуйте, reductor, Вы писали:
R>А что тогда его фамилия делает в Revised Report on the Algorithmic Language ALGOL 68 R>это вот здесь: http://members.dokom.net/w.kloke/RR/rrAck.html#Ack R>?
Читаем что написано:
[8] N. Wirth, A Proposal for a Report on a Successor of ALGOL 60, Mathematisch Centrum, Amsterdam, MR 75, October 1965.
В сам комитет Вирт не входил. Там была знойная история, но искать мне во второй раз уже лениво. Я этот вопрос гуглил еще в прошлом флейме. Валяется где-то в священных войнах. Туда не хожу из принципа.
GZ>> Algol-60 появился до него. Его вариант в виде Algol-W был отвергнут комиссией. В результате была специфирована некая помойка в виде Algol-68 и без его участия. R>А, ну да. Куча идиотов отвергла гениальное предложение гениального вирта в виде Algol-W, поэтому никакого отношения к алголу вирт не имеет. В том числе и к Algol-W.
Насчет идиотов — это ты сказал.
GZ>> Algol-W потом перешел в Паскаль, и как результат, Паскаль стал промышленным языком, Algol-68 — только же как сборище ссылок. Некоторые вещи Algol-68 все таки повзаимствовал у Algol-W, но это был уже другой язык. R>Какой? Алгол-68
GZ>> Виртом был создан первый структурный язык с нормальным дизайном и с модульным принципом построения программ. R>Нет слов. Тихий ужас
Не нравится? Докажи обратное.
GZ>>Ну или возьмем EBNF. Это тоже упрощение Вирта. Сейчас уже де факто он используется вместо BNF. R>Знаете, всему нужно знать предел. Где в сочетании Backus-Naur зашифрована фамилия Wirth? И еще переделка _стандарта_ как лучшее научное достижение, заставляет трепетать душу и сердце.
BNF и EBNF — различия видишь? Или если есть расширенная реляционная алгебра, то у нее нет автора? Смешно.
GZ>>Но вообще, наибольшее достижение Вирта — это школа построения компиляторов. Во многом те компиляторы которые мы используем — это детище Вирта. Потому как Паскаль и Модула, его работы связанные с ними и послужили примером что такое эффективный концептуальный компилятор. R>После этого заявления, я прекращаю дальнейшее обсуждение с вами любых тема, касающихся Computer Science. R>Пардон, что личное, но мне дорого мое время. R>Школа компиляторов — Это Backus, McCarthy, Knuth, Turner, Milner, Strachey, Scott R>и так почему-то нелюбимый вами Ульман вот с этой книжкой:
Нелюбимый — не говорил.
R> http://www.amazon.com/gp/product/0201100886/002-5958156-7611205?v=glance&n=283155&n=507846&s=books&v=glance
Красный дракон? Действительно он. Обычно обращаешь внимание на первое имя(АХО). Ну и работы Sethi — тоже известные работы. А теперь пожалуйста приведи мне пример что он изобрел. То что он изобрел я знаю, и уже приводил. Дополни список.
R>Если очень хочется, туда еще можно Хомского записать.
Ооо. Ноар Хомский, конечно. Как это не странно, но его почему-то в индексах я также не нашел. Хотя индекс цитирования его как политика в Америке, ну очень высокий. R>Не буду даже спрашивать, кто эти "мы", которые пользуются исключительно детищами вирта для компиляции.
Это ваше конкретное право.
R>Мы видимо про разные науки говорим. А список работ вирта я видел и даже наверное смогу перечислить по памяти — благо, он совсем короткий.
Ну да... Удивлен немало.
R>>>Дайте опровержение. Покажите работы Вирта, расскажите о их фундаментальности и влиянии. Или вам чье-то вранье все руки связало? GZ>>Можешь и сам их найти. Как Вирта так и его совместные работы. Например с тем же, твоим любимым Хоаром. R>Это доклад по алголу-то? Это все? Впрочем, не отвечайте. Достаточно.
Блин, где вы видили доклад по Алголу. Ссылку в студию. Может все таки прочитаете что в этих статьях написано. Даже те, которые по Алголу. Я видите-ли туда заглядывал. А вы?
E>>А мы только про CS говорим или про программирование вообще?
R>А что, можно отделить CS от программирования без ущерба для последнего? R>программирование напрямую следует из CS и без него было бы невозможно.
Любая теория проверяется практикой. Практика без теории не существует и наоборот. Только иногда практика и теория это совершенно разные вещи.
Науку (как вид деятельности) совершенно не интересуют практические реализации научных идей. Успешность научных сотрудников измеряется количеством публикаций. В то же время успешность программного продукта может совершенно не зависеть от степени его наукоемкости. Фокус в том, что создать успешный программный продукт не проще, чем написать хорошую научную работу и стать цитируемым автором. Вирт как раз является человеком, который умеет делать успешные продукты. Причем много чего делает сам, собственноручно их программируя.
R>А если речь идет о заслугах перед индустрией, то в таком случае скорее нужно устроить культ поклонения биллу гейтсу и ларри эллисону.
Не нужно путать технологию и маркетинг, это разные вещи.
R>Или на худой конец страуструпу или ларри уоллу — их детища имели гораздо больший коммерческий успех.
Не думаю, что Страуструп зарабатывал непосредственно на компиляторах языка C++. Скорее всего, только на книгах об этом языке.
E>>Так что, если мы говорим только о научных публикациях, то ради бога, пусть Милнер будет в пять раз более цитируемым. E>>Размер вклада Вирта в программирование вообще это никак не умаляет.
R>Так какой же это все-таки вклад? Коммерческий успех турбо-паскаля? Дельфи? У Visual Studio больше.
Насколько мне извесно, к Турбо Паскалю Вирт не имел отношения. А вот то, что Паскаль стал базой для множества последующих языков -- это точно.
R>>>Если я скажу, что моя фамилия Плоткин — это будет иметь большее значение, чем если я скажу, что моя фамилия Пупкин?
E>>Будет. По этой фамилии можно будет сделать поиск в citeseer.
R>И что? Как от этого изменятся заслуги объекта дискуссии?
Заслуги Вирта, к счастью, от наших разборок не зависят.
А вот оценка адекватности твоих высказываний вполне может измениться.
R>Да сколько угодно. Только я знаю людей, которые сделали большее количество и более удобных инструментов.
И получили за это премию Тьюринга?
R>Но речь изначально шла не о том.
Ok. Я думаю пора заканчивать. А то точно в "Священые воины" уедем.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Можно, очень даже. Причем без всякого ущерба — для того, чтобы писать C>код вовсе не нужно знать что такое тезис Черча-Тьюринга, нормальные C>алгоритмы Маркова и EBNF.
C>Хороший программист о них, конечно, должен знать, но это скорее просто C>background knowledge (как мат.анализ или алгебра).
Да ладно. Конечно не должен!
Хороший программист — это когда в слюнявчике, утка, детское питание по катетеру, мышь без колеса и клавиатура с одной кнопкой — для вызова сиделки с проджект менеджером.
Дийкстру, с его стандартами программиста откопать и сжечь вместе с рукописями.
А MIT, CMU, Stanford и Yale — расстрелять из BFG, чтобы не плодили яйцеголовых умников.
Здравствуйте, eao197, Вы писали:
E>Не думаю, что Страуструп зарабатывал непосредственно на компиляторах языка C++. Скорее всего, только на книгах об этом языке.
А ведь Евгений, скорее всего, прав.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, reductor, Вы писали:
C>>Хороший программист о них, конечно, должен знать, но это скорее просто C>>background knowledge (как мат.анализ или алгебра).
R>Да ладно. Конечно не должен! R>Хороший программист — это когда в слюнявчике, утка, детское питание по катетеру, мышь без колеса и клавиатура с одной кнопкой — для вызова сиделки с проджект менеджером.
R>Дийкстру, с его стандартами программиста откопать и сжечь вместе с рукописями. R>А MIT, CMU, Stanford и Yale — расстрелять из BFG, чтобы не плодили яйцеголовых умников.
Ну все, трындец. Хорошие программисты -- это только из MIT, CMU, Stanford, Yale... А вот мне, похоже не суждено. Не там уродился.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Можно, очень даже. Причем без всякого ущерба — для того, чтобы писать C>код вовсе не нужно знать что такое тезис Черча-Тьюринга, нормальные C>алгоритмы Маркова и EBNF.
C>Хороший программист о них, конечно, должен знать, но это скорее просто C>background knowledge (как мат.анализ или алгебра).
Правильно, должно же и в backgroundе что-то быть.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
R>>Паскаль прямой потомок Алгола. R>>Но это все не имеет никакого значения.
AVC>Само собой. AVC>По сравнению с самым влиятельным языком современности (ML, разумеется) мало что имеет значение...
Если это сарказм, то он еще хуже, чем предыдущий.
Во-первых, непонятна нападка на ML, а во-вторых очень комичен контекст сравнения ML и паскаля.
Да, с ML паскалю не сравниться ни в чем и ни при каких условиях.
R>>А Вирт? Язык Оберон. Даже не смешно.
AVC>Вы, насколько я понимаю, мало интересуетесь императивными языками. AVC>Конечно, Вам трудно что-то сказать по этому поводу (как мне — о функциональных языках). AVC>Они для вас "как китайцы" — все на одно лицо.
Вы а) неверно понимаете, б) слишком много фантазируете.
Во-первых меня не интересуют императивные или функциональные языки. Меня интересует программирование и языки программирования.
А вот такие попытки разделения сфер влияния мне кажутся уделом городских сумасшедших.
Что для меня как китайцы...
В моей обычной практике я использую около 30 языков программирования. Среди них хватает и императивных и функциональных и логических и стековых и гибридов всего этого смешанных вместе.
А сколько их я в свое время учил и забывал я даже затруднюсь сказать.
Но мне конечно будет непросто устоять перед вашей эрудицией в области языков Никлауса Вирта.
R>>Нет. Все вместе и по очереди.
AVC>То есть конкретно сказать нечего, кроме того, что Вам больше нравятся функциональные языки?
Здесь я тоже должен заметить, что вы слишком много фантазируете, в моем сообщении не было было слова "функциональный" вообще. И я точно не говорил, что мне нравится.
AVC>Ничего не имею против. Только обратил бы внимание, что и у императивных языков есть своя ниша.
Есть, а кто спорил? Или опять фантазии?
AVC>В Оксфорде на "первое" подают Хаскель, на "второе" — Оберон. И при этом об Обероне отзываются очень хорошо.
Ну если только подают. Оберон может и неплох для практики и набивания руки в императивном программировании.
Потом его можнно смело забывать. Я вот его уже больше 10 лет не помню.
R>>Кто такой Милнер? Хороший вопрос на форуме, посвященном программированию. R>>Нет, правда. Робин Милнер — это такой человек, который в то время, когда Вирт делал Паскаль, совершил небольшую революцию в CS.
R>>Создал язык ML и алгоритм вывода типов Хиндли-Милнера. А так же создатель пи-исчисления. Один из самых влиятельных и цитируемых ученых в мире.
AVC>Ну, я догадывался, что Милнер — автор одного из функциональных языков, о которых Вы так восторженно говорите.
Невероятная догадливость. А что такое функциональный?
AVC>Только не знал — какого именно. :shuffle:
А вы много их знаете, что никак не решались выбрать?
AVC>И на кого же он так повлиял (кроме других ученых, разумеется)?
На другие языки, на других дизайнеров языков, на программистов, на тех, кто вручал ему премию тьюринга. Ну и на других, разумеется, ученых.
AVC>А то его безмерное могущество не везде так сильно ощущается. :shuffle:
Но это же прекрасно!
И не нужно вам этого ощущать, поверьте мне!
Здравствуйте, GlebZ, Вы писали:
GZ>BNF и EBNF — различия видишь? Или если есть расширенная реляционная алгебра, то у нее нет автора? Смешно.
насколько я помню, EBNF не добавляет к возможностям BNF ничего нового, кроме небольшого количества синтаксического сахарка
в общем, не то это достижение, которым стоит гордиться
Здравствуйте, AVC, Вы писали:
AVC>Т.е. Торвальдса замучили метки в виде чисел? (Никаких других "трудностей" вроде бы нет.) AVC>Например: AVC>
AVC>while ... do
AVC>begin
AVC> while ... do
AVC> begin
AVC> ...
AVC> if a[i][j] = 0 then(* ура, нашли! *)goto 999;
AVC> ...
AVC> end
AVC>end;
AVC>999:
Другой пример:
while ... do
begin
while ... do
begin
...
if a[i][j] = 0 then goto found;
...
end
end;
found:
В чём разница?
Во втором случае код документирован в 2х местах, вместо одного. И меньшими затратами.
AVC>Как же часто надо было использовать goto, чтобы так настрадаться!
Могу выдумать только такие аналогии: Метки в виде чисел берут начало от времён, когда строки нумеровать нужно было. Древние диалекты бейсика только так и позволяли делать go to.
Символьные метки появились в первых асемблерах и имели приблизительно тот же смысл, что и имена функций/переменных сейчас.
Последний случай — практическая необходимость, вызванная поребностью в более читаемых исходниках (до меток использовали числовые адреса).
Каких либо аргументов в пользу первого придумать не могу. Есть ли они? ИМХО как раз их отсутствие и является причиной недовольства числовыми метками, а вовсе не частота использования goto.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, шапокляк, Вы писали: Ш>Я тут конешно новенькая и меня легко затоптать. Но сложите 2 и 2. Лауреаты премии Тьюринга люди не святые. Но коли с ними переходят на личности то уж никак не от большова ума. И што тут спорить? Ну а научный уровень Линуса Торвальдса можно даже не обсуждать. Хотя я не удивлюсь если его протолкнут в лауреаты Тьюринга. Такова жизнь.
Скорей верблюд пройдет в игольное ушко, чем Линус пополнит этот список. Такова премия Тьюринга.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> C>Угу. Причем мнение *практика* для меня значит намного больше, чем >> C>рассуждения теоретиков. >> Не касаясь ничего остального просто замечу, что представляя, как это >> говорит авиаконструктор, я испытываю интересные ощущения.
C>У меня отец работал авиаконструктором — они там так примерно и говорят
>> Или врач, архитектор. Даже электрик
C>Уж про врачей я вообще молчу — у них там анекдоты ходят, что на первой C>практике студентов отучают лечить по учебникам.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Теперь мне понятно почему самолеты падают!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
eao197 wrote:
> E>>Вирт как раз является человеком, который умеет делать успешные > продукты. > Д>"успешные продукты" (во множественном числе) — это Паскаль? > Давай определимся с критериями успешности. Если успешность продукта > определяется количеством проданных/используемых копий, то, вероятно, > только Паскаль подойдет под это определение.
По-моему, Вирт все же больше относиться к академикам (где его достижения
действительно весьма большие), а не к практикам.
Паскаль был абсолютным хитом в свое время — хороший, продуманый, простой
язык. Он оказал влияние на кучу последующих языков, и до сих пор
используется для обучения. Одно это тянет на премию Тьюринга
Вот только потом у Вирта начались непонятки с Модулами и Оберонами — они
фактически уже не добавляли ничего нового, по сравнению с уже
существовавшими языками. Вирт успешно пропустил распространение
объектно-ориентированного, функционального и обобщенного
программирования. А сейчас до сих пор в своих языках занимается (в
основном) идеологией без нововведений. За это Вирта и не любят тут
Здравствуйте, GlebZ, Вы писали:
GZ>Как-то раз появился господин Губанов и распальцованно начал объяснять что все языки отстой, что вы все неправильно делаете и есть только Oberon и Вирт пророк его. И настолько настойчиво указывал на это, что у большинства населения rsdn сложилась сильная антипатия к Oberon(иногда незаслуженная). Но самое главное не это. Самое главное что точно такая же антипатия сложилась и в отношении г-на Вирта. Любое упоминание Вирта вызывает стойкую антипатию не взирая на обстоятельства. И такие флеймы постоянно кочуют в Священные войны. Народ уже перестал разбираться в чем вопрос. Если в этом участвовал Вирт — то значит отстой. Хотя не мы признавали Вирта одним из людей, которые внесли вклад в развитие Computer Science. Это делали другие, более профессиональные люди, и делали это более независимо. И они не знали о Губанове(и об Обероне правда тоже ).
на самом деле, Вирт сам вызывает антипатию к себе своими резкими, необоснованными и порой просто невежественными высказываниями
в частности, что
1. Ява — это Оберон, испорченный сишным синтаксисом
2. Функциональные языки никому не нужны, и вообще, они — просто подмножество императивных языков
3. Все современные языки ни на что не годятся, и только Оберон рулит неимоверно. Потому что его синтаксис очень простой, и это одним махом решает все существующие проблемы программирования.
4. Оберон никто не использует, потому что ему нигде не обучают. И вообще, все вокруг сговорились, чтобы вытеснить Оберон с рынка.
и так далее, и тому подобное
GZ>Поэтому предложил бы объявить людей, которые являются Нобелевскими лауреатами и лауреатами премии Тьюринга священными коровами. И баннить наезды на них по полной так же как и наезды на личности на rsdn. То есть добавить правило что личности из списка Премии Тьюринга священны, и личные нападки на этих людей есть нападки на все IT сообщество. Можно наезжать на поступки, нельзя наезжать на личность.
Может быть, все-таки не станем устраивать идолопоклонничество?
Здравствуйте, GlebZ, Вы писали:
R>>Во-первых, раз и навсегда — идея противопостовления структурного и функционального программирования — это крайне дикая идея. Функциональные языки, надо полагать, не вписываются в языки "структурные"? GZ> представь себе если в SML или лиспе уберут списки и разрешат использовать состояние внутри функции.
В SML можно использовать состояние внутри функции
Здравствуйте, Игoрь, Вы писали:
И>Здравствуйте, minorlogic, Вы писали:
M>>Так вот в том то и дело что метку можно назвать хорошо а МОЖНО ПЛОХО , а return не допускает вольной интерпретации, логика его работы прозрачна. И>Ну и что из этого следует? Я же выше сказал, что и функцию МОЖНО ПЛОХО назвать, но главное что можно и хорошо.
Метки для goto гораздо сложнее назвать хорошо. Наиболее часто используемые имена выглядят так: end_if, end_loop, exit, start_loop, else_branch. А с учетом того, что метки в определенной области видимости должны быть уникальны, приходится извращаться с добавлением суффиксов. Это также создает проблемы при переносе какого-то участка кода в другое место: часто приходится переименовывать метки, из-за чего могут вноситься ошибки. Например,
во-втором goto exit1; может действительно подразумевался выход из двух вложенных циклов, а может кто-то просто забыл (при переносе кода) exit1 заменить на exit2.
Здравствуйте, eao197, Вы писали:
R>>В моей обычной практике я использую около 30 языков программирования. Среди них хватает и императивных и функциональных и логических и стековых и гибридов всего этого смешанных вместе.
E>Можно ли развить эту тему по-подробнее? E>Это действительно интересно, т.к. недавно я утверждал, что сложно одновременно использовать в проекте 3-5 языков (Re[2]: Предагаю мир!
). E>Но здесь цифра просто на порядок большая . Можно ли подробнее, что это за языки, для каких целей используются, как применяются, какие замечены достоинства/недостатки использования такого количества языков, используется ли это все в рамках одного проекта, какова численность команды и пр.?
E>Я думаю, что это будет интересно не только мне.
30 одновременно используемых в проекте — это явное преувеличение, ИМХО. Наверно имелось ввиду, что в разное время использует много языков, всего до 30 различных.
А вообще, у меня тоже практически каждый проект "разношерстный". Обычно 2 "главных" языка, и затем практически в любой проект автоматически добавляются SQL, HTML, JavaScript/DHTML, VBA, XML, Perl.
Иногда прикручиваются еще всякие скриптовые или специфические, типа Пролог, MatLab, Forth и т.д.
------
С подачи Редуктора заинтересовался Хаскелем, найти бы время на эксперименты с ним...
Здравствуйте, vdimas, Вы писали:
V>А вообще, у меня тоже практически каждый проект "разношерстный". Обычно 2 "главных" языка, и затем практически в любой проект автоматически добавляются SQL, HTML, JavaScript/DHTML, VBA, XML, Perl.
Если считать SQL, XML и HTML за языки программирования, то тогда счет может идти на сотни
V>Иногда прикручиваются еще всякие скриптовые или специфические, типа Пролог, MatLab, Forth и т.д.
А зачем? Можно ли примеры?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>Я просто предположил.
Да ладно, бывает. Однако в этом топике идет, в общем-то, нормальная дискуссия. Не хотелось бы превращать ее в очередную священную войну, плавно переходящую в виртуальный мордобой.
Здравствуйте, Privalov, Вы писали:
P>Да ладно, бывает. Однако в этом топике идет, в общем-то, нормальная дискуссия. Не хотелось бы превращать ее в очередную священную войну, плавно переходящую в виртуальный мордобой.
Здравствуйте, reductor, Вы писали:
R>Как пример — Java/Prolog/Scheme/Python (Все могут быть и в пределах одной java-машины) на сервере и Smalltalk, Javascript, Tcl на клиенте. + еще VB на клиенте внутри Ms Office
В чем преимущество связки Java+Prolog?
В каких задачах это может потребоваться?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Глеб Алексеев, Вы писали:
GZ>> представь себе если в SML или лиспе уберут списки и разрешат использовать состояние внутри функции. ГА>В SML можно использовать состояние внутри функции
Конкретнее.
Здравствуйте, Дарней, Вы писали:
Д>на самом деле, Вирт сам вызывает антипатию к себе своими резкими, необоснованными и порой просто невежественными высказываниями Д>в частности, что Д>1. Ява — это Оберон, испорченный сишным синтаксисом
Имеет право. Он Оберон-то лучше знает. Д>2. Функциональные языки никому не нужны, и вообще, они — просто подмножество императивных языков
Где он такое говорил? Ссылку. Я слышал от него другие слова. Д>3. Все современные языки ни на что не годятся, и только Оберон рулит неимоверно.
Это я тоже не слышал в его исполнении. Д>Потому что его синтаксис очень простой, и это одним махом решает все существующие проблемы программирования.
Почти так была информация. Только откуда взялось все существующие проблемы? Ты сам своими словами пытаешься сделать из него идола. Я сомневаюсь что он такого мнения о себе. Он достаточно интересный старикашка с весьма интересными мнениями, но бреда от него я не заметил. Д>4. Оберон никто не использует, потому что ему нигде не обучают. И вообще, все вокруг сговорились, чтобы вытеснить Оберон с рынка. Д>и так далее, и тому подобное
1. Вообще-то Оберон кое-где изучают.
2. Лично я ему такое высказывание прощу(хотя дословно оно было другое). Обидно человеку. Но вот невежественными их назвать не могу.
GZ>>Поэтому предложил бы объявить людей, которые являются Нобелевскими лауреатами и лауреатами премии Тьюринга священными коровами. И баннить наезды на них по полной так же как и наезды на личности на rsdn. То есть добавить правило что личности из списка Премии Тьюринга священны, и личные нападки на этих людей есть нападки на все IT сообщество. Можно наезжать на поступки, нельзя наезжать на личность. Д>Может быть, все-таки не станем устраивать идолопоклонничество?
Не идолопоклончество. А уважение. Это разные вещи.
ГА>fun imperative fact (n:int) =
ГА>let
ГА> val result = ref 1
ГА> val i = ref 0
ГА> fun loop () =
ГА> if !i = n then
ГА> ()
ГА> else
ГА> (i := !i + 1;
ГА> result := !result * !i;
ГА> loop ())
ГА> in
ГА> loop (); !result
ГА> end
ГА>
Да, про рефы забыл ГА>Конечно, все это выглядит достаточно некрасиво и неудобно, чтобы в таком духе писать программы полностью, но в низкоуровневом коде встречается (в реализации массивов, хэш-таблиц, потоков I/O).
+1
ГА>Весь ввод/вывод в ML является императивным. В стандарте языка есть библиотека функционального ввода-вывода, но реализации ее я не видел (ни в Moscow ML, ни в SML/NJ).
Все общение с железом императивно.
ГА>Кроме того, в базовых библиотеках как SML, так и OCaml есть массивы и хэш-таблицы — mutable структуры данных.
Но они передаются но не хранятся. Все что нельзя редуцировать ГА>Ну и т.д., reference cells — это и есть, собственно, "состояние внутри функции".
Согласен.
ГА>Поэтому с одной стороны, языки семейства ML более легки в освоении для программистов-императивщиков и считаются более практичными
Вот это абсолютно точно. Не знаю про программаистов имеративщиков, но строгость SML меня поразила. После пары подходов к CLISP мне хотелось повесится.
Здравствуйте, Cyberax, Вы писали:
C>Паскаль был абсолютным хитом в свое время — хороший, продуманый, простой C>язык. Он оказал влияние на кучу последующих языков, и до сих пор C>используется для обучения. Одно это тянет на премию Тьюринга
+1
C>Вот только потом у Вирта начались непонятки с Модулами и Оберонами — они C>фактически уже не добавляли ничего нового, по сравнению с уже C>существовавшими языками.
Вирта сильно недолюбливали за то что он был наиболее последовательным и рьяным критиком Паскаля. Он его считал промежуточным звеном для построения промышленного языка.
C>Вирт успешно пропустил распространение C>объектно-ориентированного,
Честно говоря он ничего не пропускал. Ты судишь по Паскалю. Просто он занялся компонентным программированием. И задолго до того как компонентное программирование стало промышленным. Просто человеку сложно понять что между требованиями к научным языкам и промышленными совершенно разные. И процесс внедрения тоже разный.
Здравствуйте, GlebZ, Вы писали:
ГА>>Весь ввод/вывод в ML является императивным. В стандарте языка есть библиотека функционального ввода-вывода, но реализации ее я не видел (ни в Moscow ML, ни в SML/NJ). GZ>Все общение с железом императивно.
Тут надо поосторожнее. Дело не в железе, т.к. можно докатиться до логики "раз все языки компилируются в ассемблер, они по сути императивны". Тут дело в мат. модели. В ML решили не усложнять: операции, изменяющие состояние, имеют тип unit, порядок выполнения инструкций гарантирован, но практически любая функция может иметь побочные эффекты (хотя естественно, их избегают без необходимости):
let add_with_side_effect x y =
let ret = x + y in
(print_int ret; ret)
(* вызов print_int никак не влияет на тип функции,
это по-прежнему int->int->int *)
Как быть в чисто функциональном языке? А особенно в ленивом, в котором порядок вычислений определяется компилятором и зависимостью по данным?
Очень грубо говоря, выход такой: любая функция с побочными эффектами считается функцией, которая вычисляет новое состояние мира из старого, т.е. из императивного кода
Где-то смутно ощущаю, что IO-монада и do-нотация в Хаскеле примерно это и делает, только с синтаксическим сахаром (просьба ногами не бить, с теорией категорий не знаком, с Хаскелем знаком по туториалам и паре самостоятельно выполненных "Hello cruel world" в Hugs, это мое интуитивное понимание на сегодняшний день. А т.к. Haskell is a language of choice for discriminating hackers, я с ним еще обязательно разберусь получше ).
ГА>>Кроме того, в базовых библиотеках как SML, так и OCaml есть массивы и хэш-таблицы — mutable структуры данных. GZ>Но они передаются но не хранятся. Все что нельзя редуцировать
Вот здесь не уверен, что понял тебя.
ГА>>Поэтому с одной стороны, языки семейства ML более легки в освоении для программистов-императивщиков и считаются более практичными GZ>Вот это абсолютно точно. Не знаю про программаистов имеративщиков, но строгость SML меня поразила. После пары подходов к CLISP мне хотелось повесится.
Надо, Федя, надо . Если интересуешься ФП, без SICP никуда, а там не обойтись без Лиспа (точнее, Scheme).
GlebZ wrote:
> C>Вот только потом у Вирта начались непонятки с Модулами и Оберонами — > они > C>фактически уже не добавляли ничего нового, по сравнению с уже > C>существовавшими языками. > Вирта сильно недолюбливали за то что он был наиболее последовательным > и рьяным критиком Паскаля. Он его считал промежуточным звеном для > построения промышленного языка.
И тем не менее, именно Паскаль (с небольшими добавлениями в виде
break/continue, типизированых констант и т.п.) стал промышленным языком.
Модулы и Оберон уже не имели даже близкого по масштабу влияния на индустрию.
> C>Вирт успешно пропустил распространение > C>объектно-ориентированного, > Честно говоря он ничего не пропускал. Ты судишь по Паскалю. Просто он > занялся компонентным программированием.И задолго до того как > компонентное программирование стало промышленным.
Промышленное КОП появилось с появлением VB. И фактически в области
визуального программирования и осталось. Влияния Вирта тут я уже не вижу
— скорее развитие логически шло от визуальных контролов на формах к их
представлению в виде отдельных пакетов.
Здравствуйте, Трурль, Вы писали:
R>>Вообще в чем проблема, квалифицированному программисту выучить любой язык, если очень нужно — полдня максимум
Т>Тут недавно на смех подняли человека, который утверждал что знает C++, попрограммировав на нем всего год. Т>Где же правда
Тут есть люди, которые понимают, о чем идет речь в топике Стагнация?
Здравствуйте, reductor, Вы писали:
R>Нет-нет, в случае IO Monad все совсем не так, все гораздо проще R>я чуть попозже напишу поподробнее почему ни состояния ни ввод-вывод не являются никакой проблемой в хаскеле вообще и в любом языке в принципе, поддерживает он императивный ввод вывод или нет. Сейчас времени нет — там немного длинно получится. R>Тема безумно интересная и важная.
Ждем-с с нетерпением.
Здравствуйте, reductor, Вы писали:
R>Правда и там и там. R>Человек, для которого С++ — первый или второй язык программирования в жизни действительно не будет знать его хорошо даже за год (особенно, если не будет стараться проникнуть в язык поглубже)...Ни один язык не является замкнутой системой — идеи и способы реализации кочуют туда-сюда и то, на понимание чего в случае первого знакомства требуется два месяца, человек эрудированный просто отметит про себя — ага, это как в языке x, а это как в x', но через механизм z из языка y
Все так, но для продуктивного программирования нужно еще и "руку набить", и о распространенных граблях знать, и не лезть поминутно в справку, а еще есть (стандартная) библиотека, которую изучать и изучать.
Потому переход с более сложного С++ на (вроде бы) более простые C# или Java — вовсе не минутное дело.
з.ы. Я очень надеюсь, что изучение Лиспа и Хаскелла откроет мне третий глаз, и с чакрами все станет в порядке, но новый язык за полдня — ИМХО, преувеличение.
Здравствуйте, eao197, Вы писали:
E>Никогда не поверю, что C++ можно выучить очень быстро и начать на нем грамотно программировать. Особенно с сегодняшним уклоном в шаблоны, метапрограммирование и expression templates...
Да легко. Видел достаточно много примеров. Достаточно хороший код но с достаточно узким кругом инструментов. Ну например метапрограммирования, за последние 13 лет я никогда не использовал. И вообще когда встречаюсь с ним(а встречался только на rsdn), пугаюсь.
Здравствуйте, GlebZ, Вы писали:
GZ>Во-вторых, Вирт с его страстью к упрощению здесь сыграл положительную роль. И я сомневаюсь что кто-то меня опровергнет.
+1
жаль, что позднее его страсть к упрощению пошла совсем не туда, куда надо
Здравствуйте, GlebZ, Вы писали:
GZ>Имеет право. Он Оберон-то лучше знает.
давай не будем начинать спор по новой, ок?
чтобы иметь право разбрасываться такими откровенно оскорбительными обвинениями, нужно иметь объяснения — "а почему, собственно?" и доказательства сего факта
ни того, ни другого у него нет
если уж прослеживать параллели, то Смоллток имеет куда больше права называться прародителем Явы. Но разработчики Смоллтока почему-то не жалуются про это на лекциях.
GZ>Где он такое говорил? Ссылку. Я слышал от него другие слова.
поищи — здесь было несколько тем с обсуждениями его лекций
возможно конечно, что переводчики или авторы топиков переврали — но подобные утверждения были в нескольких местах
GZ>Это я тоже не слышал в его исполнении.
там же
Д>>Потому что его синтаксис очень простой, и это одним махом решает все существующие проблемы программирования. GZ>Почти так была информация. Только откуда взялось все существующие проблемы?
откуда взялись проблемы, намного лучше пишет Брукс. но синтаксис здесь уж совершенно точно ни при чем
GZ>Ты сам своими словами пытаешься сделать из него идола.
я? это как?
Д>>4. Оберон никто не использует, потому что ему нигде не обучают. И вообще, все вокруг сговорились, чтобы вытеснить Оберон с рынка. Д>>и так далее, и тому подобное GZ>1. Вообще-то Оберон кое-где изучают.
значит, еще один камень в огород Вирта
GZ>2. Лично я ему такое высказывание прощу(хотя дословно оно было другое). Обидно человеку.
нужно не обижаться, а думать — что было сделано неправильно? Вместо того, чтобы делать очередной никому не нужный язык.
GZ>Но вот невежественными их назвать не могу.
то, что он говорит про ФЯ, по другому я назвать не могу
GZ>Не идолопоклончество. А уважение. Это разные вещи.
банить за любую критику в адрес какого-то человека — это просто уважение?
Здравствуйте, Cyberax, Вы писали:
C>И тем не менее, именно Паскаль (с небольшими добавлениями в виде C>break/continue, типизированых констант и т.п.) стал промышленным языком. C>Модулы и Оберон уже не имели даже близкого по масштабу влияния на индустрию.
+1
C>Промышленное КОП появилось с появлением VB.
Вопрос на засыпку, а ты можешь описать разницу между модульностью и компонентностью? Этот вопрос настолько узкий, что я подчас сам не понимаю этой разницы. C>И фактически в области C>визуального программирования и осталось.
Нет. В честь чего? COM объекты, которые безусловно компонентны не являются областью компонентного программирования. Так же как и на их основе DCOM. C>Влияния Вирта тут я уже не вижу C>- скорее развитие логически шло от визуальных контролов на формах к их C>представлению в виде отдельных пакетов.
Да нет. Тут как раз именно Вирт был впереди планеты всей. На вопрос является ли наш постылый Oberon компонентным языком, можно ответить что да, является. Правда в несколько интересном формате, но это факт.
Здравствуйте, Дарней, Вы писали:
E>>Давай определимся с критериями успешности.
Д>успешность — это востребованность продукта сообществом Д>ведь не для марсиан же он работал, верно?
Кажется, где-то проскакивала информация, что систему управления метрополитеном в какой-то европейской столице толи на Modula-2, толи на Oberon реализовали. Так что продукт востребован.
БелАЗы, например, ты крайне редко увидишь. И выпускается их мало. Но ведь это не означает, что они не востребованы.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
GZ>>Где он такое говорил? Ссылку. Я слышал от него другие слова. Д>поищи — здесь было несколько тем с обсуждениями его лекций Д>возможно конечно, что переводчики или авторы топиков переврали — но подобные утверждения были в нескольких местах
Нет, переводчики его перевели правильно. И что самое интересное, я там был. Тот топик сразу был понятно что уйдет в бессмысленный флейм, поэтому его и не читал(уже давно можно прогнозировать что происходит на rsdn при слове Вирт, да вот сейчас вляпался). На rsdn началась своя интерпретация его слов. Не буду это сейчас обсуждать и переубеждать, можно взять данный тезис как субъективный.
GZ>>Это я тоже не слышал в его исполнении. Д>там же
Нет. Вообще-то он сказал, что функциональные языки это некоторые языки построенные на том что компиляторы умеют оптимизировать функции(дословно не помню). И высказал что не видит смысла в промышленном применении этих языков. И вообще он высказал достаточно много мнений о которых я сказал бы что они весьма и весьма спорные. Но у человека может быть мнение. С ним можно соглашаться или несоглашаться, но если у человека нет мнения, то такой человек не смог бы стать Виртом.
Д>>>Потому что его синтаксис очень простой, и это одним махом решает все существующие проблемы программирования. GZ>>Почти так была информация. Только откуда взялось все существующие проблемы? Д>откуда взялись проблемы, намного лучше пишет Брукс. но синтаксис здесь уж совершенно точно ни при чем GZ>>Ты сам своими словами пытаешься сделать из него идола. Д>я? это как?
Смотри выделенное. Это примерно означает что человек высказавший его является супербогом. Это твои слова. Вирт так не выглядит, и такого не говорил.
GZ>>2. Лично я ему такое высказывание прощу(хотя дословно оно было другое). Обидно человеку. Д>нужно не обижаться, а думать — что было сделано неправильно? Вместо того, чтобы делать очередной никому не нужный язык.
Ну насчет никому не нужного я бы не сказал. Какая разница между промышленным и научным языком. Для первого важен маркетинг и большое кол-во условий чтобы сказать что он успешен. Для второго нужна некоторая функциональность которую можно обсуждать. Судя по тому, сколько клав стерто на rsdn по поводу Oberon, с научной точки зрения — язык успешный. Наличие группы фанатов, также говорит об этом.
Что касается неправильно, то здесь более сложный вопрос. Промышленным язык просто так не станет.
GZ>>Но вот невежественными их назвать не могу. Д>то, что он говорит про ФЯ, по другому я назвать не могу
То что он сказал о компиляторах, верно. То что он сказал о применении, не знаю. Обсуждать не хочу. Но это его мнение. В первом случае вполне профессиональное, во втором случае, вполне абстрактное. Это не повод называть его невежественным.
GZ>>Не идолопоклончество. А уважение. Это разные вещи. Д>банить за любую критику в адрес какого-то человека — это просто уважение?
Банить за любую критику в адрес какого-то человека — это есть правило rsdn. А вот за критику высказываний и действий, никто банить не будет. Разницу чувствуешь между "невежественный человек", и "неправильное мнение(высказывание)"?
Здравствуйте, GlebZ, Вы писали:
GZ>Нет. Вообще-то он сказал, что функциональные языки это некоторые языки построенные на том что компиляторы умеют оптимизировать функции(дословно не помню). И высказал что не видит смысла в промышленном применении этих языков. И вообще он высказал достаточно много мнений о которых я сказал бы что они весьма и весьма спорные. Но у человека может быть мнение. С ним можно соглашаться или несоглашаться, но если у человека нет мнения, то такой человек не смог бы стать Виртом.
Назвал Пролог функциональным языком — явный промах.
В одной из веток автор писал, что у Вирта поинтересовались его мнением о ФЯ
на что он ответил, что ФЯ — это те же самые императивные языки, из которых удалили процедуры и оставили только функции. За точность слов не ручаюсь, но смысл был такой.
еще там была ссылка на блог (кажется, у СГ), где были собраны еще некоторые материалы
там в частности было высказывание, что функции высшего порядка применяются крайне редко и в принципе не очень то нужны
про такие вещи как лямбда, макросы и т.п. — вообще ни слова, хотя это как раз одни из самых сильных сторон ФЯ
GZ>Смотри выделенное. Это примерно означает что человек высказавший его является супербогом. Это твои слова. Вирт так не выглядит, и такого не говорил.
разве он не говорил, что оберон должен решить многие проблемы программирования?
GZ>Ну насчет никому не нужного я бы не сказал. Какая разница между промышленным и научным языком. Для первого важен маркетинг и большое кол-во условий чтобы сказать что он успешен. Для второго нужна некоторая функциональность которую можно обсуждать. Судя по тому, сколько клав стерто на rsdn по поводу Oberon, с научной точки зрения — язык успешный. Наличие группы фанатов, также говорит об этом. GZ>Что касается неправильно, то здесь более сложный вопрос. Промышленным язык просто так не станет.
боюсь, что с научной точки зрения оберон — пустое место
абсолютно ничего нового и интересного там нет
GZ>Банить за любую критику в адрес какого-то человека — это есть правило rsdn. А вот за критику высказываний и действий, никто банить не будет. Разницу чувствуешь между "невежественный человек", и "неправильное мнение(высказывание)"?
Здравствуйте, Дарней, Вы писали:
Д>Назвал Пролог функциональным языком — явный промах.
Честно говоря видел где то флеймы по поводу является ли пролог функциональным языком или нет. Они были потише чем флеймы является ли Smalltalk функциональным, но все таки были. Я тут как-то познакомился с Refal, и как то граница между логическим и функциональным программированием у меня начала улетучиваться.
Д>В одной из веток автор писал, что у Вирта поинтересовались его мнением о ФЯ Д>на что он ответил, что ФЯ — это те же самые императивные языки, из которых удалили процедуры и оставили только функции. За точность слов не ручаюсь, но смысл был такой.
Да было такое. Признаю. Д>еще там была ссылка на блог (кажется, у СГ), где были собраны еще некоторые материалы Д>там в частности было высказывание, что функции высшего порядка применяются крайне редко и в принципе не очень то нужны
И что, это неправда? Для императивных это так. Д>про такие вещи как лямбда, макросы и т.п. — вообще ни слова, хотя это как раз одни из самых сильных сторон ФЯ
А он и не пояснял функциональные языки. Похоже у него стойкое неприятие к ним.
GZ>>Смотри выделенное. Это примерно означает что человек высказавший его является супербогом. Это твои слова. Вирт так не выглядит, и такого не говорил. Д>разве он не говорил, что оберон должен решить многие проблемы программирования?
Многие и все, несколько разные вещи. Об этом я намекал. Если бы в далеком 85 году все пересели бы на Oberon, мир был бы другим. Правда 20 лет — это срок.
GZ>>Ну насчет никому не нужного я бы не сказал. Какая разница между промышленным и научным языком. Для первого важен маркетинг и большое кол-во условий чтобы сказать что он успешен. Для второго нужна некоторая функциональность которую можно обсуждать. Судя по тому, сколько клав стерто на rsdn по поводу Oberon, с научной точки зрения — язык успешный. Наличие группы фанатов, также говорит об этом. GZ>>Что касается неправильно, то здесь более сложный вопрос. Промышленным язык просто так не станет. Д>боюсь, что с научной точки зрения оберон — пустое место Д>абсолютно ничего нового и интересного там нет
Для 85 года? Я так не думаю. Но сейчас я также не очень хорошо понимаю место оберона. Технологии обогнали его. Zoonon — вообще непонятное чудо. Если Оберон мне не понравился(в нынешних то летах) то от Zoonon вообще стало плохо.
Но честно говоря, очень жалко что во времена когда я только начинал, я о нем не знал.
Прочитал сегодняшние посты.
Главное, что хочу сказать: имхо, RSDN прошел тест на зрелость.
Мой респект всем участникам, независимо от того, симпатизируют они Вирту, или напротив — терпеть его не могут.
Довавлю пару слов от себя.
Данила-мастер (Вирт) все-таки сделал каменный цветок (Оберон).
Но кто помнит сказы Бажова, знает, что там все не так просто.
Меня еще в детстве поразила красота и печаль этой истории.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, eao197, Вы писали:
E>Никогда не поверю, что C++ можно выучить очень быстро и начать на нем грамотно программировать. Особенно с сегодняшним уклоном в шаблоны, метапрограммирование и expression templates...
Если вы считаете, что человек, знающий Common Lisp, Smalltalk и ML найдет для себя что-то новое и неизвестное в C++, то мне придется вас разочаровать. Не найдет.
Система типов — слабое подобие той, что в ML
Шаблоны в C++ — это частично (со стороны типов) — реализация параметрического полиморфизма из того же ML, частично (со стороны мета-) — 1/20 (если не меньше) возможностей того, что могут дать макросы в Common Lisp.
Весь STL — это неуклюжая попытка скопировать стандартную библиотеку Common Lisp, причем Степанов даже и не пытается это отрицать.
С классами, полагаю, и так все понятно.
Самая новая и оригинальная идея в С++ имеет не менее чем двадцатилетнюю историю в других языках.
E>Я и сам "13 Years of C++ and still learning"
Я вас правильно понимаю, что вы не знаете ни одного из вышеназванных языков?
ГА>Все так, но для продуктивного программирования нужно еще и "руку набить", и о распространенных граблях знать, и не лезть поминутно в справку, а еще есть (стандартная) библиотека, которую изучать и изучать.
Для этого придется найти язык с по-настоящему уникальной стандартной библиотекой
Насколько могу судить я, таким положением дел не может похвастаться даже Haskell.
ГА>Потому переход с более сложного С++ на (вроде бы) более простые C# или Java — вовсе не минутное дело.
на C# я до того не знал вообще(один раз мельков видел описание новшеств в 3.0) и не написал на нем ни одной строчки. Яву и еще несколько языков правда знал.
А все, что меня связывает с .NET — это просмотр спецификация на F# и SML.NET и написание на них для теста hello, world
тут я предложил вариант: http://www.rsdn.ru/Forum/Message.aspx?mid=1508248&only=1
На все про все мне потребовалось около двух часов. С синтаксисом все понятно. Сомнений, что там можно сделать константную проверку в switch вместо динамики с кучей if у меня не было никаких, посмотрел на определение switch в MSDN, полазил по библиотеке, нашел константы для типовых значений и нужные методы и все. Можно было бы сделать посимпатичнее через подобие continuations или иксепшены (не так конечно как в другом там варианте), но мне было лень дальше разбираться.
ГА>з.ы. Я очень надеюсь, что изучение Лиспа и Хаскелла откроет мне третий глаз, и с чакрами все станет в порядке, но новый язык за полдня — ИМХО, преувеличение.
Да ничего такого сложного — чем больше их учишь, тем проще.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
E>>>Я и сам "13 Years of C++ and still learning"
R>>Я вас правильно понимаю, что вы не знаете ни одного из вышеназванных языков?
E>Правильно.
E>И знаешь что? Мне совершенно не стыдно. Всего знать не возможно.
Я и не предлагал, чтобы было стыдно. Речь шла совсем о другом.
Кому-то нравится учить много языков, кого-то вообще от программирования тошнит.
E>Знать что-то про язык, знать стандарт языка, знать что-то про его библиотеки, но в теории -- это одно. E>Применять язык на практике -- совершенно другое.
Конечно. Только это другое в какой-то момент сжимается в невидимую глазу точку. Просто языков программирования на самом деле намного меньше, чем принято считать. Потому и порой открывая документацию на незнакомый язык обнаруживаешь, что ты его уже знаешь. От и до.
E>Мало знать про такие вещи, как RAII или сильную гарантию безопасности исключений. Мало знать про то, как это работает. Нужно уметь это применять. Постоянно, целенаправлено и последовательно. Могу тебя уверить -- далеко не у всех это получается. И я не исключение, удачный код у меня выходит не так часто как хотелось бы. Поэтому и говорю, что все еще изучаю C++.
Нет никакого желания спорить. Знать как работает — нужно
E>Поскольку рассказ про монады в функциональных языках -- это только одна грань такой обширной вещи, как программирование. А другая грань -- это, например, СУБД. И какая бы теория за какой-нибудь СУБД не стояла, без качественной реализации такая СУБД -- это так, поделка. А для качественной реализации нужно много разных качеств у разработчика. Среди которых эрудиция, имхо, далеко не на первом месте.
Ну Джеф Ульман конечно про СУБД и эрудицию бы здесь поспорил. Просто своим существованием . Я не смогу так конечно.
Скажу, что монады мне не мешают разбираться в СУБД на достаточном для удовлетворения моего интереса уровне.
Здравствуйте, eao197, Вы писали:
E>Кажется, где-то проскакивала информация, что систему управления метрополитеном в какой-то европейской столице толи на Modula-2, толи на Oberon реализовали. Так что продукт востребован.
E>БелАЗы, например, ты крайне редко увидишь. И выпускается их мало. Но ведь это не означает, что они не востребованы.
я очень сильно сомневаюсь, что оберон задумывался как нишевой язык изначально
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> C>Хороший программист о них, конечно, должен знать, но это скорее просто >> C>background knowledge (как мат.анализ или алгебра). >> Да ладно. Конечно не должен! >> Хороший программист — это когда в слюнявчике, утка, детское питание по >> катетеру, мышь без колеса и клавиатура с одной кнопкой — для вызова >> сиделки с проджект менеджером.
C>А если серьезно, где теория необходима прикладному программисту? C>Например, я не помню, чтобы мне где-то понадобилось использовать C>алгоритмы быстрой факторизации чисел или доказывать правильность алгоритма.
Не знаю, по-моему везде.
Например, чтобы понимать нерешаемость какой-то задачи.
Или чтобы понимать какой аппарат или алгоритм для какой задачи больше подходит.
По-моему, пример с Rubin и Dijkstra это очень красиво показывает.
И я как-то более чем за, что описанные необязательные требования для программиста в MIT или CMU обязательны на первом курсе.
Да мало ли какая задача попадется. Что вообще такое программист в конечном итоге?
C>Полезного из теории могу вспомнить O-нотацию для оценки скорости, но я C>до нее еще в школе сам додумался Я даже трехмерной графикой вполне C>успешно занимался без знаний подробностей работы алгоритма триангуляции C>Делоне или критериев оптимальности разбиения.
Да все мы занимались чем-то для чего потом выясняли, что существует название.
Но по-моему заранее знать это название несколько удобнее.
C>Бывают задачи (типа цифровой обработки сигналов, например), где без C>теории — никуда. Но это уже исключения, подтверждающие правило.
Что-то мне не кажется, что DSP такое уж исключение в плане требовательности к теоретической подготовке.
К тому же основы тех же сигналов ни одному программисту и просто так не повредят. Для общей эрудиции.
Здравствуйте, reductor, Вы писали:
R>Я и не предлагал, чтобы было стыдно. Речь шла совсем о другом. R>Кому-то нравится учить много языков, кого-то вообще от программирования тошнит.
А я не о том, нравится или нет.
Я о том, что знания, например, Java совершенно не помогают при программировании на C++. Скорее наоборот.
Точно так же, как сравнивать приемы программирования на Ruby или C++.
Ну, например, какие грабли зарыты в следующем C++ коде:
E>>Знать что-то про язык, знать стандарт языка, знать что-то про его библиотеки, но в теории -- это одно. E>>Применять язык на практике -- совершенно другое.
R>Конечно. Только это другое в какой-то момент сжимается в невидимую глазу точку. Просто языков программирования на самом деле намного меньше, чем принято считать. Потому и порой открывая документацию на незнакомый язык обнаруживаешь, что ты его уже знаешь. От и до.
На счет "от и до" -- не верю.
E>>Поскольку рассказ про монады в функциональных языках -- это только одна грань такой обширной вещи, как программирование. А другая грань -- это, например, СУБД. И какая бы теория за какой-нибудь СУБД не стояла, без качественной реализации такая СУБД -- это так, поделка. А для качественной реализации нужно много разных качеств у разработчика. Среди которых эрудиция, имхо, далеко не на первом месте.
R>Ну Джеф Ульман конечно про СУБД и эрудицию бы здесь поспорил. Просто своим существованием . Я не смогу так конечно.
А что Джеф Ульман был спецом по ленивым вычислениями или функциональным языкам?
R>Скажу, что монады мне не мешают разбираться в СУБД на достаточном для удовлетворения моего интереса уровне.
Помогут ли они тебе при реализации, например, подсистемы кэширования таблиц РСУБД на языке C. При условии, что подсистема должна быть портабельна на Solaris, HP-UX, AIX, Linux, *BSD и Win32 (Win2k, XP, 2003)?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Я о том, что знания, например, Java совершенно не помогают при программировании на C++. Скорее наоборот.
Видимо, вы много времени потратили на изучение этого вопроса. По вашему знание или незнание Java в то время, когда кроме нее знаешь еще языков 20 как-то может повлиять при программировании на С++? Ну если может, так только положительно. Потому что общего в них больше, чем различий. Несмотря на все различия.
E>Точно так же, как сравнивать приемы программирования на Ruby или C++. E>Ну, например, какие грабли зарыты в следующем C++ коде:
Вы мне экзамен решили устроить?
Причем, что характерно экзамен на терпение. Оно не константно.
E>На счет "от и до" -- не верю.
Ваше право. Но кстати я даже не пытался вас убедить. Всего лишь делился опытом. Причем, не по своей, замечу, инициативе.
R>>Ну Джеф Ульман конечно про СУБД и эрудицию бы здесь поспорил. Просто своим существованием . Я не смогу так конечно.
E>А что Джеф Ульман был спецом по ленивым вычислениями или функциональным языкам?
Ну во-первых он не был, он есть. Во-вторых, Джеф Ульман, как и любой, действительно великий человек, талантлив во всем и неисчерпаем как электрон. Сложнее сказать по чему он не_специалист.
В-третьих, представьте себе и по функциональным языкам тоже: http://www.amazon.com/gp/product/0137903871/qid=1133421564/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/102-6365212-3711324?n=507846&s=books&v=glance http://www-db.stanford.edu/~ullman/emlp.html
R>>Скажу, что монады мне не мешают разбираться в СУБД на достаточном для удовлетворения моего интереса уровне.
E>Помогут ли они тебе при реализации, например, подсистемы кэширования таблиц РСУБД на языке C. При условии, что подсистема должна быть портабельна на Solaris, HP-UX, AIX, Linux, *BSD и Win32 (Win2k, XP, 2003)?
Однозначно, особенно кеширования
Кстати, можно и MacOS туда вписать. Я всегда все на нее портирую тоже.
Вообще интересно, что вас заставляет _спорить_ с _моим_ опытом каким бы он ни был?
Здравствуйте, Mamut, Вы писали:
E>>>Видишь ли, к научному миру я отношения не имею. А когда пытался иметь это отношение, то у меня остались не самые хорошие воспоминания об этом деле. В частности о системе оценки работы по количеству публикаций.
R>>По количеству ссылок на публикации. Впрочем, количество работ у вирта тоже не фонтан.
M>Прохоже сейчас в универе Science, Technology and Society. Так вот, количество ссылок на публикации является удобным, но очень неточным критерием оценки вклада того или иного ученого в науку.
Конечно неточным. Что вообще может быть точным в таком вопросе.
Но у вас есть точнее?
Ну и конечно лично для меня это не самый первостепенный критерий. Просто кидать ссылки на чьи-то работы и просить оценить — будет смешно.
Тем более непонятно как кому-то объяснить, что тот же Вирт — вовсе не ученый, а преподаватель и популяризатор.
Здравствуйте, Игoрь, Вы писали:
И>Здравствуйте, minorlogic, Вы писали:
M>>Так вот в том то и дело что метку можно назвать хорошо а МОЖНО ПЛОХО , а return не допускает вольной интерпретации, логика его работы прозрачна. И>Ну и что из этого следует? Я же выше сказал, что и функцию МОЖНО ПЛОХО назвать, но главное что можно и хорошо. И>По-моему тема с goto высосона из пальца. Просто не стоит ими злоупотреблять вот и все. А прогу запутать легко и без явных меток, что многие успешно делают.
Собственно тут логически течет такое рассуждение. Если переходы "goto" настолько же удобны как и return к примеру , тогда зачем загромождать язык такими конструкциями как
for
if
case
while
и т.д.
А зачем ? ведь все можно построить на goto.
А вот зачем , чтобы ЯВНО выделить лгические конструкции языковыми примитивами , в том числе и return служит для этой цели.
Это делается для удобства ЧТЕНИЯ и ПОНИМАНИЯ исходников. Залдача языка в этом вопросе , помочь передавать смысл написанного не позволяя неточные трактовки.
M>>Прохоже сейчас в универе Science, Technology and Society. Так вот, количество ссылок на публикации является удобным, но очень неточным критерием оценки вклада того или иного ученого в науку.
R>Конечно неточным. Что вообще может быть точным в таком вопросе. R>Но у вас есть точнее?
Посмотрю дома Может и нет на самом деле
R>Ну и конечно лично для меня это не самый первостепенный критерий. Просто кидать ссылки на чьи-то работы и просить оценить — будет смешно. R>Тем более непонятно как кому-то объяснить, что тот же Вирт — вовсе не ученый, а преподаватель и популяризатор.
Эээ нет, не дождетесь. В спор про Вирта лезть не буду
eao197 wrote:
> Д>успешность — это востребованность продукта сообществом > Д>ведь не для марсиан же он работал, верно? > Кажется, где-то проскакивала информация, что систему управления > метрополитеном в какой-то европейской столице толи на Modula-2, толи > на Oberon реализовали. Так что продукт востребован.
Наверное имелось в виду парижское метро — там ее реализовали сначала на
Модула-2, а потом переписали на Аде (попутно доказывая правильность).
reductor wrote:
> Если вы считаете, что человек, знающий Common Lisp, Smalltalk и ML > найдет для себя что-то новое и неизвестное в C++, то мне придется вас > разочаровать. Не найдет.
Плохо ищет значит.
> Самая новая и оригинальная идея в С++ имеет не менее чем > двадцатилетнюю историю в других языках.
1) State-of-art система ручного управления памятью. Назовите мне
язык, где управлять распределением/уничтожением памяти можно так же
гибко и удобно как в С++.
2) Взаимодействие с кодом на С. Где у нас еще есть extern "C"?
3) Реально используется в промышленности.
> E>Я и сам "13 Years of C++ and still learning" > Я вас правильно понимаю, что вы не знаете ни одного из вышеназванных > языков?
Я писал на OCaml'е и немного на Haskell'е, например. Неплохо, но далеко
не самая лучшая вещь с начала времен.
Здравствуйте, GlebZ, Вы писали:
C>>Any if-statement is a goto. As are all structured loops. GZ>Подмена понятия языка высокого уровня ассемблером до хорошего не доводят.
Игнорирование факта, что из ЯВУ-программы в конце концов получаются машинные команды, приводит к тому же. А уж если софт имеет прямое и непосредственное отношение к железу (чем Линус занимается, напоминать надо?), то и более того.
Ну, и пара слов в защиту goto (раз уж на него нападают):
Есть такая программа re2c. она генерирует распознаватели регулярных выражений в C-код.
Там есть несколько вариантов генерации. (1)используя goto (2)используя if-ы (3)используя таблицу состояний. Почему-то, самый быстрый код получается в варианте (1)...
И, в качестве флэймбайта: Простая и бесхитросная реализация бинарного алгоритма возведения в степень больших чисел. С использованием GOTO. Я не говорю, что это единственный вариант реализации этого алгоритма, но в данном случае goto спасает (а)от достаточно неприятного дублирования кода,
(б) ничуть не вредит ясности текста.
//rn = (an ** en) mod mn
umodexp(data* rn, data const* an, data const* en, data const* mn)
{
data *n1 = rn; n1->copy(an);
data *n2 = data::alloc(rn->capacity);//пусть этот меморилик вас не смущает
//код немного упрощен для наглядности
data::byte_type const* ep = en->data + en->size - 1;
data::byte_type mask = 1 << (data::bits-1);
while( 0 == (*ep & mask) )
mask >>= 1;//skip to first '1' bit
reduction_algo reduce(mn);
goto start;for(;;) {
umul(n1, n2, n2);
reduce(n2, n1);
if( *ep & mask ) {
umul(n1, n2, an);
start: reduce(n2, n1);
}
if( 0 == (mask >>= 1) ) {
if( --ep < en->data_ ) break;
mask = 1 << (data::bits-1);
}
}
rn->copy(n2);
}
Посему, вопрос: должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, GlebZ, Вы писали:
Д>>>там в частности было высказывание, что функции высшего порядка применяются крайне редко и в принципе не очень то нужны GZ>>И что, это неправда? Для императивных это так.
Д>как насчет С++/STL?
И что? Эмуляция функций высших порядков с помощью объектов, которое еще к тому-же достаточно редко применяется. Потому как во многом не очень удобно писать на каждый чих свой объект. Во-вторых, в функциональных языках более продвинутое понятие функции высшего порядка.
Ну например в SML:
- fun times (x:int) (y:int) = x*y;
- val twice = times 2;
- twice 4;
>8
- times 3 4;
>12
То есть, легко и без выпендрежей получили на основе ф-ции times получили функцию twice.
Здравствуйте, 0xDEADBEEF, Вы писали:
C>>>Any if-statement is a goto. As are all structured loops. GZ>>Подмена понятия языка высокого уровня ассемблером до хорошего не доводят. DEA>Игнорирование факта, что из ЯВУ-программы в конце концов получаются машинные команды, приводит к тому же. А уж если софт имеет прямое и непосредственное отношение к железу (чем Линус занимается, напоминать надо?), то и более того.
Поэтому на Java и не пишут такие вещи. Чем ниже язык, тем лучше он адаптирует железо. Но это к вопросу дела не имеет.
DEA>Ну, и пара слов в защиту goto (раз уж на него нападают): DEA>Есть такая программа re2c. она генерирует распознаватели регулярных выражений в C-код. DEA>Там есть несколько вариантов генерации. (1)используя goto (2)используя if-ы (3)используя таблицу состояний. Почему-то, самый быстрый код получается в варианте (1)...
DEA>И, в качестве флэймбайта: Простая и бесхитросная реализация бинарного алгоритма возведения в степень больших чисел. С использованием GOTO. Я не говорю, что это единственный вариант реализации этого алгоритма, но в данном случае goto спасает (а)от достаточно неприятного дублирования кода, DEA>(б) ничуть не вредит ясности текста. DEA>
DEA>//rn = (an ** en) mod mn
DEA>umodexp(data* rn, data const* an, data const* en, data const* mn)
DEA>{
DEA> data *n1 = rn; n1->copy(an);
DEA> data *n2 = data::alloc(rn->capacity);//пусть этот меморилик вас не смущает
DEA> //код немного упрощен для наглядности
DEA> data::byte_type const* ep = en->data + en->size - 1;
DEA> data::byte_type mask = 1 << (data::bits-1);
DEA> while( 0 == (*ep & mask) )
DEA> mask >>= 1;//skip to first '1' bit
DEA> reduction_algo reduce(mn);
DEA> goto start;
DEA> for(;;) {
DEA> umul(n1, n2, n2);
DEA> reduce(n2, n1);
DEA> if( *ep & mask ) {
DEA> umul(n1, n2, an);
DEA> start: reduce(n2, n1);
DEA> }
DEA> if( 0 == (mask >>= 1) ) {
DEA> if( --ep < en->data_ ) break;
DEA> mask = 1 << (data::bits-1);
DEA> }
DEA> }
rn->>copy(n2);
DEA>}
DEA>
DEA>Посему, вопрос: должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет.
Жуть... Минут пять смотрел как на икону, так и не понял как это работает. И тут у нас может быть две ситуации:данный код должен быть читабельным, и его нужно переписать с введением дополнительных функций. Или этот код должен выполняться с максимальной скоростью выполнения, тогда идет игра без правил.
Здравствуйте, GlebZ, Вы писали:
GZ>И что? Эмуляция функций высших порядков с помощью объектов, которое еще к тому-же достаточно редко применяется. Потому как во многом не очень удобно писать на каждый чих свой объект.
писать объект совсем необязательно, можно использовать вместо этого указатель на функцию
и еще есть boost::lambda
хотя это конечно не очень удобно, но всё-таки есть и вполне применяется
Но, если не только искать, а еще и читать, то по первой ссылке можно найти следующее
Most programming languages are equivalent to the lambda calculus extended with some additional programming language constructs. The classical work where this viewpoint was put forward was Peter Landin's "A Correspondence between ALGOL 60 and Church's Lambda-notation", published in CACM in 1965.
А по второй:
Common Lisp is a multi-paradigm programming language that:
— Supports programming techniques such as imperative, functional and object-oriented programming.
Здравствуйте, Трурль, Вы писали:
Т>Можно еще погуглить на тему Macros+assembler .
только макросы там абсолютно другие. Ты бы еще про макросы в Ворде вспомнил.
Т>Но, если не только искать, а еще и читать, то по первой ссылке можно найти следующее Т>
Most programming languages are equivalent to the lambda calculus extended with some additional programming language constructs. The classical work where this viewpoint was put forward was Peter Landin's "A Correspondence between ALGOL 60 and Church's Lambda-notation", published in CACM in 1965.
там есть еще такое понятие, как лямбда-функции и некоторые интересные возможности, которые они дают
впрочем, заниматься просветительством я не собираюсь. так что до свидания как-нибудь в другой раз.
Т>- Supports programming techniques such as imperative, functional and object-oriented programming.
тем лучше для Лиспа, что он поддерживает другие парадигмы, кроме своей "родной". В отличие от Оберона, например.
Здравствуйте, Дарней, Вы писали:
Д>писать объект совсем необязательно, можно использовать вместо этого указатель на функцию
Фи. Это моветон. Просто иногда не бывает другого выхода для реализации callback. Д>и еще есть boost::lambda Д>хотя это конечно не очень удобно, но всё-таки есть и вполне применяется
В том то и дело, что boost не так уж часто применяется. Знаниями о boost, а больше умением им пользоваться, обладают не такое уж большое количество программистов. Поэтому в коммерч. разработках его опасаются использовать. Да и в большинстве случаев можно обойтись и без него. У дизайна ООП другие законы. Поэтому в смысле C++ это утверждение неверно.
В смысле C#, как бы практики больше, но до функциональных языков недотягивают. Во первых, и удобной лямбды пока нет. Во-вторых, также существуют аналоги в паттернах проектирования, поэтому данная функциональность выделенно не часто требуется. В-третьих, пример показаный на SML так же просто не сделаешь. Вобщем функциональность есть, иногда помогает, но не используется на полную мощь поскольку идеалогия у императива другая. По большому счету полновесная функциональность таких функций для императива чужеродна. А в функциональных языках, просто выхода нет как не использовать подобные функции.
GlebZ,
> В том то и дело, что boost не так уж часто применяется. Знаниями о boost, а больше умением им пользоваться, обладают не такое уж большое количество программистов. Поэтому в коммерч. разработках его опасаются использовать.
Кто именно опасается? Ссылки уже давались. Это не полный перечень, а просто список заметных компаний, кто захотел поддержать инициативу. Например, из заметных публично, в Civilization IV используется по крайней мере Boost.Python, и их в списке нет.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Кто именно опасается? Ссылки уже давались. Это не полный перечень, а просто список заметных компаний, кто захотел поддержать инициативу. Например, из заметных публично, в Civilization IV используется по крайней мере Boost.Python, и их в списке нет.
Во первых, не хотел бы я смотреть список всех команд которые используют С++. Трафик не резиновый.
Во-вторых, я вполне понимаю когда люди говорят что они используют STL. Потому как они могут использовать различные части библиотеки. Boost настолько разнороден, что я немного не понимаю что значит использовать Boost. Наверняка будут использоваться только некоторые компоненты. Поэтому использование lambda на порядки меньше чем заявлений об использовании boost.(и в принципе это хорошо прослеживается по твоему списку).
В третьих, мне приходится встречаться с различными командами. Из встреченного, я не слышал чтобы использовали boost. Почему-то пишут в основном либо свои лесипеды, либо у них таких задач и не ставится. Или используют другие библиотеки, особенно это касается Spirit.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Поэтому использование lambda на порядки меньше чем заявлений об использовании boost. ПК>Ты говорил о боязни использования boost вообще.
1 и 3 заметка именно об этом. Вторая — контекст предыдущего разговора.
Здравствуйте, z00n, Вы писали:
Z>Т.е. мы просто преобразуем список в дерево. Абстракции тут просты и понятны. Синтаксис С++ темплэйтов ужасен. Z>Если начинать знакомиться с абстракциями типа filter, map, fold etc. по Александреску и Абрахамсу-Гуртовому (или даже по STL), то, для начинающего, синтаксис затмит все. Не говоря уже о том, что посмотреть на результат темплейтного метапрограмирования глазами мы можем, лишь скомпилировав файл с ключом -D, а потом еще и отформатировав вывод. Зная абстракции, пользоваться инструментами — просто.
Маленькое замечание. Может сложиться впечатление, что Абрахамс и Гуртовой — жрецы-злодеи, скрывающие от общественности тайну своей магии , но на самом деле они ссылаются на классиков (Paul Hudak) практически с первой страницы: http://boost.org/libs/mpl/doc/tutorial/higher-order.html
Я, собственно, так и заразился ФП, после туториала MPL.
А синтаксис, понятное дело, читаем слабо, т.к. не предназначен для метапрограммирования.
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Маленькое замечание. Может сложиться впечатление, что Абрахамс и Гуртовой — жрецы-злодеи, скрывающие от общественности тайну своей магии , но на самом деле они ссылаются на классиков (Paul Hudak) практически с первой страницы: ГА>http://boost.org/libs/mpl/doc/tutorial/higher-order.html
Я ничего такого не имел в виду.
ГА>Я, собственно, так и заразился ФП, после туториала MPL.
А я пошел читать SICP после 6-ой главы их книги (Algorithms)
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Игoрь, Вы писали:
И>>Здравствуйте, minorlogic, Вы писали:
M>>>Так вот в том то и дело что метку можно назвать хорошо а МОЖНО ПЛОХО , а return не допускает вольной интерпретации, логика его работы прозрачна. И>>Ну и что из этого следует? Я же выше сказал, что и функцию МОЖНО ПЛОХО назвать, но главное что можно и хорошо. И>>По-моему тема с goto высосона из пальца. Просто не стоит ими злоупотреблять вот и все. А прогу запутать легко и без явных меток, что многие успешно делают.
M>Собственно тут логически течет такое рассуждение. Если переходы "goto" настолько же удобны как и return к примеру , тогда зачем загромождать язык такими конструкциями как
M>for M>if M>case M>while M>и т.д.
M>А зачем ? ведь все можно построить на goto.
И что ты мне пытаешься доказать? Я разве где-то говорил о том, что я против структурного программирования? Я говорил только о том, что возможны ситуации, когда применение явного goto оправдано. Вообще тема настолько заезжена, что у меня нет особого желания спорить. Если ты считаешь, что метки — это абсолютное зло, то я не смогу тебя переубедить. У Кнута есть статья на эту тему Structured Programming with go to Statements.
Здравствуйте, dshe, Вы писали:
D>Здравствуйте, Игoрь, Вы писали:
И>>Здравствуйте, minorlogic, Вы писали:
M>>>Так вот в том то и дело что метку можно назвать хорошо а МОЖНО ПЛОХО , а return не допускает вольной интерпретации, логика его работы прозрачна. И>>Ну и что из этого следует? Я же выше сказал, что и функцию МОЖНО ПЛОХО назвать, но главное что можно и хорошо.
D>Метки для goto гораздо сложнее назвать хорошо. Наиболее часто используемые имена выглядят так: end_if, end_loop, exit, start_loop, else_branch. А с учетом того, что метки в определенной области видимости должны быть уникальны, приходится извращаться с добавлением суффиксов.
Большое кол-во меток наводит на мысль, что что-то в коде не так... больше двух меток мне точно не приходилось никогда использовать
D> Это также создает проблемы при переносе какого-то участка кода в другое место: часто приходится переименовывать метки, из-за чего могут вноситься ошибки.
Никто не говорит, что метки нужно использовать повсеместно. Если возникают такие проблемы, то видимо кто-то очень хорошо злоупотребил.
D>во-втором goto exit1; может действительно подразумевался выход из двух вложенных циклов, а может кто-то просто забыл (при переносе кода) exit1 заменить на exit2.
Там максиму нужна была одна метка, но я бы этот пример писал без меток
Кстати, по поводу именования меток... на одной из предыдущих работ у нас один товарищ под впечатлением от гоблиновского перевода "Властелина колец" выдал:
if (...)
if (...)
if (...)
goto mochi_kozlov;
...
...
mochi_kozlov:
// cleanup
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> Если вы считаете, что человек, знающий Common Lisp, Smalltalk и ML >> найдет для себя что-то новое и неизвестное в C++, то мне придется вас >> разочаровать. Не найдет.
C>Плохо ищет значит.
Нет, кто-то плохо показывает.
>> Самая новая и оригинальная идея в С++ имеет не менее чем >> двадцатилетнюю историю в других языках.
C>1) State-of-art система ручного управления памятью. Назовите мне C>язык, где управлять распределением/уничтожением памяти можно так же C>гибко и удобно как в С++.
Но хочется понять долго ли мемори менеджмент в С++ доходил до state-of-the-art, чтобы достигнуть достигать такого — язык, к которому даже GC нормальный не прицепишь. А то мне кажется, идея такого мемори менеджмента мягко говоря не нова.
C>2) Взаимодействие с кодом на С. Где у нас еще есть extern "C"?
Хм.
С/Objective-C/D/Cyclone ?
А вообще конечно это одна из самых важных и уникальных идей и языка С++, да..
Скажите, а
foreign export ccall в Хаскеле написать уже нет?
или там external в O'Caml
C>3) Реально используется в промышленности.
Очень новая языковая идея.
>> E>Я и сам "13 Years of C++ and still learning" >> Я вас правильно понимаю, что вы не знаете ни одного из вышеназванных >> языков?
C>Я писал на OCaml'е и немного на Haskell'е, например. Неплохо, но далеко C>не самая лучшая вещь с начала времен.
А расскажите какая лучшая?
Кстати еще интересно чем вам так мемори менеджмент в окамле и хаскеле не угодил. Правда.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, шапокляк, Вы писали:
Ш>>Я тут конешно новенькая и меня легко затоптать. Но сложите 2 и 2. Лауреаты премии Тьюринга люди не святые. Но коли с ними переходят на личности то уж никак не от большова ума. И што тут спорить? Ну а научный уровень Линуса Торвальдса можно даже не обсуждать. Хотя я не удивлюсь если его протолкнут в лауреаты Тьюринга. Такова жизнь. GZ>Честно говоря, я бы дал премию Страуступу. Можно долго мучится вопросом насчет недостатков и достоинств языка и научной ценности, но то что его детище кардинально повлиял на все сообщество на десятилетия — отрицать нельзя. Это влияние нельзя переоценить.
GZ>С уважением, Gleb.
Дадут дадут не сумлевайтесь. Вот нашла о нем на одном програмерском форуме:
Он-таки сейчас профессор в университете Texas A&M University плюс состоит в лаборатории Information and Systems Software Research Lab, что работает внутри AT&T Labs. Да еще в этом году получил приз за научные достижения -- William Procter Prize for Scientific Achievement.
А сейчас до сих пор в своих языках занимается (в C>основном) идеологией без нововведений. За это Вирта и не любят тут
Как я успела заметить Вирта тут не любят за другое — он и его слова вносят ненужный диссонанс (во какое словечко вспомнила) во всеобщее благоденствие на рынке С-шных языков.
>> Если вы считаете, что человек, знающий Common Lisp, Smalltalk и ML найдет для себя что-то новое и неизвестное в C++, то мне придется вас разочаровать. Не найдет.
ПК>Вероятно, Вам будет удобнее увидеть это новое, глядя не на спецификацию самого языка, а на формальное описание некоторой части его семантики. Вот попытка составления такого формализма; кстати, там явно прописаны отличия от Хаскеля.
О, спасибо.
Странный документ. Хаскель там для сравнения системы типов приведен. Причем в каждом случае описываются отличия системы типов С++ от Хаскеля. Они там и предупреждают в начале, что на этом и будут строить формализм.
Видимо, это был самый простой способ. Но для реального сравнения этих двух языков, этот подход малосодержателен, нужно сказать.
Потому что даже как только система типов, Хаскель там присутствует лишь небольшой частью (фактически только typeclasses).
Вообще же, несмотря на то, что в реальной жизни можно даже найти параллели между С++ и Haskell, реальная их семантика различается настолько, что на полном серьезе ее сравнивать, это очень смело
Я кстати конкретно с Haskell C++ и не сравнивал.
Вообще это популярные в последнее время экзерсисы — какой-нибудь формализм понеожиданнее придумать. Вот исчисление для явовских классов: http://homepages.inf.ed.ac.uk/wadler/papers/featherweight/featherweight.ps
позволяет решать систему типов.
Очень смешное кстати.
ПК>Есть и ряд отличий, существенных с практической точки зрения. Часть из них упоминал eao197, но, к сожалению, Вашего мнения по этому поводу каждого из отличий увидеть не удалось; поэтому я пока, пожалуй, воздержусь от их перечисления.
А что-то кстати не соображу быстро о чем речь, где это?
reductor,
> C>1) State-of-art система ручного управления памятью. Назовите мне > C>язык, где управлять распределением/уничтожением памяти можно так же > C>гибко и удобно как в С++.
> Уфф. Меня аж чуть просветление не хватило. То есть это не баг, а _фича_ Си++ такое управление памятью?
Пожалуй, правильнее говорить об управлении временем жизни объектов, с чем C++, действительно, справляется лучше ряда других языков благодаря детерминированному разрушению объектов. GC этой задачи не решает.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
AVC wrote: > > Само собой. > По сравнению с самым влиятельным языком современности (ML, разумеется) > мало что имеет значение...
Вы недооцениваете влияние ML, например, на Вашу повседневную жизнь (если
Вы, конечно, программер)
> Ну, я догадывался, что Милнер — автор одного из функциональных языков, о > которых Вы так восторженно говорите. > Только не знал — какого именно. > И на кого же он так повлиял (кроме других ученых, разумеется)? > А то его безмерное могущество не везде так сильно ощущается.
Ну вот, например, темплейты в C++ — пародия на ML (или, скорее, на
Haskell, т.к. они ленивые).
eao197 wrote: > > C>А с операционными системами у > C>Торвальдса явно лучше результат. > > Интересно, где бы был Торвальдс со своим ядром, если бы он делал > собственную ОС, а не очередной клон Unix-а?
Кому нужна очередная новая операционная система, если она не клон
UNIX'а. Или, на худой конец, VMS'а?
Cyberax wrote: > > Надо сказать, что ядро к окружению отношение не очень большое имеет (а > Unix — это прежде всего окружение). То есть на Linux'е можно запустить и > встроеное устройство вообще без файловой системы. Кроме того, критикам > Линуса стоит напомнить, что есть куча *BSD-систем, которые так и не > набрали популярность (в отличие от Линукса).
Вообще без файловой системы, это вряд ли. Без файловой системы на
"твердом носителе", это возможно.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>reductor,
>> C>1) State-of-art система ручного управления памятью. Назовите мне >> C>язык, где управлять распределением/уничтожением памяти можно так же >> C>гибко и удобно как в С++.
>> Уфф. Меня аж чуть просветление не хватило. То есть это не баг, а _фича_ Си++ такое управление памятью?
ПК>Пожалуй, правильнее говорить об управлении временем жизни объектов, с чем C++, действительно, справляется лучше ряда других языков благодаря детерминированному разрушению объектов. GC этой задачи не решает.
Я все же не понимаю кое-чего. Для каких задач нужно такое управление?
Но даже если так, почему С++ здесь справляется лучше тех языков, у которых нет проблем с алиасингом?
Окамла, у которого очень прогрессивный копирующий GC при котором куча всегда утрамбована и который еще и полностью управляемый?
Или чем С++ здесь лучше Cyclone c его регионами и прочим?
Privalov wrote: > > Добавлю, что, возможно, именно Паскаль помог уйти от разработки монстров > типа PL/1. Иначе, был бы сейчас какой-нибудь PL/3, объединяющий все > самое худшее из всех течений в программировании.
А разве C++ в сочетании с Win32 API к этому не стремится?...
Здравствуйте, Pzz, Вы писали:
Pzz>Вы недооцениваете влияние ML, например, на Вашу повседневную жизнь (если Pzz>Вы, конечно, программер)
Разве что на будущую?
Pzz>Ну вот, например, темплейты в C++ — пародия на ML (или, скорее, на Pzz>Haskell, т.к. они ленивые).
ИМХО, этой пародией детей пугать можно...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
eao197 wrote: > > Нет, работа замечательная, долго к такой стремился. > Меня призраки прошлого гнетут. Когда я решил повторить достижение > Константина Книжника <http://www.garret.ru/~knizhnik/index.html> и > защитить дисертацию по собственноручно написанной объектной СУБД (Косте > удалось это сделать по своей СУБД GOODS > <http://www.garret.ru/~knizhnik/goods.html>). Никого не интересовали > технические подробности ее реализации, ее возможности, оснащенность > утилитами, полезность и реальные внедрения в реальные проекты. Все > вопросы начинались с количества моих публикаций. Максимум, до чего > доходило -- это до: "В чем состоит научная новизна?" и "Что было сделано > лично вами?". Обычно разговор на вопросе "научной новизны" терял свою > актуальность. А апофиозом моего обучения в аспирантуре был вопрос от
Ну вообще, по-моему, это правильно. Диссертация все же должна быть про
науку, а не про то, какую замечательную программу можем мы написать. И
оцениваться диссертация, по-моему, должна в первую очередь с точки
зрения научного вклада.
reductor wrote: > > Вообще же, несмотря на то, что в реальной жизни можно даже найти > параллели между С++ и Haskell, реальная их семантика различается > настолько, что на полном серьезе ее сравнивать, это очень смело
Я бы предложил относиться к C++ как к двум разным языкам, с разной
парадигмой, причудливо соединенным в одном языке.
Один язык — это C с классами. Другой — это темплейты.
C с классами на Хаскель, конечно, не похож. Но вот темплейты напоминают
пародию на Хаскель — сильно урезанную и с ужасным синтаксисом.
AVC wrote: > > Pzz>Вы недооцениваете влияние ML, например, на Вашу повседневную жизнь (если > Pzz>Вы, конечно, программер) > > Разве что на будущую? > > Pzz>Ну вот, например, темплейты в C++ — пародия на ML (или, скорее, на > Pzz>Haskell, т.к. они ленивые). > > ИМХО, этой пародией детей пугать можно...
: функциональные языки какие крутые (круче них, понятное дело, только яйца)! Вот почему они мейнстримом не стали понять до сих пор не могу?
Z>Ну, например, вот немного линейной алгебры из домашнего задания первокурсника, который к тому времени уже целых два месяца учится программировать. Если это переписать на boost::mpl и запостить с форум по С++ — все закричат, что это извращение и среднему труженнику С++ этого ни в жисть не понять Z>
Z>(define (dot-product v w)
Z> (accumulate + 0 (map * v w)))
Z>(define (matrix-*-vector m v)
Z> (map (lambda (x) (dot-product x v)) m))
Z>(define (transpose m)
Z> (accumulate-n cons null m))
Z>(define (matrix-*-matrix m n)
Z> (let ((cols (transpose n)))
Z> (map (lambda (x) (matrix-*-vector cols x)) m)))
Z>
А чего здесь вообще должно делаться? Матрица на матрицу перемножаться?
Ну и сколько Scheme-программисту нужно будет изучать C++ и boost::mpl для того, чтобы сделать то же самое через C++ные expression templates?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
// Finally, destroy the key and the region
free_ukey(key);
В морг.
Да и подобное делается с помощью пулов в обычном С++.
R>Но хочется понять долго ли мемори менеджмент в С++ доходил до state-of-the-art, чтобы достигнуть достигать такого — язык, к которому даже GC нормальный не прицепишь. А то мне кажется, идея такого мемори менеджмента мягко говоря не нова.
Почему же, консервативные GC подцепляются без проблем (лично Boehm GC использовал). А С++/CLI вообще рассчитан на точную сборку.
А вот покажите мне, пожалуйста, язык с понятием умных указателей, автоматических объектов, placement new, и при этом не клон С++ (Hint: наиболее близко к этому подходит язык D).
C>>2) Взаимодействие с кодом на С. Где у нас еще есть extern "C"? R>Хм. R>С/Objective-C/D/Cyclone ?
C не считаем. Objective-C страдает с управлением памятью, да и недоделаный он вообще какой-то. D — да, но это последователь С++.
Cyclone — слишком мало возможностей. Нет OOP, темплейтов и т.п.
R>А вообще конечно это одна из самых важных и уникальных идей и языка С++, да.. R>Скажите, а foreign export ccall в Хаскеле написать уже нет? R>или там external в O'Caml
Простите, но если вы не понимаете, что интероперабельность делается не только одним extern-вызовом функций, то вы просто дилетант.
И нет. Ни Хаскел, ни OCaml не имеют даже близких возможностей интероперабельности.
C>>Я писал на OCaml'е и немного на Haskell'е, например. Неплохо, но далеко C>>не самая лучшая вещь с начала времен. R>А расскажите какая лучшая?
Никакая. Но функциональные языки уж точно на нее не тянут.
R>Кстати еще интересно чем вам так мемори менеджмент в окамле и хаскеле не угодил. Правда.
Не всегда GC (и связаный с ним оверхед) нужен. И кое-где он не нужен совсем.
Pzz wrote:
>> Надо сказать, что ядро к окружению отношение не очень большое имеет (а >> Unix — это прежде всего окружение). То есть на Linux'е можно запустить и >> встроеное устройство вообще без файловой системы. Кроме того, критикам >> Линуса стоит напомнить, что есть куча *BSD-систем, которые так и не >> набрали популярность (в отличие от Линукса). > Вообще без файловой системы, это вряд ли.
Сам такое устройство видел. Делается без проблем — все нужное пишется в
виде ядерных модулей и статически линкуется.
> Без файловой системы на "твердом носителе", это возможно.
Можно и на диске — ядро в память загружает lilo, которому FS не нужна.
Sinclair wrote:
> C>У goto есть минус — очень сложно отслеживать переходы "назад". И > C>вложенные goto тоже страшновато выглядят. > Дело не в страшноватости вида. А в том, что очень трудно определить > зависимости. Совершенно неважно, прыгает goto вперед или назад. > Проблема в том, что в любую метку ты можешь попасть из неопределенного > количества мест, и совершенно непонятно, какие ветки кода к этому > моменту были выполнены, и сколько раз.
Если у кода есть зависимости от того, какие ветки были выполнены — то не
надо использовать goto (или сделать его использование безопасным). Тут
действительно хорошо подходит С-шный паттерн "goto cleanup".
> Конечно, goto — не единственный способ запутать программу. Но если > ограничиться "безопасным" использованием goto, то оно как раз и > сведется к while, if, return.
Я бы еще добавил break/continue и имитацию исключений.
шапокляк wrote:
> C> А сейчас до сих пор в своих языках занимается (в основном) > идеологией без нововведений. За это Вирта и не любят тут Как я успела > заметить Вирта тут не любят за другое — он и его слова вносят ненужный > диссонанс (во какое словечко вспомнила) во всеобщее благоденствие на > рынке С-шных языков.
Нет, скорее поднимает из могилы давно надоевшие флеймы.
Диссонансом занимается Python/OCaml и другие новые языки.
reductor wrote:
> ПК>Пожалуй, правильнее говорить об управлении временем жизни объектов, > с чем C++, действительно, справляется лучше ряда других языков > благодаря детерминированному разрушению объектов. GC этой задачи не > решает. > Я все же не понимаю кое-чего. Для каких задач нужно такое управление?
Например, если нельзя допускать пауз GC и большого оверхеда
конкурентного GC. Или если существуют гораздо более эффективные методы
управления памятью для данной задачи (preallocated пулы, например). Или
если требуется детерминированое уничтожение объекта.
> Но даже если так, почему С++ здесь справляется лучше тех языков, у > которых нет проблем с алиасингом?
А в С++ нет проблем с алиасингом. Более того, он тоже успешно
используется для некоторых трюков. Вот вам прямо с About Haskell
(http://www.haskell.org/aboutHaskell.html):
It isn't all roses, of course. The C quicksort uses an extremely
ingenious technique, invented by Hoare, whereby it sorts the array /in
place/; that is, without using any extra storage. As a result, it runs
quickly, and in a small amount of memory. In contrast, the Haskell
program allocates quite a lot of extra memory behind the scenes, and
runs rather slower than the C program.
In effect, the C quicksort does some very ingenious storage management,
trading this algorithmic complexity for a reduction in run-time storage
management costs.
In applications where performance is required at any cost, or when the
goal is detailed tuning of a low-level algorithm, an imperative language
like C would probably be a better choice than Haskell, exactly because
it provides more intimate control over the exact way in which the
computation is carried out.
> Окамла, у которого очень прогрессивный копирующий GC при котором куча > всегда утрамбована и который еще и полностью управляемый? > Или чем С++ здесь лучше Cyclone c его регионами и прочим?
А говорите "выучить язык за пару дней"...
В С++ продумано взаимодействие аллокаторов, стандартных контейнеров,
алгоритмов и т.п. Например, как мне поместить в контейнер OCaml'а
объект, созданый в блоке shared memory? Причем указатели в этом объекте
представлены в виде смещений относительно начала блока, а null pointer
представлен в виде указателя со смещением -1.
Здравствуйте, Andir, Вы писали:
Д>>а то, что наука в нашей стране окончательно прогнила и практически ни на что не годится — это и так известный факт
A> Какая чушь! Прогнила не наука, а максимум — система обучения. А Наука не приемлет государственных границ.
Andir, не знаю, за что именно ты мне поставил минус, но против науки, как таковой, я ничего не говорил. Я просто сказал, что не приемлю тех оценок "производительности" или "показанных результатов", которые применялись некоторое время назад -- количество публикаций. Этот критерий еще может как-то показывать достижения математика или физика, но если речь идет о программировании, то почему в расчет не принимаются реализованные в ПО идеи, я не могу понять.
Это как религия и церковь: понятие и институт вокруг него. Так же, есть Наука и есть Ученые с большой буквы. А есть "наука", как институт вокруг Науки. В котором свои правила и порядки, иерархия и система ценностей. И я согласен с Дарнеем, что во многих прикладных областях (о фундаментальных исследованиях не скажу) этот институт прогнил. В часности, в области ИТ.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Любое внедрение чего угодно. Даже если ты "изобрел" сортировку пузырьком, для дисера вполне хватит "применение сортировки пузырьком в свинодобывающей промышленности"...
Это что-то из области "булки на деревьях растут, а Россия-родина слонов"?
Здравствуйте, Игoрь, Вы писали:
И>И что ты мне пытаешься доказать? Я разве где-то говорил о том, что я против структурного программирования? Я говорил только о том, что возможны ситуации, когда применение явного goto оправдано. Вообще тема настолько заезжена, что у меня нет особого желания спорить. Если ты считаешь, что метки — это абсолютное зло, то я не смогу тебя переубедить. У Кнута есть статья на эту тему Structured Programming with go to Statements.
Я просто хочу увидеть код где использование goto оправдано.
Я не утверждаю , что это зло абсолютное — но то что зло — однозначно.
Повторюсь еще раз , единственная ситуация где с C/C++ я бы мог стерпеть goto это выход из наспех сделанного вложенного цикла.
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, Дарней, Вы писали:
Д>>а то, что наука в нашей стране окончательно прогнила и практически ни на что не годится — это и так известный факт
A> Какая чушь! Прогнила не наука, а максимум — система обучения. А Наука не приемлет государственных границ.
A> C Уважением, Andir!
Здравствуйте, Pzz, Вы писали:
Pzz>Тогда уж еще и Биллу Гейтсу — влияние его империи еще сильнее.
Не пойдет. Гейтс — менеджер и финансист. Ему другая премия полагается(хотя не знаю, нужна ли она ему).
Здравствуйте, Cyberax, Вы писали:
C>Простите, но если вы не понимаете, что интероперабельность делается не только одним extern-вызовом функций, то вы просто дилетант.
Сейчас мы выясним кто здесь дилетант.
R>>Уфф. Меня аж чуть просветление не хватило. То есть это не баг, а _фича_ Си++ такое управление памятью? C>Да, причем она дает достаточно много преимуществ по сравнению с другими языками.
Опишите их. По сравнению с Окамлом, Хаскелем и Cyclone.
R>>Вообще, прежде чем ответить, хочется конечно понять для чего оно вам такое нужно. R>>А то ведь есть такое: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html C>Ну GC. И что? Кого сейчас этим можно удивить?
Во-первых удивить этим можно С++ к которому такой GC не прицеишь, а во-вторых — речь идет о memory management, если не ошибаюсь?
это включает в себя и то, что описано на той странице. Покажите мне как в С++ сделать то, что умеет окамловский GC.
и не в C++ для .NET, ага?
После чего попробуйте мне рассказать, что в окамле и где угодно нельзя руками выделять и освобождать память.
Вы кстати не сказали зачем вам это нужно. А я жду.
C> // Finally, destroy the key and the region
C> free_ukey(key);
C>В морг.
че?
C>Да и подобное делается с помощью пулов в обычном С++.
Вы о чем вообще. Пул — это что, средство _языка_ должно быть?
R>>Но хочется понять долго ли мемори менеджмент в С++ доходил до state-of-the-art, чтобы достигнуть достигать такого — язык, к которому даже GC нормальный не прицепишь. А то мне кажется, идея такого мемори менеджмента мягко говоря не нова. C>Почему же, консервативные GC подцепляются без проблем (лично Boehm GC использовал). А С++/CLI вообще рассчитан на точную сборку.
Консервативные GC идут туда же, куда автопойнтеры, смартпойнтеры и всякая другая жуть на подпорках для эмуляции GC.
сейчас, на секундочку, 2005 год заканчивается.
что касается C++ на .NET, речь началась про С++, который у страуструпа, а не который на .NET. Не увиливайте.
C>А вот покажите мне, пожалуйста, язык с понятием умных указателей, автоматических объектов, placement new, и при этом не клон С++
Вы сами перечитали хоть перед тем как это отправить?
Во-первых это к языку как таковому отношения не имеет, во-вторых, зачем какому-то языку костыль, если в нем изначально все сделано правильно. смартпойнтеры... надо же.
C>(Hint: наиболее близко к этому подходит язык D).
Очень смешно, но не в тему.
C>>>2) Взаимодействие с кодом на С. Где у нас еще есть extern "C"? R>>Хм. R>>С/Objective-C/D/Cyclone ? C>C не считаем. Objective-C страдает с управлением памятью, да и недоделаный он вообще какой-то. D — да, но это последователь С++.
C>Cyclone — слишком мало возможностей. Нет OOP, темплейтов и т.п.
Чего еще там нет? Вы это почитав/подумав написали?
"т.п." там нет. да.
R>>А вообще конечно это одна из самых важных и уникальных идей и языка С++, да.. R>>Скажите, а foreign export ccall в Хаскеле написать уже нет? R>>или там external в O'Caml C>Простите, но если вы не понимаете, что интероперабельность делается не только одним extern-вызовом функций, то вы просто дилетант.
А расскажите мне чем она делается?
А то у меня вообще тут автомат генерирует все. И я потом пользуюсь.
Получается, что даже проще.
C>И нет. Ни Хаскел, ни OCaml не имеют даже близких возможностей интероперабельности.
Близких, это каких?
А то интересно очень.
C>>>Я писал на OCaml'е и немного на Haskell'е, например. Неплохо, но далеко C>>>не самая лучшая вещь с начала времен. R>>А расскажите какая лучшая? C>Никакая. Но функциональные языки уж точно на нее не тянут.
Расскажите почему. Подробно. И покажите.
R>>Кстати еще интересно чем вам так мемори менеджмент в окамле и хаскеле не угодил. Правда. C>Не всегда GC (и связаный с ним оверхед) нужен. И кое-где он не нужен совсем.
А вот это здорово.
Расскажите какой оверхед у GC. _Особенно_ Окамловского.
И почему окамл быстрее С++ при этом.
Cyberax wrote: > >>> Надо сказать, что ядро к окружению отношение не очень большое имеет (а >>> Unix — это прежде всего окружение). То есть на Linux'е можно запустить и >>> встроеное устройство вообще без файловой системы. Кроме того, критикам >>> Линуса стоит напомнить, что есть куча *BSD-систем, которые так и не >>> набрали популярность (в отличие от Линукса). >> Вообще без файловой системы, это вряд ли. > > Сам такое устройство видел. Делается без проблем — все нужное пишется в > виде ядерных модулей и статически линкуется.
Так можно, но зачем тогда Линух? Почему не eCos или RTEMS, которые как
раз предназначены быть прилинкованы к программе в виде библиотеки.
По-моему, Linux без user space это все же извращение...
А что касается "без проблем", инициализацию в ядре придется таки
подхачить, чтобы оно /sbin/init не пыталось запускать. Для многих, хотя
и не для всех, идея что-то поковырять в ядре не кажется беспроблемной
Pzz wrote:
> Так можно, но зачем тогда Линух? Почему не eCos или RTEMS, которые как > раз предназначены быть прилинкованы к программе в виде библиотеки. > По-моему, Linux без user space это все же извращение...
Куча готовых драйверов, сервисов ядра и т.п.
> А что касается "без проблем", инициализацию в ядре придется таки > подхачить, чтобы оно /sbin/init не пыталось запускать.
Не помню, но кажется это делается даже из make menuconfig.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> ПК>Пожалуй, правильнее говорить об управлении временем жизни объектов, >> с чем C++, действительно, справляется лучше ряда других языков >> благодаря детерминированному разрушению объектов. GC этой задачи не >> решает. >> Я все же не понимаю кое-чего. Для каких задач нужно такое управление?
C>Например, если нельзя допускать пауз GC и большого оверхеда C>конкурентного GC. Или если существуют гораздо более эффективные методы C>управления памятью для данной задачи (preallocated пулы, например). Или C>если требуется детерминированое уничтожение объекта.
Эффективное управление...
>> Но даже если так, почему С++ здесь справляется лучше тех языков, у >> которых нет проблем с алиасингом?
C>А в С++ нет проблем с алиасингом. Более того, он тоже успешно C>используется для некоторых трюков.
Переведите
C>Вот вам прямо с About Haskell
Что вы хотели сказать цитированием мне этого sales talk десятилетней давности?
>> Окамла, у которого очень прогрессивный копирующий GC при котором куча >> всегда утрамбована и который еще и полностью управляемый? >> Или чем С++ здесь лучше Cyclone c его регионами и прочим?
C>А говорите "выучить язык за пару дней"...
Говорю.
C>В С++ продумано взаимодействие аллокаторов, стандартных контейнеров, C>алгоритмов и т.п. Например, как мне поместить в контейнер OCaml'а C>объект, созданый в блоке shared memory? Причем указатели в этом объекте C>представлены в виде смещений относительно начала блока, а null pointer C>представлен в виде указателя со смещением -1.
Вы будете продолжать фантазировать или хотя бы прочитаете мануал по окамлу?
А то мало того, что придумываете жуть всякую, еще и жуть, которая к особенностям языка (в том числе и С++) вообще не относится.
Указатели, объекты, shared memory... мнда.
И кстати. http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign.html
reductor wrote:
> R>>Уфф. Меня аж чуть просветление не хватило. То есть это не баг, а > _фича_ Си++ такое управление памятью? > C>Да, причем она дает достаточно много преимуществ по сравнению с > другими языками. > Опишите их. По сравнению с Окамлом, Хаскелем и Cyclone.
См. ниже.
> R>>Вообще, прежде чем ответить, хочется конечно понять для чего оно > вам такое нужно. > R>>А то ведь есть такое: > http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html > C>Ну GC. И что? Кого сейчас этим можно удивить? > Во-первых удивить этим можно С++ к которому такой GC не прицеишь, а > во-вторых — речь идет о memory management, если не ошибаюсь?
Ручном управлении памятью.
> это включает в себя и то, что описано на той странице. Покажите мне > как в С++ сделать то, что умеет окамловский GC. > и не в C++ для .NET, ага?
В С++ для этого есть другие средства. Зачастую более адекватные.
> После чего попробуйте мне рассказать, что в окамле и где угодно нельзя > руками выделять и освобождать память. > Вы кстати не сказали зачем вам это нужно. А я жду
Руками освобождать ресурсы. Дикость в современном С++.
> C>Да и подобное делается с помощью пулов в обычном С++. > Вы о чем вообще. Пул — это что, средство _языка_ должно быть?
Нет, благодаря средству языка (а именно placement new) можно
реализовать свое управление памятью для объектов. И в частности данную
систему.
> C>Почему же, консервативные GC подцепляются без проблем (лично Boehm > GC использовал). А С++/CLI вообще рассчитан на точную сборку. > Консервативные GC идут туда же, куда автопойнтеры, смартпойнтеры и > всякая другая жуть на подпорках для эмуляции GC. сейчас, на > секундочку, 2005 год заканчивается. что касается C++ на .NET, речь > началась про С++, который у страуструпа, а не который на .NET. Не > увиливайте.
И что? Можно и точный GC для С++ сделать, но это потребует кооперации со
стороны программиста. В библиотеке Boost.Regex, например, есть такой
один (хотя и примитивный).
> C>А вот покажите мне, пожалуйста, язык с понятием умных указателей, > автоматических объектов, placement new, и при этом не клон С++ > Вы сами перечитали хоть перед тем как это отправить? Во-первых это к > языку как таковому отношения не имеет,
Да? Читаем: автоматические объекты — одна из центральных фич языка.
Умные указатели — требуют перегрузки оператора разыменования, так что
это тоже языковая особенность. Placement new — одна из форм ключевого
слова new.
Дальше будете демонстрировать незнание?
> во-вторых, зачем какому-то языку костыль, если в нем изначально все > сделано правильно. смартпойнтеры... надо же.
Вы не понимаете значение слова "гибкость"? Или наивно полагаете, что
можно предусмотреть все случаи использования заранее?
Имеем: библиотека VTK, все объекты в ней создаются с помощью
статического метода New, а уничтожаются методом Delete. Требуется
написать функцию, которая будет создавать объект, чего-то с ним делать и
возвращать его. При этом я не должен заботиться о необходимости ручного
вызова Delete.
> C>Cyclone — слишком мало возможностей. Нет OOP, темплейтов и т.п. > Чего еще там нет? Вы это почитав/подумав написали? > "т.п." там нет. да.
Когда я в последний раз смотрел — еще не было. Теперь добавили, но все
равно с ограничениями.
> C>Простите, но если вы не понимаете, что интероперабельность делается > не только одним extern-вызовом функций, то вы просто дилетант. > А расскажите мне чем она делается? А то у меня вообще тут автомат > генерирует все. И я потом пользуюсь. > Получается, что даже проще.
Это _использование_ C через проксики, а не полноценная
интероперабельность с ним. А то так можно взять SOAP и сказать, что с
помощью него можно с С интероперировать.
> C>И нет. Ни Хаскел, ни OCaml не имеют даже близких возможностей > интероперабельности. > Близких, это каких?
Битовые поля? union'ы? #pragma pack? Поддержка __stdcall, __fastcall и
других calling conventions. Поддержка сторонних аллокаторов.
> R>>А расскажите какая лучшая? > C>Никакая. Но функциональные языки уж точно на нее не тянут. > Расскажите почему. Подробно. И покажите.
Преимущества пока что не перевешивают недостатков. Я бы предпочел
обычный императивный язык с небольшими функциональными расширениями,
пока в этом направлении движется C#.
> R>>Кстати еще интересно чем вам так мемори менеджмент в окамле и > хаскеле не угодил. Правда. > C>Не всегда GC (и связаный с ним оверхед) нужен. И кое-где он не нужен > совсем. > А вот это здорово. Расскажите какой оверхед у GC.
Функциональное программирование прекрасно, оно — радость созерцания. Как только кто-то поймет функциональное программирование, он немедленно перейдет к нему. Массы, которые застряли в устаревшем императивном и объектно-ориентированном программировании, делают это из слепого предубеждения. Они просто не понимают.
Каким-то религиозным духом попахивает
Хотя интересно было бы найти время покопаться в исходниках unison, он вроде на OCaml был реализован. В свое время и ООП пыталось пробивать себе дорогу.
В предыдущей колонке [1] перечислены некоторые из таких применений, и подчеркнуто как используется мощность функциональных языков. Разработчиков сетей связи привлекает Erlang своей поддержкой параллелизма и распределенных вычислений; последнее непосредственно связано с тем фактом, что функциональные данные, являющиеся неизменным, хорошо пригодны для передачи по сети. Создателей систем доказательств теорем привлекает ML с его поддержкой символьных вычислений. Генетики тяготеют к CPL/Kleisli, потому что его система типов поддерживает доступ к гетерогенным базам данных, и потому что математические свойства функциональных языков могут использоваться для оптимизации запросов. Разработчики экспертных систем привлечены к Natural Expert, потому что ленивые вычисления походят на рассуждения обратным логическим выводом, и потому что ленивые вычисления дают возможность создавать экономичный интерфейс к базам данных.
Хочется добавить, что C, C++ и Java успешно работают во всех этих областях
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
reductor wrote:
> C>Например, если нельзя допускать пауз GC и большого оверхеда > C>конкурентного GC. Или если существуют гораздо более эффективные методы > C>управления памятью для данной задачи (preallocated пулы, например). Или > C>если требуется *детерминированое* уничтожение объекта. > Вы на чей вопрос здесь отвечаете? > Я спрашивал для каких задач. Конкретнее.
Игры, требовательные десктопные приложения, системный софт.
> Опять же, про паузы интересно.
RTFM: http://www.memorymanagement.org/
> C>А в С++ нет проблем с алиасингом. Более того, он тоже успешно > C>используется для некоторых трюков. > Переведите
В С++ нет проблем с накладывающимися массивами, так как они с помощью
адресной арифметики могут быть использованы для интересных
inplace-преобразований.
> C>Вот вам прямо с About Haskell > Что вы хотели сказать цитированием мне этого sales talk десятилетней > давности?
А что, вы один должны гнать sales-talk десятилетней давности про GC?
> C>В С++ продумано взаимодействие аллокаторов, стандартных контейнеров, > C>алгоритмов и т.п. Например, как мне поместить в контейнер OCaml'а > C>объект, созданый в блоке shared memory? Причем указатели в этом объекте > C>представлены в виде смещений относительно начала блока, а null pointer > C>представлен в виде указателя со смещением -1. > Вы будете продолжать фантазировать или хотя бы прочитаете мануал по > окамлу?
КАК мне разместить, скажем, список OCaml'а в shared memory и передать на
него ссылку в другой процесс? В С++ это делается так:
//Type of shared memory vectortypedef vector<int, shmem_allocator_int_t > MyVect;
//Create named vector
MyVect *shmem_vect = segment.construct<MyVect>
("ShmVect")(segment.get_raw_alloc_algo());
for(int i = 0; i < max; ++i){
shmem_vect->push_back(i);
}
В другом процессе:
typedef vector<int, shmem_allocator_int_t > MyVect;
MyVect *shmem_vect = segment.find<MyVect>("ShmVect").first;
//А теперь можно, например, посортировать вектор.
std::sort(shmem_vect->rbegin(), shmem_vect->rend());
Хотя я знаю, что вы скажете — дадите мне ссылку на документацию по FFI и
станете рассказывать, что shared memory устарел и никому не нужен.
Cyberax wrote: > >> Так можно, но зачем тогда Линух? Почему не eCos или RTEMS, которые как >> раз предназначены быть прилинкованы к программе в виде библиотеки. >> По-моему, Linux без user space это все же извращение... > > Куча готовых драйверов, сервисов ядра и т.п.
Ну, куча драйверов не нужна. Нужны именно те, которые соответствуют
вашей embedded системе. А таковых может и не быть.
Что до сервисов, они гораздо в более удобном виде доступны из user space.
>> А что касается "без проблем", инициализацию в ядре придется таки >> подхачить, чтобы оно /sbin/init не пыталось запускать. > > Не помню, но кажется это делается даже из make menuconfig.
По-моему, все же не делается. И оно еще обижается, если у него нету хоть
какой-нибудь рутовой файловой системы.
Pzz wrote:
>> Куча готовых драйверов, сервисов ядра и т.п. > Ну, куча драйверов не нужна. Нужны именно те, которые соответствуют > вашей embedded системе. А таковых может и не быть.
Ну вот как раз в Линуксе они были Этот девайс — промышленный
контроллер с видеокамерой.
>>> А что касается "без проблем", инициализацию в ядре придется таки >>> подхачить, чтобы оно /sbin/init не пыталось запускать. >> Не помню, но кажется это делается даже из make menuconfig. > По-моему, все же не делается. И оно еще обижается, если у него нету хоть > какой-нибудь рутовой файловой системы.
Может быть, уже не помню, а смотреть лень Но оно точно очень просто
делается.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, 0xDEADBEEF, Вы писали:
M>Откровенно говоря , после взгляда на вход в середину цикла , разбираться что этот код делает — пропадает у меня охота ..
В середину бесконечного цикла — it makes a lot of difference.
Впрочем, если вы послушный ребенок и никогда не стреляли из рогатки, потому что мама запрещает, я вас понимаю...
Впрочем, на вопрос вы не ответили. А вопрос, напоминаю, был: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>В середину бесконечного цикла — it makes a lot of difference. DEA>Впрочем, если вы послушный ребенок и никогда не стреляли из рогатки, потому что мама запрещает, я вас понимаю...
Стрельба из рогатки, кстати, отнюдь не безобидное занятие и запрещается не безосновательно.
А если ты используешь goto по принципу "запретный плод сладок", то в этом нет ничего хорошего.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> R>>Уфф. Меня аж чуть просветление не хватило. То есть это не баг, а >> _фича_ Си++ такое управление памятью? >> C>Да, причем она дает достаточно много преимуществ по сравнению с >> другими языками. >> Опишите их. По сравнению с Окамлом, Хаскелем и Cyclone.
C>См. ниже.
>> R>>Вообще, прежде чем ответить, хочется конечно понять для чего оно >> вам такое нужно. >> R>>А то ведь есть такое: >> http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html >> C>Ну GC. И что? Кого сейчас этим можно удивить? >> Во-первых удивить этим можно С++ к которому такой GC не прицеишь, а >> во-вторых — речь идет о memory management, если не ошибаюсь?
C>Ручном управлении памятью.
Последний раз — GC не запрещает вручную выделять память. И попробуйте сказать обратное.
При это по ссылке приведены функции, аналог которых попробуйте найдите в С++.
>> это включает в себя и то, что описано на той странице. Покажите мне >> как в С++ сделать то, что умеет окамловский GC. >> и не в C++ для .NET, ага?
C>В С++ для этого есть другие средства. Зачастую более адекватные.
Покажите как в С++ дефрагментировать кучу
>> После чего попробуйте мне рассказать, что в окамле и где угодно нельзя >> руками выделять и освобождать память. >> Вы кстати не сказали зачем вам это нужно. А я жду
C>См. пример в другом письме с объектом в shared memory.
Мимо кассы.
Скажите зачем вам нужно выделять руками память и освобождать ее.
Это дикость везде.
Но в данном случае вы говорили про ручное управление. Вас шатает из стороны в сторону. Держитесь.
Или хотите сказать, в Cyclone нельзя делать этого автоматически?
>> C>Да и подобное делается с помощью пулов в обычном С++. >> Вы о чем вообще. Пул — это что, средство _языка_ должно быть?
C>Нет, благодаря средству языка (а именно placement new) можно C>реализовать свое управление памятью для объектов. И в частности данную C>систему.
Вот этого я не понял. Хотите сказать, синтаксическая возможность написать new (buffer) — это достижение и уникальная особенность?
Или создать буфер заранее?
И в cyclone/caml/haskell/lisp этого нельзя?
Great.
>> C>Почему же, консервативные GC подцепляются без проблем (лично Boehm >> GC использовал). А С++/CLI вообще рассчитан на точную сборку. >> Консервативные GC идут туда же, куда автопойнтеры, смартпойнтеры и >> всякая другая жуть на подпорках для эмуляции GC. сейчас, на >> секундочку, 2005 год заканчивается. что касается C++ на .NET, речь >> началась про С++, который у страуструпа, а не который на .NET. Не >> увиливайте.
C>И что? Можно и точный GC для С++ сделать, но это потребует кооперации со C>стороны программиста. В библиотеке Boost.Regex, например, есть такой C>один (хотя и примитивный).
Нельзя. Или покажите мне как взять например wxwidgets и запустить его под инкрементальным GC который еще автоматом отучит каждый объект при создании требовать указания родителя.
Кооперация... state-of-the-art система с кооперацией.
>> C>А вот покажите мне, пожалуйста, язык с понятием умных указателей, >> автоматических объектов, placement new, и при этом не клон С++ >> Вы сами перечитали хоть перед тем как это отправить? Во-первых это к >> языку как таковому отношения не имеет,
C>Да? Читаем: автоматические объекты — одна из центральных фич языка.
Это не фича, это баг.
C>Умные указатели — требуют перегрузки оператора разыменования, так что C>это тоже языковая особенность. Placement new — одна из форм ключевого C>слова new.
И таким образом все эти уникальные особенности сводятся к возможности перегружать операторы?
Это не уникальная черта С++. Можете мне просто поверить.
Я уж не говорю, что само понятие "оператор" — это тоже баг в С++.
C>Дальше будете демонстрировать незнание?
О да, великий гуру.
>> во-вторых, зачем какому-то языку костыль, если в нем изначально все >> сделано правильно. смартпойнтеры... надо же.
C>Вы не понимаете значение слова "гибкость"? Или наивно полагаете, что C>можно предусмотреть все случаи использования заранее?
Это не гибкость, это затычки для тех дыр, которые можно кое как заткнуть в С++.
Сделать такое хоть в хаскеле не представляется проблемой.
но там это просто _не нужно_.
C>В качестве примера:
C>Имеем: библиотека VTK, все объекты в ней создаются с помощью C>статического метода New, а уничтожаются методом Delete. Требуется C>написать функцию, которая будет создавать объект, чего-то с ним делать и C>возвращать его. При этом я не должен заботиться о необходимости ручного C>вызова Delete.
Хотите сказать, где-то так нельзя?
Я вам там кидал ссылку на то, что в стандартной библиотеке хаскеля это делает.
>> C>Cyclone — слишком мало возможностей. Нет OOP, темплейтов и т.п. >> Чего еще там нет? Вы это почитав/подумав написали? >> "т.п." там нет. да.
C>Когда я в последний раз смотрел — еще не было. Теперь добавили, но все C>равно с ограничениями.
Знаете, это не разговор. Ручное управление памятью — это очень низкого уровня класс задач.
И Cyclone при этом дает ее выполнять с помощью гораздо более высокуровневых инструментов, чем С++
и гораздо мощнее.
Система типов ML, экзистенциальные и абстрактные типы, сабтайпинг, полиморфные структуры, регионы, блаблабла.
Кроме того, что некоторые вещи в С++ будешь делать год, чтобы заработало, другие там еще и вовсе невозможны по фундаментальным причинам.
Вы вскрыли самое больное место С++ — его Си наследие в области того же управления памяти зачем-то.
Даже фортран ведет себя более пристойно в этом смысле.
А потом опять вскрыли — всю эту жуткую систему перегрузки и шаблонов, которая пыхтит, сопит и очень часто не может сделать даже простейшие вещи.
продавец из вас прямо скажем, не очень
>> C>Простите, но если вы не понимаете, что интероперабельность делается >> не только одним extern-вызовом функций, то вы просто дилетант. >> А расскажите мне чем она делается? А то у меня вообще тут автомат >> генерирует все. И я потом пользуюсь. >> Получается, что даже проще.
C>Это _использование_ C через проксики, а не полноценная C>интероперабельность с ним. А то так можно взять SOAP и сказать, что с C>помощью него можно с С интероперировать.
Можно, а что вас не устраивает, кстати?
>> C>И нет. Ни Хаскел, ни OCaml не имеют даже близких возможностей >> интероперабельности. >> Близких, это каких?
C>Битовые поля? union'ы? #pragma pack? Поддержка __stdcall, __fastcall и C>других calling conventions. Поддержка сторонних аллокаторов.
ЭЭ... foreign import stdcall в хаскеле? Ну и я там ссылку кидал на модуль Foreign.*
А в чем вообще проблема-то?
Что мешает _кому угодно_ завести такую поддержку?
Как и аллокаторы и что угодно еще
>> R>>А расскажите какая лучшая? >> C>Никакая. Но функциональные языки уж точно на нее не тянут. >> Расскажите почему. Подробно. И покажите.
C>Преимущества пока что не перевешивают недостатков. Я бы предпочел
Так а какие недостатки-то. Меня этот вопрос сводит с ума.
C>обычный императивный язык с небольшими функциональными расширениями, C>пока в этом направлении движется C#.
Да, C# движется, пока не дойдет до F#
а F# движется пока не дойдет до окамла.
Вы этого события ждете?
>> R>>Кстати еще интересно чем вам так мемори менеджмент в окамле и >> хаскеле не угодил. Правда. >> C>Не всегда GC (и связаный с ним оверхед) нужен. И кое-где он не нужен >> совсем. >> А вот это здорово. Расскажите какой оверхед у GC.
C>Могу и рассказать — как работают GC я знаю в мельчайших подробностях. C>Можете почитать тему: C>http://rsdn.ru/Forum/Message.aspx?mid=993364&only=1
О чем вы там вообще? Что еще за JIT и каким образом это относится к окамлу?
Ну и мельчайшие подробности. Вы откуда это взяли?
>> _Особенно_ Окамловского. И почему окамл быстрее С++ при этом.
C>Не быстрее. Просто иногда помогает отсутствие алиасинга (о котором в С++ C>можно сказать компилятору с помощью слова restrict).
Бум!
все, приехали. просто отсутствие aliasing и то фигня — просто скажи restrict и будет все в ажуре.
Здравствуйте, eao197, Вы писали:
E>Стрельба из рогатки, кстати, отнюдь не безобидное занятие и запрещается не безосновательно.
...переход улицы, кстати, тоже. Но иногда надо.
E>А если ты используешь goto по принципу "запретный плод сладок".
Ну я вроде бы обосоновал почему я применяю goto в данном случае...
Просто я не испытываю по этому поводу комплексов и применяю его там, где оно подходит
А от вас, я тоже хотел бы услышать ответ на вопрос: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, minorlogic, Вы писали:
M>>Откровенно говоря , после взгляда на вход в середину цикла , разбираться что этот код делает — пропадает у меня охота ..
DEA>В середину бесконечного цикла — it makes a lot of difference. DEA>Впрочем, если вы послушный ребенок и никогда не стреляли из рогатки, потому что мама запрещает, я вас понимаю...
Давайте не на личности. ?
DEA>Впрочем, на вопрос вы не ответили. А вопрос, напоминаю, был: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
Я уже писал , goto это НЕЯВНАЯ управляющая конструкция , чтобы понять чем она занимается надо отслеживать логику переходов.
А к примеру do{}while ЯВНО указывает на логику цикла .
reductor wrote:
> C>*Ручном* управлении памятью. > Последний раз — GC не запрещает вручную выделять память. И попробуйте > сказать обратное.
Не запрещает. Но делает это очень неудобным для использования, да еще и
добавляет проблем — GC во время циклов сборки должен сканировать
выделенные пользователем блоки памяти.
Это создает проблемы с расшареной памятью — может возникнуть race
condition с другим процессом. Массивы объектов тоже должны особым
образом инициализироваться. В общем, RTFM стандарт C++/CLI — там
подробно эти сложности расписаны.
> При это по ссылке приведены функции, аналог которых попробуйте найдите > в С++.
С++/CLI или Boehm GC — для тех кому это нужно. В большинстве случаев GC
_не_ нужен.
> C>В С++ для этого есть другие средства. Зачастую более адекватные. > Покажите как в С++ дефрагментировать кучу
1. Не фрагментировать ее. Тем более, что в С++ достаточно для этого средств.
2. Использовать memcpy-moveable-объекты.
3. Сделать move constructor объектам и дефрагментировать на здоровье.
4. Использовать уплотняющий GC.
5. Еще что-то можно придумать.
Придется делать руками (как GC в Boost.Regex), но я не помню, чтобы это
мне когда-нибудь нужно было. Custom'ных аллокаторов для задач мне всегда
хватало.
> C>См. пример в другом письме с объектом в shared memory. > Мимо кассы. > Скажите зачем вам нужно выделять руками память и освобождать ее.
Это не требует GC. Консервативный GC ведь вам не нравится, а точный GC
тянет за собой слона.
> C>Руками освобождать ресурсы. Дикость в современном С++. > Это дикость везде.
Только не в языках с GC. Там это норма.
> Но в данном случае вы говорили про ручное управление. Вас шатает из > стороны в сторону. Держитесь.
Простите, но связь между этими двумя понятиями — одно из самых больших
преимуществ. И вы после этого говорите, что знаете С++????
> Или хотите сказать, в Cyclone нельзя делать этого автоматически?
Нет. В Cyclone нет деструкторов с С++ной семантикой вызова.
> C>Нет, благодаря *средству языка* (а именно placement new) можно > C>реализовать свое управление памятью для объектов. И в частности данную > C>систему. > Вот этого я не понял. Хотите сказать, синтаксическая возможность > написать new (buffer) — это достижение и уникальная особенность?
Да (достижение, хотя и не уникальное). Как мне такое сделать в OCaml? Вы подумайте как это сделать, и что это за собой влечет для GC.
> C>И что? Можно и точный GC для С++ сделать, но это потребует > кооперации со > C>стороны программиста. В библиотеке Boost.Regex, например, есть такой > C>один (хотя и примитивный). > Нельзя.
Можно. Смотрите tracking_ptr.hpp из xpressive в Boost'е, например. В
xpressive используется простой _точный_ GC.
> Или покажите мне как взять например wxwidgets и запустить его под > инкрементальным GC который еще автоматом отучит каждый объект при > создании требовать указания родителя.
А нафига это в wxWidgets нужно? Там вполне хватает ручного управления
памятью.
> C>Да? Читаем: автоматические объекты — одна из центральных фич языка. > Это не фича, это баг.
Ну да. Их же нет в OCaml'е....
> C>Умные указатели — требуют перегрузки оператора разыменования, так что > C>это тоже языковая особенность. Placement new — одна из форм ключевого > C>слова new. > И таким образом все эти уникальные особенности сводятся к возможности > перегружать операторы?
Как мне в OCaml перегрузить оператор обращения к члену структуры?
> C>Вы не понимаете значение слова "гибкость"? Или наивно полагаете, что > C>можно предусмотреть все случаи использования заранее? > Это не гибкость, это затычки для тех дыр, которые можно кое как > заткнуть в С++. > Сделать такое хоть в хаскеле не представляется проблемой. > но там это просто _не нужно_.
Почему-то вы считаете GC — панацеей. И в упор не видите проблем, которые
он создает.
> C>Имеем: библиотека VTK, все объекты в ней создаются с помощью > C>статического метода New, а уничтожаются методом Delete. Требуется > C>написать функцию, которая будет создавать объект, чего-то с ним > делать и > C>возвращать его. При этом я не должен заботиться о необходимости ручного > C>вызова Delete. > Хотите сказать, где-то так нельзя?
Да.
Например в OCaml. Внимание на строчку про "не должен заботиться о
необходимости ручного
вызова Delete". В финализаторе, естественно, это делать тоже нельзя.
> Я вам там кидал ссылку на то, что в стандартной библиотеке хаскеля это > делает.
Ткните пальцем.
> C>Когда я в последний раз смотрел — еще не было. Теперь добавили, но все > C>равно с ограничениями. > Знаете, это не разговор. Ручное управление памятью — это очень низкого > уровня класс задач. > И Cyclone при этом дает ее выполнять с помощью гораздо более > высокуровневых инструментов, чем С++ > и гораздо мощнее.
Не вижу тучи проектов на этом супермощном языке. А лет ему немало уже —
я его в 2001 еще смотрел (если не раньше).
> C>Это _использование_ C через проксики, а не полноценная > C>интероперабельность с ним. А то так можно взять SOAP и сказать, что с > C>помощью него можно с С интероперировать. > Можно, а что вас не устраивает, кстати?
1. Скорость.
2. Уровень интеграции.
3. Трудоемкость сложной интеграции.
> C>Битовые поля? union'ы? #pragma pack? Поддержка __stdcall, __fastcall и > C>других calling conventions. Поддержка сторонних аллокаторов. > ЭЭ... foreign import stdcall в хаскеле? Ну и я там ссылку кидал на > модуль Foreign.*
А __thiscall с __fastcall'ом? В доке по FFI написано про всего две
конвенции — "по умолчанию" и stdcall. Я кстати еще про распространенную
pascal-конвенцию забыл.||*||*
> Что мешает _кому угодно_ завести такую поддержку?
Так ведь не сделали? Значит, что-то мешает.
> Да, C# движется, пока не дойдет до F# > а F# движется пока не дойдет до окамла.
> О чем вы там вообще? Что еще за JIT и каким образом это относится к > окамлу? > Ну и мельчайшие подробности. Вы откуда это взяли?
Кхм. Вообще-то JIT — это Just-In-Time компляция, не знать этого стыдно
(кстати, в OCaml'е оно есть для байт-кодов). И читайте всю тему, а не
одно сообщение.
> C>Не быстрее. Просто иногда помогает отсутствие алиасинга (о котором в > С++ > C>можно сказать компилятору с помощью слова restrict). > Бум! > все, приехали. просто отсутствие aliasing и то фигня — просто скажи > restrict и будет все в ажуре.
Ну да, если я уверен, что в моем коде нет алиасинга, то я могу дать хинт
оптимизатору с помощью атрибута restrict.
Типа так:
void some_func(restrict int *a, restrict int *b)
{
while(*b!=0)
*b++=*a++;
}
Здравствуйте, minorlogic, Вы писали:
M>Давайте не на личности. ?
Ну, вы же первый начали...
Зы обвинение в запрыгивании внутрь for(), в приличном обществе бьют клавиатурой по лицу
Если, конечно, for() не безусловный...
M>Я уже писал, goto это НЕЯВНАЯ управляющая конструкция ,
Увы, я не читал книгу, где вы это писали. Страуструпа читал, Вирта читал, даже Кнута читал, а вас — нет. Не удосужитесь подкинуть цитатку?
M>чтобы понять чем она занимается надо отслеживать логику переходов.
...в данном куске кода логика лежит на поверхности.
Переход существует ВСЕГДА — безо всяких условий.
Думаю, этого трудно не заметить...
А на вопрос вы опять не ответили. А вопрос, напоминаю, был: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
E>>Стрельба из рогатки, кстати, отнюдь не безобидное занятие и запрещается не безосновательно. DEA>...переход улицы, кстати, тоже. Но иногда надо.
На моих глазах школьный товарищ дорогу перебегал в неположенном месте. Жив остался, но получил пять переломов таза. Так что рекомендовать кому-нибудь переходить дорогу в неположенном месте я не могу.
E>>А если ты используешь goto по принципу "запретный плод сладок". DEA>Ну я вроде бы обосоновал почему я применяю goto в данном случае... DEA>Просто я не испытываю по этому поводу комплексов и применяю его там, где оно подходит
Может быть потому, что не нашел нормального способа от него избавиться?
DEA>А от вас, я тоже хотел бы услышать ответ на вопрос: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
? Здесь есть один тонкий момент. Разбираться в чужом коде не зная алгоритма и предлагать способы "выпрямления" этого кода не просто и может потребовать некоторого времени.
DEA>Кстати, вот еще один пример моего goto-любства: http://www.rsdn.ru/Forum/Message.aspx?mid=1470445
Здравствуйте, reductor, Вы писали:
R>Ну если требовательные, тогда конечно С++ нельзя, он медленный — куча тормозит из-за фрагментации. Да и на просто аллокацию у него времени уходит раза в три больше, чем у окамла.
Моя долго плакаль...
Почему-то упускаются из виду две вещи. В C++ очень много объектов -- автоматические переменные. Размещаются в стеке и автоматически разрушаются. Никакой фрагментации. Никакого оверхеда.
В действительно тебовательных к скорости приложениях (real-time системах) вообще может не применяться выделение памяти во время работы -- вся память выделяется при старте и затем только используется.
R>Давайте уже договоримся — нечего делать в прикладном софте ручному управлению памятью.
Не договоримся.
R>Сколько раз увидишь человека, который пишет ядро на С++, столько раз и убей его R>Важно другое. Вот например то, что в cyclone
Сколько раз увидишь человека, который пишет ядро на cyclone -- сфотографируй его, возьми автограф и разошли фото всем друзям. С подписью: "вот тот, кто пишет ядро на cyclone"!
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Может быть потому, что не нашел нормального способа от него избавиться?
Для меня goto — точно такой же инструмент как и другие выражения языка. Со своими плюсами и минусами. О которых я очень неплохо осведомлен. Буде встретятся еще неизвестные мне — я об этом сразу же узнаю — тк код который пишу, я ВСЕГДА тестирую.
E>Разбираться в чужом коде не зная алгоритма
Ну, я же писал: "реализация бинарного алгоритма возведения в степень больших чисел".
Описание можно найти у Кнута, Седжвика, и еще куче книжек...
ЗЫ. Когда приходят к нам наниматься, я прошу кандидата с написать с нуля любой алгоритм сортировки. Как ни странно, встречаются экземпляры, которые не могут. И их достаточно много.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
E>>Разбираться в чужом коде не зная алгоритма DEA>Ну, я же писал: "реализация бинарного алгоритма возведения в степень больших чисел".
Ну нет у меня под рукой ни Кнута, ни Седжвика, ни других книжек по алгоритмам сейчас DEA>Описание можно найти у Кнута, Седжвика, и еще куче книжек...
ЗЫ. Когда я учу студентов комментировать код, я говорю, что если они используют какой-то алгоритм, взятый откуда-то, то пусть указывают в комментариях точный источник: издание, главу и, желательно, страницу.
DEA>ЗЫ. Когда приходят к нам наниматься, я прошу кандидата с написать с нуля любой алгоритм сортировки. Как ни странно, встречаются экземпляры, которые не могут. И их достаточно много.
А на какую позицию они претендуют?
Я бы, например, с ходу бы задумался, прежде чем вспомнить какую-нибудь сортировку. А потом бы еще покурил, прежде чем написал код. И все равно не был бы уверен в корректности его работы без тестов. Просто потому, что писать реализации алгоритмов сортировки мне приходилось только во время учебы.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, minorlogic, Вы писали:
M>>Давайте не на личности. ? DEA>Ну, вы же первый начали... DEA>Зы обвинение в запрыгивании внутрь for(), в приличном обществе бьют клавиатурой по лицу DEA>Если, конечно, for() не безусловный...
Я тогда не понял , что это ваш код ...
M>>Я уже писал, goto это НЕЯВНАЯ управляющая конструкция , DEA>Увы, я не читал книгу, где вы это писали. Страуструпа читал, Вирта читал, даже Кнута читал, а вас — нет. Не удосужитесь подкинуть цитатку?
лень искать , гдет в этой ветке про return писал.
M>>чтобы понять чем она занимается надо отслеживать логику переходов. DEA>...в данном куске кода логика лежит на поверхности. DEA>Переход существует ВСЕГДА — безо всяких условий. DEA>Думаю, этого трудно не заметить...
это заметно , но надо опять вверх лезть и смотреть инициализацию переменных цикла
DEA>А на вопрос вы опять не ответили. А вопрос, напоминаю, был: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
Чуть выше уже привели пример кода рещшающий вопрос , и выглядит на порядок красивее.
Здравствуйте, minorlogic, Вы писали:
DEA>>А на вопрос вы опять не ответили. А вопрос, напоминаю, был: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет". M>Чуть выше уже привели пример кода рещшающий вопрос , и выглядит на порядок красивее.
reductor wrote:
> C>Игры, требовательные десктопные приложения, системный софт. > Ну если требовательные, тогда конечно С++ нельзя, он медленный — куча > тормозит из-за фрагментации. Да и на просто аллокацию у него времени > уходит раза в три больше, чем у окамла.
Хватит уже бред нести про фрагментацию. Надоело уже, честное слово, — вы
не знаете даже о чем говорите. С++ную кучу можно обвинять в
тормознутости, но уж точно не в фатальной склонности к фрагментации.
Так же, следует знать, что в С++ есть НЕ ТОЛЬКО объекты в куче.
> Давайте уже договоримся — нечего делать в прикладном софте ручному > управлению памятью. > Это очень дорого. Во всех смыслах.
Да? Я вот так не считаю — ручное управление требует некоторой
аккуратности, но вполне окупается за счет более мальениких и быстрых
программ.
> C>RTFM: http://www.memorymanagement.org/ > Ну вот только не нужно этой пошлости. > Конкретно скажите у какого типа GC какие паузы и тп.
У любого современного GC есть паузы при полной сборке — из-за того, что
GC нужно остановить мутатор на время сканирования working set'а. Есть
техники, которые позволяют эту паузу уменьшить, но они требуют
дополнительного затрата времени и памяти.
Паузы GC особенно хорошо заметны при работе с IDEA или ReShaper на
больших проектах.
> И что где дороже того, что в С++ получается. > Ну вот пусть в том же окамле. А то там Лерой как-то выкладывал > калькуляцию по этим вещам, хочу сравнить вашу и его.
ОК. Давайте сравним время создания/удаления автоматических объектов и
ваш GC. Хотите?
> Абсолютно неинтересной невозможности компактнуть хип правильно сказать. > "интересных преобразований"
Еще раз: в С++ можно НЕ ДОПУСКАТЬ фрагментации кучи. Это делается за
счет более медленных алгоритмов распределения памяти, что компенсируется
наличием очень быстрых автоматических объектов.
> C>А что, вы один должны гнать sales-talk десятилетней давности про GC? > Чооо? эт где?
Прочитайте свои слова про всесильность GC...
> Вот этого я кстати не понимаю. Даже если дам ссылку на докуменртацию > по FFI, то что? > Что вы этим хотели сказать?
Вот есть у меня структура:
struct MyStruct
{
int a, b, c;
std::string name;
};
Мне надо поместить ее инстанс в shared-memory. То есть два (или более)
процесса будут видеть один и тот же объект, но из разных адресных
пространств. Причем виртуальный адрес этого объекта в разных процессах
будет разный.
В С++ это делается достаточно просто — объект просто создается внутри
блока разделяемой памяти, а указатели внутри объекта представляются в
виде смещений относительно начала блока. При этом скорость доступа будет
лишь немного медленнее обычной.
> Причем про shared memory непонятно — как это относится к мемори > менеджменту-то?
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Уфф, о чем это я? Мне же через три дня сдавать редактор конфигурационных файлов в формате XML, с драг-н-дропом и проперти-гридом, а там еще конь не валялся, что я тут делаю? Раскланиваюсь, не судите слишком строго...
Да нет, Глеб, все супер. И все так и есть. В принципе.
Нужно только понимать, что для каждой задачи нужен свой язык. Где-то функциональные языки рулят неимоверно. Когда таких задач станет большинство, тогда и эти языки будут мейнстримом. Хотя, скорее, в существующие императивные языки будут добавлены лучшие качества функциональных.
Пока же, к примеру, есть rsync, написанный на C, и unison, на OCaml. Rsync я могу использовать практически везде (даже на HP NonStop-ах). А unison -- только на мейнстримовых платформах. Вот и толку мне сейчас от OCaml-а. Столько же, сколько от Lisp-а. Это если брать текущий момент. А что будет дальше -- поживем, увидим
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Нужно только понимать, что для каждой задачи нужен свой язык.
Да, да, да! Так и есть! И можно а) выбрать его из всего доступного инструментария — (Питоны, ОКамлы, ХАскели, Перлы, и Явы, C и C++, естественно) или б)реализовать на единственном языке, который знаешь от и до. Мне вариант а) больше импонирует. E>Где-то функциональные языки рулят неимоверно. Когда таких задач станет большинство, тогда и эти языки будут мейнстримом. Хотя, скорее, в существующие императивные языки будут добавлены лучшие качества функциональных.
E>Пока же, к примеру, есть rsync, написанный на C, и unison, на OCaml. Rsync я могу использовать практически везде (даже на HP NonStop-ах). А unison -- только на мейнстримовых платформах. Вот и толку мне сейчас от OCaml-а. Столько же, сколько от Lisp-а. Это если брать текущий момент. А что будет дальше -- поживем, увидим
Как раз с точностью наоборот. Unix'ы были созданы в американских университетах, и все новые языки появляются в первую очередь именно под юниксами. С инструментальной поддержкой (отладчики, интегрированные среды и т.д) дела обстоят похуже, а вот с поддержкой ОС — никаких проблем. Мало того, мне для полноценных экспериментов с ОКамлом пришлось установить cygwin, вражеский Emacs (для tuareg mode), "скрипя сердцем" привыкнуть к его горячим клавишам, научиться писать Makefile-ы (всю жизнь работал с чем-то типа IDE — Турбо-Паскаль, Борланд С, Дельфи, Визуальная Студия и Сликедит, когнитивный диссонанс по сравнению с Емаксом — ужасный, но оно того стоит).
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Глеб Алексеев, Вы писали:
GZ>Почти все правильно. Основной плюс функциональных языков — это математика. Очень большой плюс. Основной минус функц. языков — это математика.
Отлично сказано ! Афоризм, однозначно. GZ>Слишком на эту математику все завязано. А это не панацея. Большинство коммерческих продуктов — это большое количество сущностей с простейшими алгоритмами. На императиве можно меньше думать и больше делать. В случае функциональных языков для подобных задач приходится думать поболее, что компенсирует то что, во многих случаях, кода на нем пишется меньше. Кроме того, в коммерческой разработке задача работы и адаптации ресурсов компьютеров встречается значительно чаще чем сложные и интересные мат. алгоритмы с мат. формулами.
Возразить нечего. Только есть надежда (несколько наивная), что в определенных пределах я сам могу выбирать задачи, которые мне интересно решать.
eao197 wrote: > > Pzz>Микрософт при этом совершает совершенно героический поступок, поставив > Pzz>все фишки на технологию, которая не была 20 лет обкатана на юниксе... > > Как будто MS-DOS и Windows были обкатаны на Unix-е > И ничего, справились
MS-DOS, так сказать, не добавляет ничего нового. Те немногочисленные
идеи, которые в него все же были заложены, так или иначе на Unix'е были
обкатаны.
Идеи Windows'а были обкатаны на VMS'е. Наверное, это можно считать хоть
и плохой, но заменой. Кроме того, своих идей в Windows'е не так уж и
много. Windows в основном, это не полет фантазии, а тяжкий физический труд.
C# это другое дело. Это все-таки язык программирования. Штука,
нуждающаяся в высокой культуре. А без оной культуры получится очередной
Visual Basic
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Например, из заметных публично, в Civilization IV используется по крайней мере Boost.Python
Интересно, это по этой причине мне так и не удалось построить три чуда за один тур? (Процесс civilization4.exe съедает 2 Гб виртуальной памяти, после чего игра просто закрывается.)
?
Принимается Из недостатков — вызов функции (помним, что слово "inline" компилятор ни к чему особенному не обязывает). Как отсутствие этого недостатка — дублирование кода. Но из-за "мелкости" этой проблемы (дубляж не более чем 10-15 байт) ею пренебрегаем. Но... даже из-за 15 байт жаба душит, но это — субьективное...
Как более серьезный недостаток — ухудшение понимания. В моем варианте — проблемная точка — программист должен "грокнуть" факт что перед началом цикла текущий бит всегда "1" и комментарий это облегчает.
В твоем случае — он должен "грокнуть" функцию "shift_mask" которая находится где угодно, но не в месте вызова. Т.е. программист должен пробраузить к этой функции, сопоставить ее аргументы (и не забыть хытрую ссылку-на-указатель) с аргументами вызова, вернуться назад. И так — два раза. И еще, имя shift_mask такое "describing", что просто ататат.
E>то пусть указывают... точный источник: издание, главу и, желательно, страницу.
Журнал "Монитор" за 19забытый год, N3, стр 25
В данном случае, это "Handbook of Applied Cryptography", алгоритм 14.76
DEA>>ЗЫ. Когда приходят к нам наниматься, я прошу кандидата с написать с нуля любой алгоритм E>А на какую позицию они претендуют?
Программист. Причем, этот тест не влияет на вопрос "принятия". А вот на величину начальной зарплаты и последующую работу — таки да... Непроходимцам поручается самое тупое и неинтересное. По крайней мере поначалу.
E>Я бы, например, с ходу бы задумался, прежде чем вспомнить какую-нибудь сортировку. E>А потом бы еще покурил, прежде чем написал код. И все равно не был бы уверен в корректности E>его работы без тестов.
Ну... у тебя есть контупер со средой (VS7.1) и неограниченное время. (На самом деле "неограниченное" означает полчаса — т.е. я приду и поинтересуюсь результатом а через час — выгоню). Для борландистов, есть Notepad и всепрощающий я, который по первой просьбе скомпилирует код с командной строки при помощи того же MSVC. Или... та же среда программирования. Программируй, отлаживайся — делай че хочешь.
E>Просто потому, что писать реализации алгоритмов сортировки мне приходилось только во время учебы.
Кое-какие вещи надо помнить... Или вспомнить... Или "изобрести"... Неважно.
Просто эта сортировка — одна из простейших проблем. Очень хорошо подходит для тестов. По крайней мере, она показывает насколько кандидат умеет пользоваться мозгами в применении к программированию.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, Pzz, Вы писали:
Pzz>Я бы написал сортировку пузырьком, чтобы не рисковать в стрессовых условиях собеседования.
И прошел бы. А вот за "quicksort", подвергся бы жестоким нападкам на тему "А докажи что это работает". Ведь это не тест на "память", а тест на умение пользоваться мозгами. И тебе (не без оснований заподозренному в "зубрежке" или "абсолютной памяти") пришлось бы доказывать... Если у тебя "абсолютная память", то доказал бы... или, если додумался "зазубрить" и доказательство... Педантичность такого рода тоже приветствуется.
Pzz>Опыт показал, что такой подход позволяет очень хорошо узнать человека как специалиста,
Именно. А насчет идеи "набора задач" — спасибо. Примем на вооружение.
__________
16.There is no cause so right that one cannot find a fool following it.
? DEA>Принимается Из недостатков — вызов функции (помним, что слово "inline" компилятор ни к чему особенному не обязывает). Как отсутствие этого недостатка — дублирование кода. Но из-за "мелкости" этой проблемы (дубляж не более чем 10-15 байт) ею пренебрегаем. Но... даже из-за 15 байт жаба душит, но это — субьективное...
А вот это еще вопрос. Интересно было бы сравнить оба варианта на производительность. Хотя бы в VS C++ и GNU C++.
DEA>Как более серьезный недостаток — ухудшение понимания. В моем варианте — проблемная точка — программист должен "грокнуть" факт что перед началом цикла текущий бит всегда "1" и комментарий это облегчает.
Кстати, я бы вообще вынес это в отдельную функцию, вроде find_starting_point, чтобы while-ом не загромождать логику.
DEA>В твоем случае — он должен "грокнуть" функцию "shift_mask" которая находится где угодно, но не в месте вызова. Т.е. программист должен пробраузить к этой функции, сопоставить ее аргументы (и не забыть хытрую ссылку-на-указатель) с аргументами вызова, вернуться назад. И так — два раза. И еще, имя shift_mask такое "describing", что просто ататат.
А в чем проблема? Задача в shift_mask -- это сдвинуть бит. Обзови еще shift_mask_bit. И заметь, выход из do..while стал гораздо понятнее: когда сдвигать больше нечего.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
? DEA>>Принимается Из недостатков — вызов функции (помним, что слово "inline" компилятор ни к чему особенному не обязывает). Как отсутствие этого недостатка — дублирование кода. Но из-за "мелкости" этой проблемы (дубляж не более чем 10-15 байт) ею пренебрегаем. Но... даже из-за 15 байт жаба душит, но это — субьективное...
E>А вот это еще вопрос. Интересно было бы сравнить оба варианта на производительность. Хотя бы в VS C++ и GNU C++.
Думаю, твой был на чуть-чуть хуже. Но это чуть-чуть во всех смыслах — ниже уровня погрешности. Разницы-то пара инструкций + код несколько вырос. Именно поэтому я написал "принимается". По крайней мере, на алгоритмах типа RSA или Diffie-Hellman key exchange эта разница вообще не будет видна.
E>Кстати, я бы вообще вынес это в отдельную функцию, вроде find_starting_point, чтобы while-ом не загромождать логику.
...точно ту же функцию выполняет и "while". Но, так как он не используется повторно, то он лишен чести вынесения в отдельную функцию. А великую честь смысловой нагрузки может выполнить и комментарий (который я разместил несколько нестандартном месте, и написал некорректно) Надо было написать "skip to the highest '1' bit".
E>А в чем проблема? Задача в shift_mask -- это сдвинуть бит. Обзови еще shift_mask_bit.
Как тебе сказать... Я привык анализировать код "линейно". То есть: сверху и вниз. Как текст.
"Прыжки" вроде вызова функций рвут мне контекст. B еще, возникает вопрос: "а не вызывается ли эта функция где-то еще". Опровержение этого факта (пренебрежение этим шагом пару раз мне дорого стоила) займет пару минут + "переключение" в другой контекст (поиск файле, а если это .h-файл, то и во всем source tree).
E>И заметь, выход из do..while стал гораздо понятнее: когда сдвигать больше нечего.
Да. Не прибавить ни отнять.
Но... Прежде ты должен понять-принять-определить (те "грокнуть") независимую сущность. Имя этой сущности — функция shift_mask() с данным (не забываем об оверлоаде) набором аргументов.
ЗЫ. "Грокнуть" это из "Чужеземец в чужой стране" Хайнлайна. Must read
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
E>>А вот это еще вопрос. Интересно было бы сравнить оба варианта на производительность. Хотя бы в VS C++ и GNU C++. DEA>Думаю, твой был на чуть-чуть хуже. Но это чуть-чуть во всех смыслах — ниже уровня погрешности. Разницы-то пара инструкций + код несколько вырос. Именно поэтому я написал "принимается". По крайней мере, на алгоритмах типа RSA или Diffie-Hellman key exchange эта разница вообще не будет видна.
Не уверен. При нынешних оптимизирующих компиляторах я бы не стал что-либо утвержать без замеров.
E>>Кстати, я бы вообще вынес это в отдельную функцию, вроде find_starting_point, чтобы while-ом не загромождать логику. DEA>...точно ту же функцию выполняет и "while". Но, так как он не используется повторно, то он лишен чести вынесения в отдельную функцию. А великую честь смысловой нагрузки может выполнить и комментарий (который я разместил несколько нестандартном месте, и написал некорректно) Надо было написать "skip to the highest '1' bit".
А теперь представь, если бы ты так функцию обозвал: skip_to_highest_1bit(...) -- ни комментариев, ни места лишнего, ни оверхеда в run-time.
E>>А в чем проблема? Задача в shift_mask -- это сдвинуть бит. Обзови еще shift_mask_bit. DEA>Как тебе сказать... Я привык анализировать код "линейно". То есть: сверху и вниз. Как текст. DEA>"Прыжки" вроде вызова функций рвут мне контекст. B еще, возникает вопрос: "а не вызывается ли эта функция где-то еще". Опровержение этого факта (пренебрежение этим шагом пару раз мне дорого стоила) займет пару минут + "переключение" в другой контекст (поиск файле, а если это .h-файл, то и во всем source tree).
Это спорный вопрос. Меня лично функции не напрягают. Особенно количество их вызовов. А вот направление goto -- очень даже.
DEA>ЗЫ. "Грокнуть" это из "Чужеземец в чужой стране" Хайнлайна. Must read
Не, фантастика же давно не Must read. К сожалению
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Не уверен. При нынешних оптимизирующих компиляторах я бы не стал что-либо утвержать без замеров.
Обьясни плз свой оптимизм по поводу любого из вариантов. Заметь, я говорю что и твой и мой варианты по большому счету — эквивалентны. Впрочем, в понедельник я предоставлю результаты (source tree на работе находится).
А мой пессимизм основывается на... моем опыте. Посмотрим что сильнее. Кстати, полных исходников не дам — они — коммерческая тайна.
E>А теперь представь, если бы ты так функцию обозвал: skip_to_highest_1bit(...) -- ни комментариев, ни места лишнего, ни оверхеда в run-time.
Я не понимаю, почему я должен выносить этот кусок в отдельную функцию.
Он (а)он прост и очевиден (для тех кто знает как работать с битами, конечно) (б)используется только в одном месте (б)не требует введения дополнительных переменных. (с)логически является частью этого и только этого алгоритма.
Так, что, поподробнее: какие преимущества?
E>Это спорный вопрос. Меня лично функции не напрягают. Особенно количество их вызовов. А вот направление goto -- очень даже.
Еще раз: функция это ОТДЕЛЬНАЯ, НЕЗАВИСИМАЯ сущность. Она "рвет контекст", и вызывает сомнения в своем предназначении. А еще, поселившись в исходнике, она начинает ЖИТЬ САМА ПО СЕБЕ.
Это означает, что в развесистом исходнике, какой-то совершенно левый индус, которого ты и в лицо не видел, решит задействовать ТВОЮ функцию для СВОИХ целей. Естественно, он, как "грамотный программист" обьявит ее в своем гадюшнике. А потом ТЫ (через полгода), маленько подправив СВОЮ функцию, с удивлением обнаруживаешь что ты(именно ТЫ!!!) ЗАВАЛИЛ БИЛД! Или на тебя свалилась куча БАГОВ.
Итог: полпачки спаленных сигарет, пятиминутка ненависти к индусам и ДЕНЬ РАБОТЫ.
Хочу сказать, слава богу, это произошло не со мной. Но процесс наблюдал "вживую" и воспоминания о нем — самые тягостные.
E>Не, фантастика же давно не Must read. К сожалению
Не буду разубеждать, но имхо, многое теряешь. Например, альтернативный взгляд на многие вещи. И все же, эта вещь Must read, хотя ты и сопротивляешься
Впрочем, фантастика нынешняя и фантастика вообще — вещи мало пересекающиеся.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, minorlogic, Вы писали:
M>Я тогда не понял , что это ваш код ...
Сер, если вы все понимаете со второго раза.... У меня же for безусловный
M>лень искать , гдет в этой ветке про return писал.
А мне, в свою очередь, тоже лень искать что вы где-то-там понаписали. В особенности, учитывая взвешенность и вудумчивость ваших понаписаний в этой ветке..
M>это заметно, но надо опять вверх лезть и смотреть инициализацию переменных цикла
Если у вас в памяти помещаются меньше чем 2(две) строчки кода, то, как вы впомните про лидирующий if в начале блока???? Или будете скроллиться как челнок от закрывающей скобки к открывающей и обратно? Или "любой блок кода длинее чем 2 строчки" тоже масдай и должен искореняться?
Если так, то не проблема — я хоть всю программу в одну строчку помещу — все поместится — благо в C/С++ точка с запятой есть — не питон, чай.
M>Чуть выше уже привели пример кода рещшающий вопрос , и выглядит на порядок красивее.
Этот пример привели не вы. Так что, и разговаривать об этом примере — не с вами.
__________
16.There is no cause so right that one cannot find a fool following it.
Пожалуйста. Никогда не претендовал на "истину в последней инстанции". Более того, за варианты рефакторинга, которые меня (хотя бы) заинтрересуют, сполна отвешу оценками — минусов обещаю не ставить . Но... только за варианты рефакторинга. А то звиздеть здесь многие горазды, а вот код писать... увы...
ЗЫ. Изначально этот код был написан за час. Для С-строк.
Затем, в итоге нескольких отладочных сессий, маленько подправлен (появились '?' и goto).
Затем, как проект сдался, я его отложил в "копилку" и формализовал под итераторы.
Затем, после примерно полугода, у меня возникла блажь выложить его здесь.
__________
16.There is no cause so right that one cannot find a fool following it.
GlebZ wrote: > > Pzz>Тогда уж еще и Биллу Гейтсу — влияние его империи еще сильнее. > Не пойдет. Гейтс — менеджер и финансист. Ему другая премия > полагается(хотя не знаю, нужна ли она ему).
Ну, Страуструп тоже не ученый. Мы же говорили о _влиянии_. Влияние Билла
Гейтса, без сомнения, сильнее.
Здравствуйте, 0xDEADBEEF, Вы писали:
E>>Не уверен. При нынешних оптимизирующих компиляторах я бы не стал что-либо утвержать без замеров. DEA>Обьясни плз свой оптимизм по поводу любого из вариантов. Заметь, я говорю что и твой и мой варианты по большому счету — эквивалентны. Впрочем, в понедельник я предоставлю результаты (source tree на работе находится).
Да дело в том, что недавно в темах "C++ Culture" (и некоторых других) я сделал несколько примеров на C++ с замерами производительности. Речь шла о возврате из функций объектов по значению или ссылке, а так же передачу в функцию объектов по ссылкам или значению. Так вот интересные результаты там получались. Посмотри, например, одна ветка обсуждения начинается здесь: Re[15]: С++ culture
-- там передача объектов по значению оказывается эффективнее. Так что гадать о предполагаемой производительности особенно не хочется.
DEA>А мой пессимизм основывается на... моем опыте. Посмотрим что сильнее. Кстати, полных исходников не дам — они — коммерческая тайна.
Да и не надо, у меня своих -- хоть залейся
E>>А теперь представь, если бы ты так функцию обозвал: skip_to_highest_1bit(...) -- ни комментариев, ни места лишнего, ни оверхеда в run-time. DEA>Я не понимаю, почему я должен выносить этот кусок в отдельную функцию. DEA>Он (а)он прост и очевиден (для тех кто знает как работать с битами, конечно) (б)используется только в одном месте (б)не требует введения дополнительных переменных. (с)логически является частью этого и только этого алгоритма. DEA>Так, что, поподробнее: какие преимущества?
Читабельность. Мне не нравится подход, что код нужно выделять в функцию, если он используется хотя бы в двух местах. Мне нравится разделение кода на слои. Тогда вызов функции skip_to_highest_1bit() показывает читателю umodexp, что здесь происходит поиск старшего не нулевого бита. Но не опускает на уровень реализации этого поиска. Если читатель захочет узнать, как это делается, он найдет skip_to_highest_1bit и все увидит. А в твоем варианте ему сразу подсовывают реализацию, через которую ему в любом случае нужно будет пройти.
Ну и еще одно гипотетическое преимущество. Т.к. skip_to_highest_1bit() -- это другой слой логики, то этот слой оказывается изолированным от места его использования. Что позволит нам, при необходимости:
— сменить реализацию skip_to_highest_1bit() на более эффективную или по каким-то другим причинам (разбавить ее assert-ами или отладочными печатями, к примеру);
— сделать ее публичной и использовать ее в других местах.
E>>Это спорный вопрос. Меня лично функции не напрягают. Особенно количество их вызовов. А вот направление goto -- очень даже. DEA>Еще раз: функция это ОТДЕЛЬНАЯ, НЕЗАВИСИМАЯ сущность. Она "рвет контекст", и вызывает сомнения в своем предназначении. А еще, поселившись в исходнике, она начинает ЖИТЬ САМА ПО СЕБЕ.
DEA>Это означает, что в развесистом исходнике, какой-то совершенно левый индус, которого ты и в лицо не видел, решит задействовать ТВОЮ функцию для СВОИХ целей. Естественно, он, как "грамотный программист" обьявит ее в своем гадюшнике. А потом ТЫ (через полгода), маленько подправив СВОЮ функцию, с удивлением обнаруживаешь что ты(именно ТЫ!!!) ЗАВАЛИЛ БИЛД! Или на тебя свалилась куча БАГОВ.
Не понимаю сути высказанной проблемы? Если skip_to_highest_1bit() объявлена и реализована только в твоем cpp-файле как static или в анонимном пространстве имен, то как индус сможет ее поиспользовать в другом контектсе? А если skip_to_highest_1bit() не static и не член анонимного пространства имен, или вообще объявлена в h-файле -- то о чем вообще речь идет?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
achp,
> ПК>Например, из заметных публично, в Civilization IV используется по крайней мере Boost.Python > > Интересно, это по этой причине мне так и не удалось построить три чуда за один тур? (Процесс civilization4.exe съедает 2 Гб виртуальной памяти, после чего игра просто закрывается.)
Есть устойчивое подозрение, что из-за части ".Python". Впрочем, это всего лишь подозрение...
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
reductor wrote:
> C>Это создает проблемы с расшареной памятью — может возникнуть race > C>condition с другим процессом. > Сразу видно человека, который не любит теорию. Это кстати и к > сканированию памяти относится.
Я вам уже говорил, что знаю функционирование GC в мелочах. Вообще,
читайте соседнюю тему.
> C>С++/CLI или Boehm GC — для тех кому это нужно. В большинстве случаев GC > C>_не_ нужен. > Знаете, я вам вот что скажу. GC — это вещь фундаментальная для языков > программирования. Она или есть или ее не может быть. В с++ — не может. > Boehm проблем не решает как организационно, так и с производительностью.
Ну почему же, Mono вполне успешно живет с Boehm GC уже пять лет.
> ну дайте же мне уплотняющий GC для C++ > дайте tracing copying incremental mark-n-sweep GC, пусть он будет > двадцатилетней давности
Смотрите tracking_ptr.hpp в xpressive. Там простой mark-and-sweep.
> C>Это не требует GC. Консервативный GC ведь вам не нравится, а точный GC > C>тянет за собой слона. > Не тянет. Если это не С++
Смотрите соседнюю тему. Специально создал для обсуждения влияния точного GC.
> C>Только не в языках с GC. Там это норма. > в языках с GC норма — руками освобождать ресурсы?
Да. Просто ресурсами являются открытые файлы, сетевые соединения,
элементы GUI и т.п. GC работает только с памятью.
Предположим, что у нас есть объект, в одном из полей которого лежит
открытый файл. Когда этот файл будет закрыт в случае использования GC?
> C>Простите, но связь между этими двумя понятиями — одно из самых больших > C>преимуществ. И вы после этого говорите, что знаете С++???? > Я там вам выше уже все написал про продажу прошлогоднего снега.
RTFM про RAII.
> А вот нормальный GC в С++ невозможен. А у других он просто есть.
Для С++ он просто не нужен.
> C>Нет. В Cyclone нет деструкторов с С++ной семантикой вызова. > да вы что. серьезно? чего еще там нет?
Много чего другого. А вы вместо зубоскальства могли бы и ткнуть пальцем
в доку.
> C>Да (достижение, хотя и не уникальное). Как мне такое сделать в > OCaml? Вы > C>*подумайте* как это сделать, и что это за собой влечет для GC. > Что, как отщипнуть от готового буфера кусок? написать функцию new?
Нет, как разместить объект в памяти, выделенной каким-то механизмом,
отличным от "родного".
Вы так и не ответили на простейший вопрос — как мне создать OCaml-объект
так, чтобы он лежал в shared memory. Я показал как это делается в С++ —
теперь ваша очередь.
> А че для камловского GC это влечет? по-моему, вообще ничего. А по-вашему?
Кучу тараканов.
> C>Можно. Смотрите tracking_ptr.hpp из xpressive в Boost'е, например. В > C>xpressive используется простой _точный_ GC. > Вы видимо принципиально не понимаете о чем вообще речь. > Что со своими аллокациями я могу разобраться, я в курсе. Но речь не > обо мне, а о С++ > и о чужих объектах с адресной арифметикой и прочим говном.
Ну так если объекты чужие — то пусть и живут как хотят, это их личное
дело. Я говорю про возможность писать код так, чтобы можно было
использовать точный GC. И даже привожу пример как это сделано в реальном
примере.
> C>А нафига это в wxWidgets нужно? Там вполне хватает ручного управления > C>памятью. > НЕТ. МНЕ не хватает. Я не хочу ничем управлять и создавать объекты в > строгой последовательности. > хочу красивой жизни как в нормальных средах.
Время жизни и жизненный цикл GUI-объектов в wxWidgets задается системной
GUI-библиотекой. В частности, в многих оконных средах нельзя создавать
GUI-объекты без родителя или менять родителя уже созданных объектов.
Так же обычно нельзя передавать объекты между потоками и т.п. Это и
влечет ограничения wxWidgets. И никакой GC этому не поможет.
Можете сделать эксперимент — закомментировать содержимое всех
деструкторов в wxWidgets и добавить Boehm GC. И убедиться, что ничего не
будет работать (и вовсе не из-за утечек памяти).
> C>Как мне в OCaml перегрузить оператор обращения к члену структуры? > Оператор. В окамле операторы — это просто функции. > Но вообще, даже без просто определения функции: > http://caml.inria.fr/pub/docs/manual-camlp4/manual001.html
Это препроцессор, а не языковая фича. В С++ я тоже могу вместо
операторов -> использовать функцию dereference. Будет тоже самое, но вы
тут первый начали кричать, что нужны фичи языка.
> Что вы там говорили про свое программирование на окамле? не повторите? > Вы на нем программировали и на хаскеле еще и решили, что они — так себе?
Нет, решил что мне оно не надо — не решает практических проблем.
> Это у вас странное представление как о GC так и об окамле с хаскелем. > И вы в упор не видите проблем, которые не только вам, но и всем вокруг > создает С++ и весь этот закат солнца вручную.
Ну да. Закат солнца вручную в виде С/C++ создал нам проблемы в виде
почти всех современных операционных систем, прикладных программ и
остального софта. Языки с GC пока только робко пробиваются в эту область.
> Вообще здорово. А че мешает? Никогда вот delete не вызываю.
На конкретный пункт, пожалуйста.
> C>1. Скорость. > C>2. Уровень интеграции. > C>3. Трудоемкость сложной интеграции. > Скорость чего? врапперов?
SOAP-wrapper'ов. Оно в тысячи раз медленнее, чем прямой вызов.
> C>Так ведь не сделали? Значит, что-то мешает. > А еще не сделали оператор delete, наверное что-то мешает > и auto_ptr
Так, значит полноценной интероперабельности с реальным софтом на С у нас
в FFI нет. Так и запищем...
> C>Кхм. Вообще-то JIT — это Just-In-Time компляция, не знать этого стыдно > C>(кстати, в OCaml'е оно есть для байт-кодов). И читайте всю тему, а не > C>одно сообщение. > @#$%@#$% я знаю что такое JIT, я не понял какого хрена он делает в > разговоре об окамле и его GC > и тему не хочу читать. я и так слишком много всего прочитал уже > лишнего и глупого.
В той теме разговор шел о Java, так что там поднималась и тема JITа.
Почитайте всю тему, наконец. То что там написано про GC точно так же
применимо и к OCaml.
> C>Ну да, если я уверен, что в моем коде нет алиасинга, то я могу дать > хинт > C>оптимизатору с помощью атрибута restrict. > Я в общем-то желаю вам программировать на С++ как можно дольше. Мне > кажется это правильно вообще, да.
Ну да, С++ — это не "выучить за два дня". На нем надо уметь писать — и
не каждому это доступно.
GlebZ wrote:
> C>Промышленное КОП появилось с появлением VB. > Вопрос на засыпку, а ты можешь описать разницу между модульностью и > компонентностью? Этот вопрос настолько узкий, что я подчас сам не > понимаю этой разницы.
Компонентнгсть все же более узкое понятие. Компонент — это независимый
кусок функциональности, который можно переиспользовать отдельно.
Модуль — это уже менее строгое понятие. Например, один компонент может
состоять из нескольких модулей.
> C>И фактически в области > C>визуального программирования и осталось. > Нет. В честь чего? COM объекты, которые безусловно компонентны не > являются областью компонентного программирования. Так же как и на их > основе DCOM.
COM-объекты все же НЕ компоненты, это скорее один из вариантов
переносимого ООП. На основе COM уже можно сделать компонентную системы
(ActiveX), но вот сами COM-объекты еще ей не являются.
> C>Влияния Вирта тут я уже не вижу > C>- скорее развитие логически шло от визуальных контролов на формах к их > C>представлению в виде отдельных пакетов. > Да нет. Тут как раз именно Вирт был впереди планеты всей. На вопрос > является ли наш постылый Oberon компонентным языком, можно ответить > что да, является. Правда в несколько интересном формате, но это факт.
Я бы сказал, что он является модульным, но не компонентным. Например, в
визуальных компонентных языках дошли до, не имеющего аналогов в Обероне,
design-time'а и визуального биндинга свойств. Причем еще в ранних 90-х.
Здравствуйте, Cyberax, Вы писали:
C>Компонентнгсть все же более узкое понятие. Компонент — это независимый C>кусок функциональности, который можно переиспользовать отдельно.
Я бы сказал так, компонент — кусок функциональности использовании которого не требует перекомпиляции.
C>Модуль — это уже менее строгое понятие. Например, один компонент может C>состоять из нескольких модулей.
Точно так же и компонент может состоять из нескольких компонент. Модуль требует перекомпиляции при компиляции используещего кода.
Но вообще компонентность — несколько маркетинговая вещь. Проблема в том, что обычная dll windows также является компонентом. Конечно, там проблем до фигищи типа проблемного контракта и dll-hell, но все условия для компонента она выполняет.
C>COM-объекты все же НЕ компоненты, это скорее один из вариантов C>переносимого ООП. На основе COM уже можно сделать компонентную системы C>(ActiveX), но вот сами COM-объекты еще ей не являются.
Нет. ActiveX — всего лишь стандарт наличия COM интерфейсов между сервером и клиентом для визуальных компонентов. COM — компонентен. Особенно при позднем связывании.
C>Я бы сказал, что он является модульным, но не компонентным. Например, в C>визуальных компонентных языках дошли до, не имеющего аналогов в Обероне, C>design-time'а и визуального биндинга свойств. Причем еще в ранних 90-х.
При использовании модулей Oberona в частности на Oberon OS(не помню об остальном возможно и без него, давно читал) перекомпиляция не требуется. А это значит, что Oberon — компонентен. Просто у меня такое впечатление, что в те времена об этом никто не знал.
Здравствуйте, Cyberax, Вы писали:
C>Много чего другого. А вы вместо зубоскальства могли бы и ткнуть пальцем C>в доку.
C>Нет, как разместить объект в памяти, выделенной каким-то механизмом, C>отличным от "родного".
C>Вы так и не ответили на простейший вопрос — как мне создать OCaml-объект C>так, чтобы он лежал в shared memory. Я показал как это делается в С++ — C>теперь ваша очередь.
Боюсь, что конкретного ответа от reductor-а ты не дождешься. Как показывают обсуждения с его участием -- это не в его стиле. А жаль, на некоторые вопросы очень хотелось бы услышать ответы.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Поскльку я уже сказал, что мне слишком дорого время, чтобы тратить его на бессмысленные и беспощадные флеймы непонятно о чем и чтобы не повторяться, просто сделаю несколько общих замечаний.
1. Вы так и не прочитали как работает GC у O'Caml И почему к нему не относится то, что относится к GC у Java и MONO
2. Вы так и не прочитали что такое regions у cyclone и почему к нему не относится то, что вы говорили о ручном освобождении как памяти, так и прочих ресурсов.
3. Вы продолжаете смешивать в одну кучу (не хип, а просто кучу) свойства языка и архитектурные решения конкретных приложений, синтаксис языков и возможности стандартной или нестандартной библиотеки некоторых языков и компиляторов.
4. Почему-то вы не замечаете возможности не только в других языках, а даже в С++ разделить управление памятью и другими ресурсами и возможности реализации этого через те же монады и регионы (некоторые ссылки я кидал).
5. Почему-то считаете, что к ресурсам, предоставляемым операционно системой возможен доступ только из С++ и не хотите узнавать как это сделать из других языков/компиляторов.
6. Отказываетесь рассматривать проблему формально, что порождает потоки бессмысленного и беспощадного текста с обеих сторон, опуская уровень дискуссии ниже плинтуса.
Пожалуй хватит.
Более я не хочу возвращаться к этой теме. Если кому-то удобнее, он может считать меня хоть дилетантом, хоть сумасшедшим, меня это не волнует ни секунды и даже где-то выгодно с т.з. бизнеса.
C>Ну да, С++ — это не "выучить за два дня". На нем надо уметь писать — и C>не каждому это доступно.
Совершенно и полностью согласен. Я бы даже немножко обобщил.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, reductor, Вы писали:
C>>>Только не в языках с GC. Там это норма.
R>>в языках с GC норма — руками освобождать ресурсы? R>>по-моему вы уже заговариваетесь.
ANS>Вообще-то, в словах "управление памятью" напрямую указано, каким именно ресурсом может оперировать сборщик мусора. Но, увы, ресурсом, является не только память программы.
Ну нигде не сказано, что сборщик мусора ограничивает управление другими ресурсами
reductor wrote:
> ANS>Вообще-то, в словах "управление памятью" напрямую указано, каким > именно ресурсом может оперировать сборщик мусора. Но, увы, ресурсом, > является не только память программы. > Ну нигде не сказано, что сборщик мусора ограничивает управление > другими ресурсами
Ресурсы обычно представлены в виде объектов, находящихся в локальных
переменных функции или полях объекта.
Языки с GC обычно не предлагают аналогов автоматического вызова
деструкторов в С++ для стековых переменных, так что ресурсы в локальных
переменных нужно освобождать явно в try..finally (в C# для этого сделали
даже синтаксический сахар в виде using'а).
Если хранить ресурсы в полях объекта, и надеяться на GC и финализаторы —
то получаем resource starvation под нагрузкой (не говоря уж о других
проблемах с финализацией).
reductor wrote:
> Поскльку я уже сказал, что мне слишком дорого время, чтобы тратить его > на бессмысленные и беспощадные флеймы непонятно о чем и чтобы не > повторяться, просто сделаю несколько общих замечаний. > 1. Вы так и не прочитали как работает GC у O'Caml И почему к нему не > относится то, что относится к GC у Java и MONO
Простите, после ваших откровений об уникальном GC в OCaml'е, который
дошел до идеи двух поколений — я не верю, что вы что-то знаете о GC в Java.
> 2. Вы так и не прочитали что такое regions у cyclone и почему к нему > не относится то, что вы говорили о ручном освобождении как памяти, так > и прочих ресурсов.
Еще раз: region inference _элементарно_ делается в С++. Это не требует
НИКАКИХ изменений языка, а просто использованием существующих техник.
Используется из крупных продуктов в Apache 2 (он на С, но на С++ эта
техника переносится без всяких изменений). Читайте: http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutorial-3.html
> 3. Вы продолжаете смешивать в одну кучу (не хип, а просто кучу) > свойства языка и архитектурные решения конкретных приложений, > синтаксис языков и возможности стандартной или нестандартной > библиотеки некоторых языков и компиляторов.
В зеркало посмотрите.
> 4. Почему-то вы не замечаете возможности не только в других языках, а > даже в С++ разделить управление памятью и другими ресурсами и > возможности реализации этого через те же монады и регионы (некоторые > ссылки я кидал).
КАК???? Покажите пример, где будет использоваться _хотя бы_ нормальный
прозрачный refcounted-хэндлер для открытых файлов.
> 5. Почему-то считаете, что к ресурсам, предоставляемым операционно > системой возможен доступ только из С++ и не хотите узнавать как это > сделать из других языков/компиляторов.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> ANS>Вообще-то, в словах "управление памятью" напрямую указано, каким >> именно ресурсом может оперировать сборщик мусора. Но, увы, ресурсом, >> является не только память программы. >> Ну нигде не сказано, что сборщик мусора ограничивает управление >> другими ресурсами
C>Ресурсы обычно представлены в виде объектов, находящихся в локальных C>переменных функции или полях объекта.
C>Языки с GC обычно не предлагают аналогов автоматического вызова C>деструкторов в С++ для стековых переменных, так что ресурсы в локальных C>переменных нужно освобождать явно в try..finally (в C# для этого сделали C>даже синтаксический сахар в виде using'а).
C>Если хранить ресурсы в полях объекта, и надеяться на GC и финализаторы — C>то получаем resource starvation под нагрузкой (не говоря уж о других C>проблемах с финализацией).
Не говорите глупостей, да?
Сделайте уже монаду или итератор для нужных вам ресурсов и в них все разруливайте.
Это не языки не предоставляют, это кому-то хочется свою правоту любым способом доказать.
reductor wrote:
> Сделайте уже монаду или итератор для нужных вам ресурсов и в них все > разруливайте.
И чем мне монада поможет, если мне надо _хранить_ открытый файл в
какой-нибудь структуре?
> Это не языки не предоставляют, это кому-то хочется свою правоту любым > способом доказать.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> Поскльку я уже сказал, что мне слишком дорого время, чтобы тратить его >> на бессмысленные и беспощадные флеймы непонятно о чем и чтобы не >> повторяться, просто сделаю несколько общих замечаний. >> 1. Вы так и не прочитали как работает GC у O'Caml И почему к нему не >> относится то, что относится к GC у Java и MONO
C>Простите, после ваших откровений об уникальном GC в OCaml'е, который C>дошел до идеи двух поколений — я не верю, что вы что-то знаете о GC в Java.
Вот без этого, если можно.
Вы даже не поняля, о чем я там говорил. И о чем здесь тоже.
>> 2. Вы так и не прочитали что такое regions у cyclone и почему к нему >> не относится то, что вы говорили о ручном освобождении как памяти, так >> и прочих ресурсов.
C>Еще раз: region inference _элементарно_ делается в С++. Это не требует C>НИКАКИХ изменений языка, а просто использованием существующих техник.
Вы что, даже не набрали region inference в гугле и не посмотрели ЧТО это?
использование техник, my ass...
наберите, узнаете много нового и интересного.
>> 3. Вы продолжаете смешивать в одну кучу (не хип, а просто кучу) >> свойства языка и архитектурные решения конкретных приложений, >> синтаксис языков и возможности стандартной или нестандартной >> библиотеки некоторых языков и компиляторов.
C>В зеркало посмотрите.
Хамите, между прочим.
Почитайте все-таки что такое region inference, просто регионы и научитесь делать итераторы и монады для автоматического управления чего угодно.
О, кстати. Иксепшенами тоже научитесь пользоваться.
Тоже замечательная вещь для многих трюков.
Причем, все эти способы работают без "перегрузки операторов"
А так, почитайте еще про комбинаторы.
>> 4. Почему-то вы не замечаете возможности не только в других языках, а >> даже в С++ разделить управление памятью и другими ресурсами и >> возможности реализации этого через те же монады и регионы (некоторые >> ссылки я кидал).
C>КАК???? Покажите пример, где будет использоваться _хотя бы_ нормальный C>прозрачный refcounted-хэндлер для открытых файлов.
Что, мне нарисовать здесь итератор, закрывающий файл когда нужно?
>> 5. Почему-то считаете, что к ресурсам, предоставляемым операционно >> системой возможен доступ только из С++ и не хотите узнавать как это >> сделать из других языков/компиляторов.
C>Как мне разместить объект OCaml в shared memory?
Вызвать shmget через FFI?
Ну и истерика у вас...
Держите себя в руках, пожалуйста.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> Сделайте уже монаду или итератор для нужных вам ресурсов и в них все >> разруливайте.
C>И чем мне монада поможет, если мне надо _хранить_ открытый файл в C>какой-нибудь структуре?
>> Это не языки не предоставляют, это кому-то хочется свою правоту любым >> способом доказать.
C>Ну так покажите.
C>Вот пример на С++: C>
contents <- readFile "test"
-- теперь в contents ленивый список, который будет читать файл по мере надобности.
-- ничего закрывать не нужно, особенно учитывая то, что фактически файл даже еще не открыт.
processData contents -- далее там разберутся, даже не зная откуда эти данные
reductor wrote:
> вы специально чтоли подставляетесь так. > >contents <- readFile "test" >-- теперь в contents ленивый список, который будет читать файл по мере надобности. >-- ничего закрывать не нужно, особенно учитывая то, что фактически файл даже еще не открыт. >processData contents -- далее там разберутся, даже не зная откуда эти данные > > Все, можете сравнивать.
Начнем с такой мааааааааленькой детали, что файл у меня не читается, а
пишется. Ваш ход....
reductor wrote:
> C>Простите, после ваших откровений об уникальном GC в OCaml'е, который > C>дошел до идеи двух поколений — я не верю, что вы что-то знаете о GC > в Java. > Вот без этого, если можно. > Вы даже не поняля, о чем я там говорил. И о чем здесь тоже.
Вы в этом так уверены?
> C>Еще раз: region inference _элементарно_ делается в С++. Это не требует > C>НИКАКИХ изменений языка, а просто использованием существующих техник. > Вы что, даже не набрали region inference в гугле и не посмотрели ЧТО это?
Смотрел, причем очень давно уже.
> C>Используется из крупных продуктов в Apache 2 (он на С, но на С++ эта > C>техника переносится без всяких изменений). Читайте: > C>http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutorial-3.html > Great. Приехали. Выведение регионов вручную.
Сюда еще добавляются умные указатели из С++ и оно становится
[полу]автоматическим. В С++ нет closure'ов, так что выведение получается
очень простым.
> Почитайте все-таки что такое region inference, просто регионы и > научитесь делать итераторы и монады для автоматического управления > чего угодно.
И чем мне поможет последовательная комбинация (она же "монада"), для
_хранения_ и _уничтожения_ ресурса?
> О, кстати. Иксепшенами тоже научитесь пользоваться. > Тоже замечательная вещь для многих трюков.
У меня приведенный код, кстати, полностью exception-safe.
> C>КАК???? Покажите пример, где будет использоваться _хотя бы_ нормальный > C>прозрачный refcounted-хэндлер для открытых файлов. > Что, мне нарисовать здесь итератор, закрывающий файл когда нужно?
Да. Только вот итератор должен сам закрываться _сразу_ _же_, когда
станет "ненужным" (i.e. мусором).
> C>Как мне разместить объект OCaml в shared memory? > Вызвать shmget через FFI?
Вызвал. У меня есть указатель на блок shared memory. Что дальше? Как мне
сказать OCaml'у, чтобы он создал объект в этом блоке (и мне не нужно
туда пихать сериализованые данные).
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> вы специально чтоли подставляетесь так. >> >>contents <- readFile "test" >>-- теперь в contents ленивый список, который будет читать файл по мере надобности. >>-- ничего закрывать не нужно, особенно учитывая то, что фактически файл даже еще не открыт. >>processData contents -- далее там разберутся, даже не зная откуда эти данные >> >> Все, можете сравнивать.
C>Начнем с такой мааааааааленькой детали, что файл у меня не читается, а C>пишется. Ваш ход....
ну ладно, если вы настаиваете, то..
getLazyData >>= writeFile "test"
-- эта конструкция будет писать ленивый список, на другой стороне которого ...
-- а какая, впрочем, разница что там
-- или
withOpenedFile name func = openFile name >>= (\hdl -> func handle >> hClose handle)
-- и потом где угодно вызываете это и отдаете ему функцию на растерзание
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> C>Простите, после ваших откровений об уникальном GC в OCaml'е, который >> C>дошел до идеи двух поколений — я не верю, что вы что-то знаете о GC >> в Java. >> Вот без этого, если можно. >> Вы даже не поняля, о чем я там говорил. И о чем здесь тоже.
C>Вы в этом так уверены?
Да.
C>Смотрел, причем очень давно уже.
Нет.
Все, я прекратил эту тему уже давно.
Всего хорошего. Остальные детали смотрите в документации.
reductor wrote:
> ну ладно, если вы настаиваете, то.. > >getLazyData >>= writeFile "test" >-- эта конструкция будет писать ленивый список, на другой стороне которого ... >-- а какая, впрочем, разница что там >-- или >withOpenedFile name func = openFile name >>= (\hdl -> func handle >> hClose handle) >-- и потом где угодно вызываете это и отдаете ему функцию на растерзание > > Ну?
Уже лучше.
Теперь учтите, что в одной монаде нельзя записать все данные (например,
часть данных потом получим из сети) и нам нужно где-то хранить открытый
файл между записями. Естественно, хранить данные целиком в памяти тоже
нельзя — они могут в нее не поместиться.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> ну ладно, если вы настаиваете, то.. >> >>getLazyData >>= writeFile "test" >>-- эта конструкция будет писать ленивый список, на другой стороне которого ... >>-- а какая, впрочем, разница что там >>-- или >>withOpenedFile name func = openFile name >>= (\hdl -> func handle >> hClose handle) >>-- и потом где угодно вызываете это и отдаете ему функцию на растерзание >> >> Ну?
C>Уже лучше.
C>Теперь учтите, что в одной монаде нельзя записать все данные (например, C>часть данных потом получим из сети) и нам нужно где-то хранить открытый C>файл между записями. Естественно, хранить данные целиком в памяти тоже C>нельзя — они могут в нее не поместиться.
Еще раз — список — _ленивый_
кто-то, читая из него, вызывает вычисление на другой стороне, которое вычисляет данные
data = [1..] -- вообще бесконечный список
или
resources = getFirst : getSecond : getThird : []
они начнут вызываться, только когда их кто-то на другой стороне начнет записывать в файл
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> Еще раз — список — _ленивый_ >> кто-то, читая из него, вызывает вычисление на другой стороне, которое >> вычисляет данные
C>Я это знаю. Однако, надо как-то показать _завершение_ списка.
C>Как это сделать автоматически? Чтобы список сразу завершился, когда на C>него не останется ссылок.
Что вы в дурачка-то играете, в самом деле
конец списка — это []
как оно будет получено, все само завершится
reductor wrote:
> Что вы в дурачка-то играете, в самом деле > конец списка — это [] > как оно будет получено, все само завершится
Я _не_ _хочу_ явно указывать завершение списка (и в С++ это мне не нужно
делать). Представьте, что этот файл — это log-файл, и надо чтобы он
автоматически закрылся когда станет ненужным. То есть когда на список не
останется ссылок.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> Что вы в дурачка-то играете, в самом деле >> конец списка — это [] >> как оно будет получено, все само завершится
C>Я _не_ _хочу_ явно указывать завершение списка (и в С++ это мне не нужно C>делать). Представьте, что этот файл — это log-файл, и надо чтобы он C>автоматически закрылся когда станет ненужным. То есть когда на список не C>останется ссылок.
Тихо, тихо.
Что вы блажите-то, все нормально, успокойтесь
Списочек представляет из себя те данные, которые программочка наша считает
когда данных больше нет, файлик закрывается
reductor wrote:
> Списочек представляет из себя те данные, которые программочка наша считает > когда данных больше нет, файлик закрывается
Как определяется момент, в котором в список больше не будет поступать
данных?
> readFile "test" >>= writeFile "test2" > writeFile "test3" "mama myla ramu" > Никто ничего не закрывает и не открывает, все само.
Я понимаю, что можно открывать/закрывать файл на каждую запись, но мне
это сейчас неинтересно.
> while(i.hasNext()) { stream.write(i.next()); } > после выхода из while все само закрылось.
С чего бы?
Вот такой код:
OutputStream stream = new FileOutputStream(...);
while(i.hasNext()) { stream.write(i.next()); }
вызовет resource starvation в неблагоприятных условиях (объяснить почему
или и так понятно?).
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> Списочек представляет из себя те данные, которые программочка наша считает >> когда данных больше нет, файлик закрывается
C>Как определяется момент, в котором в список больше не будет поступать C>данных?
Данные поставляет наша программа.
Когда у ней их больше нет, она говорит: извини, фигня, вот тебе []
или вот тебе hasNext() = false
>> readFile "test" >>= writeFile "test2" >> writeFile "test3" "mama myla ramu" >> Никто ничего не закрывает и не открывает, все само.
C>Я понимаю, что можно открывать/закрывать файл на каждую запись, но мне C>это сейчас неинтересно.
Это всего лишь иллюстрация почему не требуется указывать что-то руками.
Вы же не видите тут никаких open и close?
Это не потому, что у вас со зрением плохо.
>> while(i.hasNext()) { stream.write(i.next()); } >> после выхода из while все само закрылось.
C>С чего бы?
это визуализация того, так это работает.
хотите вставьте закрытие в итератор, хотите, в ту функцию, которая берет у вас итератор и пишет из него в файл.
хотите — куда-нибудь повыше.
C>Вот такой код: C>
C>OutputStream stream = new FileOutputStream(...);
C>while(i.hasNext()) { stream.write(i.next()); }
C>
C>вызовет resource starvation в неблагоприятных условиях (объяснить почему C>или и так понятно?).
C>Правильно записывается он так: C>
C>И на Haskell'е это будет выглядеть ну асболютно точно так же.
Нет.
lazyData >>= writeFile "test"
когда кончатся данные, все само закроется.
ну или writeFile "test" lazyData
в зависимости от.
lazyData — это вся наша программа.
или наоборот,
withOpenFile "test" ourProgram -- здесь наша программа получает на вход хэндл и пишет в него.
Когда все закончилось, хэндл закроется внутри withOpenFile
Аналогичным образом может работать что угодно, в том числе и аллокация в модуле Foreign
в extData результат будет результат вызова внешней функции, который мы дали пойнтер, создав его на месте. Освобождать его не нужно, он он освободился автоматически по окончанию.
C>А вот на С++ с автоматическими объектами будет выглядеть вот так: C>
Ну сделайте над собой усилие и найдите уже связь между этим и тем, что я вам показал.
Иначе придется записать вас в неизлечимые.
Потому что вы не можете понять такую простую абстракцию.
Кстати здесь я тоже больше не обсуждаю это. надоело.
reductor wrote:
> Данные поставляет наша программа. > Когда у ней их больше нет, она говорит: извини, фигня, вот тебе [] > или вот тебе hasNext() = false
Еще раз, медленно: код, пишуший в файл, не знает точного момента закрытия.
То есть:
void func(FILE *log)
{
//что-то делаем
fprintf(log,"Operation completed\n");
//а нужно ли нам закрыть файл здесь???
}
Точно так же вашу цитату можно переделать, но для памяти:
Объекты использует программа.
Когда они ей больше не нужны, она говорит: извини, фигня, вот delete.
> Это не потому, что у вас со зрением плохо.
Я вижу попытку взять другой сценарий работы.
> C>С чего бы? > это визуализация того, так это работает. > хотите вставьте закрытие в итератор, хотите, в ту функцию, которая > берет у вас итератор и пишет из него в файл. > хотите — куда-нибудь повыше.
Мне ВООБЩЕ не хочется никуда ставить явное закрытие файла. Сам он должен
закрываться когда нужно.
> C>И на Haskell'е это будет выглядеть ну асболютно точно так же. > Нет. > lazyData >>= writeFile "test" > когда кончатся данные, все само закроется.
А когда данные кончаться? Когда запишут конец потока? А когда запишут
конец потока?
> Ну сделайте над собой усилие и найдите уже связь между этим и тем, что > я вам показал. > Иначе придется записать вас в неизлечимые. > Потому что вы не можете понять такую простую абстракцию.
Я прекрасно понимаю вашу идею с потоком. Мне интересно узнать: как
сделать так, чтобы мне НЕ НАДО БЫЛО явно говорить потоку, что он завершен.
Здравствуйте, reductor, Вы писали:
R>Каков, а! R>Ловко перевел тему опять на Вирта. R>Дийкстру не трогает. Боится. И правильно делает. Могут урыть.
Кстати, а может кто-нибудь объяснить феномен того, что рынок альтернативной ОС захватил Линукс, а не какая-нибудь ФриБСД или еще что-нибудь? Может быть это такой подпольный проект МС?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Все, последний раз.
>> C>И на Haskell'е это будет выглядеть ну асболютно точно так же. >> Нет. >> lazyData >>= writeFile "test" >> когда кончатся данные, все само закроется.
C>А когда данные кончаться? Когда запишут конец потока? А когда запишут C>конец потока?
Когда данных больше не будет.
Когда iterator.hasNext() = false
>> Ну сделайте над собой усилие и найдите уже связь между этим и тем, что >> я вам показал. >> Иначе придется записать вас в неизлечимые. >> Потому что вы не можете понять такую простую абстракцию.
C>Я прекрасно понимаю вашу идею с потоком. Мне интересно узнать: как C>сделать так, чтобы мне НЕ НАДО БЫЛО явно говорить потоку, что он завершен.
Ему ничего не надо говорить. Поток представляет данные
внутри потока тот код, который их вычисляет.
который в какой-то момент прекращает это делать и все закрывается.
Не понимаете?
ничем не могу помочь.
Почитайте что такое first-class computations
Хоть что-нибудь почитайте.
reductor wrote:
> C>А когда данные кончаться? Когда запишут конец потока? А когда запишут > C>конец потока? > Когда данных больше не будет.
А когда данных больше не будет?
> Когда iterator.hasNext() = false
В данном примере все просто. А если этот поток используется в десяти
местах в программе (т.е. если это log-файл)? Когда следует закрывать его?
> C>Я прекрасно понимаю вашу идею с потоком. Мне интересно узнать: как > C>сделать так, чтобы мне НЕ НАДО БЫЛО явно говорить потоку, что он > завершен. > Ему ничего не надо говорить. Поток представляет данные внутри потока > тот код, который их вычисляет. > который в какой-то момент прекращает это делать и все закрывается.
Код, который их вычисляет — это была бы вся остальная программа (в
случае log-файла). В общем случае, ее невозможно переписать таким образом.
Здравствуйте, reductor, Вы писали:
R>А вот благодаря скандальности создателя и захватил. R>Это у него не в первый раз такое.
R>Чем громче скандал, тем шире охват
Возможно. Но почему-то мне кажется, что тут съиграли ставки монстров типа IBM-а. Вот и не ясно почему они не поставили на куда более продуманные в архитектурном плане решения.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > R>А вот благодаря скандальности создателя и захватил. > R>Это у него не в первый раз такое. > > R>Чем громче скандал, тем шире охват > > Возможно. Но почему-то мне кажется, что тут съиграли ставки монстров > типа IBM-а. Вот и не ясно почему они не поставили на куда более > продуманные в архитектурном плане решения.
До них сделал ставку GNU Project. *BSD имеют (по мнению FSF и GNU) почти
Public Domain лицензию и имеют на то какие-то идеологические причины.
Линус к тому моменту сделал ядро, которое хотя бы примерно работало, а
лицензия была расплывчатая. Его смогли убедить поменять её на GPL, после
чего стали раскручивать ядро, накладывая на него GNU OS — получилась
почти работоспособная система, которая вся под GPL. С FreeBSD сейчас всё
становится интереснее — там получается на ядре FreeBSD рядом стоят
полная BSD-licensed OS и много GPL ПО — того же, что и под GNU/Linux,
включая gcc, gmake...
Здравствуйте, reductor, Вы писали:
R>Так это ж известно, главное — не мотивировать свои слова, а побольше харизмы. R>Признавать, а тем более исправлять свои ошибки — это для лузеров и лохов. R>Устанавливают правила и пишут историю победители, а как оно там на самом деле — никого не интересует
Вот поэтому в правилах и истории — столько неисправленных, а тем более — непризнанных багов!
E>>А теперь представь, если бы ты так функцию обозвал: skip_to_highest_1bit(...) -- ни комментариев, ни места лишнего, ни оверхеда в run-time. DEA>Я не понимаю, почему я должен выносить этот кусок в отдельную функцию. DEA>Он (а)он прост и очевиден (для тех кто знает как работать с битами, конечно) (б)используется только в одном месте (б)не требует введения дополнительных переменных. (с)логически является частью этого и только этого алгоритма. DEA>Так, что, поподробнее: какие преимущества?
E>>Это спорный вопрос. Меня лично функции не напрягают. Особенно количество их вызовов. А вот направление goto -- очень даже. DEA>Еще раз: функция это ОТДЕЛЬНАЯ, НЕЗАВИСИМАЯ сущность. Она "рвет контекст", и вызывает сомнения в своем предназначении. А еще, поселившись в исходнике, она начинает ЖИТЬ САМА ПО СЕБЕ.
DEA>Это означает, что в развесистом исходнике, какой-то совершенно левый индус, которого ты и в лицо не видел, решит задействовать ТВОЮ функцию для СВОИХ целей. Естественно, он, как "грамотный программист" обьявит ее в своем гадюшнике. А потом ТЫ (через полгода), маленько подправив СВОЮ функцию, с удивлением обнаруживаешь что ты(именно ТЫ!!!) ЗАВАЛИЛ БИЛД! Или на тебя свалилась куча БАГОВ.
DEA>Итог: полпачки спаленных сигарет, пятиминутка ненависти к индусам и ДЕНЬ РАБОТЫ. DEA>Хочу сказать, слава богу, это произошло не со мной. Но процесс наблюдал "вживую" и воспоминания о нем — самые тягостные.
Не понял связи истории с "левым индусом" с данным случаем. (Хотя сама история весьма поучительна.)
Разве нельзя объявить функцию, которая используется только в данном файле, как static?
Никаких проблем с индусами возникнуть не должно. Им эта функция больше недоступна.
Но рассмотрим историю с индусами саму по себе.
Будем исходить из того, что функция должна быть доступна извне.
"Малограмотный" индус скопировал себе старый прототип функции, а мы его потом (после того, как передали индусам?) "поправили". И тут вот и случулась эта неприятность...
Вот на такой случай и существуют модульные языки. И здесь огромное преимущество раздельной компиляции перед независимой.
Они исключают такие ситуации напрочь.
Так что "билд завалила" не только неосторожность программиста, забывшего на минуту о существовании индусов, но его "завалили" также, ИМХО, дефекты языка Си++.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Кодт wrote: > > Pzz>Я как-то был поражен, зайдя в знакомую контору, и обнаружив, что там > Pzz>собралась толпа программистов, и обсуждеает, как им выкрутиться из > Pzz>очередной нетривиальной проблемы, которую поставил перед ними C++. Как > Pzz>эта проблема содержательно соотносилась с решаемой задачей, я так и не > Pzz>понял... > > Не факт, что это язык поставил проблему. Может быть, проблема была в > архитектуре, а специфика мировосприятия программистов перевела её на > рельсы кодирования.
C++, по-моему, не прощает ошибок в проектировании интерфейсов. Причем о
самой ошибке приходится узнавать, когда уже много чего понаписано...
Здравствуйте, eao197, Вы писали:
E>Жалко только, что в универе на изучение Oberon-ов, Smalltalk-ов, Lisp-ов и пр. было гораздо больше времени, чем сейчас, да и новые знания всасывались со страшной силой. А сейчас на это время выкроить тяжело, иногда не успеваешь изучать то, что по работе нужно. E>Вот и vdimas недавно сказал что-то вроде: "Где бы время найти, чтобы с Haskell-ем познакомиться".
Здравствуйте, GlebZ, Вы писали: GZ>Билли — глава корпорации, но не непосредственный создатель продуктов. А среди тех корпораций, которые наиболее повлияли на CS, правильнее назвать IBM. И я думаю, по этому показателю вряд ли кто их переплюнет.
Ну ребята, так не честно. Сравнивать вклад компании с историей в 113 лет в общем-то, не с чем. Возможно? через 300 лет про IBM в учебниках будет написано что-то вроде "небольшая компания эпохи становления Google".
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, minorlogic, Вы писали:
M>>Я тогда не понял , что это ваш код ... DEA>Сер, если вы все понимаете со второго раза.... У меня же for безусловный
M>>лень искать , гдет в этой ветке про return писал. DEA>А мне, в свою очередь, тоже лень искать что вы где-то-там понаписали. В особенности, учитывая взвешенность и вудумчивость ваших понаписаний в этой ветке..
M>>это заметно, но надо опять вверх лезть и смотреть инициализацию переменных цикла DEA>Если у вас в памяти помещаются меньше чем 2(две) строчки кода, то, как вы впомните про лидирующий if в начале блока???? Или будете скроллиться как челнок от закрывающей скобки к открывающей и обратно? Или "любой блок кода длинее чем 2 строчки" тоже масдай и должен искореняться?
DEA>Если так, то не проблема — я хоть всю программу в одну строчку помещу — все поместится — благо в C/С++ точка с запятой есть — не питон, чай.
M>>Чуть выше уже привели пример кода рещшающий вопрос , и выглядит на порядок красивее. DEA>Этот пример привели не вы. Так что, и разговаривать об этом примере — не с вами.
Я кажется обсуждал не свою личность (рад что она вам интерессна), а недостатки которые влекут использование goto. Если вы несогласны, сочувствую, но аргументов пока не слышал.
M>>Прохоже сейчас в универе Science, Technology and Society. Так вот, количество ссылок на публикации является удобным, но очень неточным критерием оценки вклада того или иного ученого в науку.
R>Конечно неточным. Что вообще может быть точным в таком вопросе.
A number of sociologists have attempted to refine citation analysis as a tool to evaluate the importance of particular publications, among other things. In a review of this work, David Edge[1] challenges the idea that citation analysis is a useful tool for studying scientifc communication
A core assumption of citation analysis is that citations represent influence. A citation is supposed to be a reference to a publication that provides important background information. This is an idealization... The scientific paper is typically an argument. Its citations, therefore, are vehicles for furthering its arguments, not necessarily records of influences[2]. Citations are biased toward the types of references that are useful in addressing intended audiences. Meanwhile, informal communication and information that does not need to be cited — or is even best not cited — is all left out of citations... Citation analysis is therefore a poor tool for studying communication and influence[3]
[1] Edge, David 1979: "Quantitative Measures of Communication in Science: A Critical Review". History of Science 17:102-34
[2] Gilbert, Nigel 1977: "Referencing a Persuasion" Social Studies of Science 7:113-22
[3] MacRoberts 1996: "Problems of Citation Analysis" Scientometrics 36:435-44
Здравствуйте, Sinclair, Вы писали:
S>Ну ребята, так не честно. Сравнивать вклад компании с историей в 113 лет в общем-то, не с чем. Возможно? через 300 лет про IBM в учебниках будет написано что-то вроде "небольшая компания эпохи становления Google".
Не-а. IBM как и Гагарин останутся в истории навсегда(пока существуют компьютеры). Они были первыми.
Здравствуйте, VladD2, Вы писали:
V>>Соответственно, в тех языках, где нет break, continue и return вполне можно можно использовать goto, если использовать ег ос той же "аккуратностью", какую мы получаем в случае break, continue, return.
VD>Да, да. Полностью согласенж. Если писать с должной акуратностью, то х86-ассемблер лучший язык программирования.
х86-ассемблер — #авно полное, по сравнению со многими другими (Dec, MC68XXX, PICXX) но речь шла не об этом.
Но если в языке нет break, continue, return, то без goto порой получается тот самый синтаксический оверхед и лишняя "искусственная" запутанность кода.
Здравствуйте, vdimas, Вы писали:
V>Но если в языке нет break, continue, return, то без goto порой получается тот самый синтаксический оверхед и лишняя "искусственная" запутанность кода.
А по-моему все наоборот становится понятнее ;)
Вот в ML и Haskell нет ни break ни return ни continue ни goto — ну по крайней мере в прямом смысле
Здравствуйте, vdimas, Вы писали:
V>Пролог — был как ядро в системе распознавания смысла текстов в одной тематической области. Обработка была на С++, связь по COM на VB, а интерфейс GUI на Дельфи.
Мне как-то пришлось наблюдать за развитием нескольких систем, ядро которых было написано на Prolog-е, а внешние интерфейсы к различным устройствам и пр. -- на C++. После того, как Prolog-разработчики решили открыть свое дело и покинули тот колектив, одна система зачахла сама по себе, а вторая была полностью переписана на C++ и успешно продолжила свое существование.
Хотя, возможно, там Prolog применялся не по месту, а как инструмент, которым очень хорошо владели основные разработчики.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> V>Но если в языке нет break, continue, return, то без goto порой >> получается тот самый синтаксический оверхед и лишняя "искусственная" >> запутанность кода. >> Вот в ML и Haskell нет ни break ни return ни continue ни goto — ну по >> крайней мере в прямом смысле
C>Зато есть запутанность кода...
Не хочу ничего говорить по поводу у кого что запутано, но в любом случае, такие суждения лучше выносить только когда знаешь язык.
Потому что иначе могут схватить за руку.
Здравствуйте, eao197, Вы писали:
V>>Пролог — был как ядро в системе распознавания смысла текстов в одной тематической области. Обработка была на С++, связь по COM на VB, а интерфейс GUI на Дельфи.
E>Мне как-то пришлось наблюдать за развитием нескольких систем, ядро которых было написано на Prolog-е, а внешние интерфейсы к различным устройствам и пр. -- на C++. После того, как Prolog-разработчики решили открыть свое дело и покинули тот колектив, одна система зачахла сама по себе, а вторая была полностью переписана на C++ и успешно продолжила свое существование.
E>Хотя, возможно, там Prolog применялся не по месту, а как инструмент, которым очень хорошо владели основные разработчики.
Любой "устаканивнийся" алгоритм на Прологе (если это слово вообще применимо) можно переделать на императивном языке (пользуясь представлением о том, как Пролог-машина достигает целей). Правда, изменять этот императивный алгоритм будет весьма непросто. Зато на Прологе макетировать/отрабатывать весьма удобно. Если быстродействие устраивает, можно ничего никуда не переписывать.
Здравствуйте, GlebZ, Вы писали:
GZ>Честно говоря, полезнее будет GZ>
GZ>if (!something)somethingDo();
GZ>
GZ>Если у тебя особый случай, то лучше обособить в отдельную процедуру.
Это что, лекция по структурному программированию?
---------
Как один из факторов целесообразности декомпозиции в каждом конкретном случае, стоит кол-во связей, которые порождает декомпозиция. В общем, нафига тело цикла из 5 строк выносить во внешнюю процедуру, если это тело может использовать до 10 переменных/параметров и быть использовано однократно?
Здравствуйте, vdimas, Вы писали:
E>>Хотя, возможно, там Prolog применялся не по месту, а как инструмент, которым очень хорошо владели основные разработчики.
V>Любой "устаканивнийся" алгоритм на Прологе (если это слово вообще применимо) можно переделать на императивном языке (пользуясь представлением о том, как Пролог-машина достигает целей). Правда, изменять этот императивный алгоритм будет весьма непросто. Зато на Прологе макетировать/отрабатывать весьма удобно. Если быстродействие устраивает, можно ничего никуда не переписывать.
Проблема была не в том, что быстродействие не устраивало или еще чего-то технического. Проблема была в том, чтобы нанять или подготовить специалистов достаточного уровня знаний, чтобы продолжить развитие уже существующего кода на Прологе. Дешевле оказалось просто переписать.
ИМХО. Когда я изучал Пролог в уневере, то довелось заглянуть в исходники одной a-la экспертной системы. С тех пор мне кажется, что пролог -- это хороший способ шифрования собственных мыслей -- никто, кроме автора их уже не прочитает. Да и автор тоже, если нить рассуждений забудет
Но настаивать на этом утверждении не буду, т.к. очень вероятно, что я просто видел примеры плохих программ на Прологе.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
V>Это что, лекция по структурному программированию?
Никоим образом. Мысль вслух.
V>--------- V>Как один из факторов целесообразности декомпозиции в каждом конкретном случае, стоит кол-во связей, которые порождает декомпозиция. В общем, нафига тело цикла из 5 строк выносить во внешнюю процедуру, если это тело может использовать до 10 переменных/параметров и быть использовано однократно?
Иногда смысл всей программы состоит из 5 строк, или даже в одной.
В данном случае у нас два несвязанных вопроса.
1 — стоит ли выносить процедуру, если у нее получается 5 строк.
2 — что делать если у тебя получается 10 параметров.
Что касается 10 переменных/параметров, то если ты такое получил, значит в этом есть смысл и его можно выносить в отдельную структуру. Это кстати и ограничивает связи.
Что касается 1 пункта, то можно выносить и одну строку в отдельную процедуру, даже если нет повторного использования, но зато получаем более читабельную главную процедуру.
Ну и на 3, вынужден сказать что связи важны для разных сущностей(классы, компоненты). На уровне процедуры, наличие большого количества связей не оказывает такого влияния, поскольку собраны и подконтрольны в одном месте. Все это некриминально, пока это можно читать.
Здравствуйте, eao197, Вы писали:
E>Но настаивать на этом утверждении не буду, т.к. очень вероятно, что я просто видел примеры плохих программ на Прологе.
Это точно, лучше не настаивать. После одного хорошего подхода к Прологу, начинаешь легко читать текст, и перестаешь понимать как это можно реализовать в других языках. Сфера применения для Пролога достаточно узкая, но зато ведение такой программы(а после 2 дней трепыхания начинаешь его понимать с полуслова) очень удобна.
Здравствуйте, Cyberax, Вы писали:
>> Когда iterator.hasNext() = false
C>В данном примере все просто. А если этот поток используется в десяти C>местах в программе (т.е. если это log-файл)? Когда следует закрывать его?
Пример с одним поток слишком прост. Нужно рассмотреть два потока с перекрывающимся, но не идеинтичным, временем жизни.
Другое дело, что смысла в таком примере особого нет
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Пример с одним поток слишком прост. Нужно рассмотреть два потока с перекрывающимся, но не идеинтичным, временем жизни.
ANS>Другое дело, что смысла в таком примере особого нет
Не обязательно. Вполне можно представить себе процесс A, который записывает данные в файл для процесса B, а после записи стартует B. Если процесс A не позаботится о корректном закрытии и флушировании файла, то B может вообще ничего не прочитать.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Cyberax, Вы писали:
>>> Когда iterator.hasNext() = false
C>>В данном примере все просто. А если этот поток используется в десяти C>>местах в программе (т.е. если это log-файл)? Когда следует закрывать его?
ANS>Пример с одним поток слишком прост. Нужно рассмотреть два потока с перекрывающимся, но не идеинтичным, временем жизни.
да легко
как раз монады такие вещи очень лихо формализуют
просто идет инверсия и хэндл сверху отдается внутрь — вообще странно, это даже в ООП-мире успело появиться в виде стандартного паттерна — inversion of control (dependency injection)
Здравствуйте, reductor, Вы писали:
>>>> Когда iterator.hasNext() = false
C>>>В данном примере все просто. А если этот поток используется в десяти C>>>местах в программе (т.е. если это log-файл)? Когда следует закрывать его?
ANS>>Пример с одним поток слишком прост. Нужно рассмотреть два потока с перекрывающимся, но не идеинтичным, временем жизни.
R>да легко R>как раз монады такие вещи очень лихо формализуют R>просто идет инверсия и хэндл сверху отдается внутрь — вообще странно, это даже в ООП-мире успело появиться в виде стандартного паттерна — inversion of control (dependency injection)
С IoC возможна такая ситуация:
---++++++++++
-******____!!
тире — это типа нет открытых файлов.
+ и * — открытые файлы.
_ — это когда файл д.б. закрыт, но еще живёт
!! — это сработала финализация.
R>вообще вариантов куча даже без этого.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Pzz, Вы писали:
Pzz>>Я как-то был поражен, зайдя в знакомую контору, и обнаружив, что там Pzz>>собралась толпа программистов, и обсуждеает, как им выкрутиться из Pzz>>очередной нетривиальной проблемы, которую поставил перед ними C++. Как Pzz>>эта проблема содержательно соотносилась с решаемой задачей, я так и не Pzz>>понял...
К>Не факт, что это язык поставил проблему. Может быть, проблема была в архитектуре, а специфика мировосприятия программистов перевела её на рельсы кодирования.
Переведи...
"Москва слезам не верит"
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, reductor, Вы писали:
>>>>> Когда iterator.hasNext() = false
C>>>>В данном примере все просто. А если этот поток используется в десяти C>>>>местах в программе (т.е. если это log-файл)? Когда следует закрывать его?
ANS>>>Пример с одним поток слишком прост. Нужно рассмотреть два потока с перекрывающимся, но не идеинтичным, временем жизни.
R>>да легко R>>как раз монады такие вещи очень лихо формализуют R>>просто идет инверсия и хэндл сверху отдается внутрь — вообще странно, это даже в ООП-мире успело появиться в виде стандартного паттерна — inversion of control (dependency injection)
ANS>С IoC возможна такая ситуация:
ANS>---++++++++++ ANS>-******____!!
ANS>тире — это типа нет открытых файлов. ANS>+ и * — открытые файлы. ANS>_ — это когда файл д.б. закрыт, но еще живёт ANS>!! — это сработала финализация.
Нет никаких файлов со стороны клиентского кода — есть стандартные интерфейсы в виде тех же итераторов или чего угодно.
Ну и состояния системы без оглядки на всякие файлы и прочее — не царское это дело.
Логическое ядро системы не должно вообще оперировать такими сомнительными понятиями как файл, база данных или сетевое соединение.
Все эти вещи должны быть снаружи и инжектиться в виде стандартных интерфейсов тех же коллекций или наоборот вытягиваться внешними сервисами в виде тех же стандартных интерфейсов.
Как-то так.
Со скидкой на оо-buzzwords
В том же хаскеле вообще скорее немыслимо это все слить воедино — монады все равно "кексик послайсят" и все само разделится на элементарные части (дико клевый между прочим побочный эффект от них).
R>>вообще вариантов куча даже без этого.
ANS>"Поднимите мне веки"
всякие каналы и lightweight continuation-based процессы. да мало ли
способов заменить много физических действий одним логическим существует больше, чем языков программирования
Здравствуйте, reductor, Вы писали:
R>В том же хаскеле вообще скорее немыслимо это все слить воедино — монады все равно "кексик послайсят" и все само разделится на элементарные части (дико клевый между прочим побочный эффект от них).
О, кстати! Покажи, как монады могут кейс послайсить. А то что-то нету ясности в голове.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, reductor, Вы писали:
R>>В том же хаскеле вообще скорее немыслимо это все слить воедино — монады все равно "кексик послайсят" и все само разделится на элементарные части (дико клевый между прочим побочный эффект от них).
К>О, кстати! Покажи, как монады могут кейс послайсить. А то что-то нету ясности в голове.
Ну как, даже простейшай операция типа | readFile "file" >>= reciever | уже порождает разделение на два очевидных компонента и дает понять, что мухи — отдельно.
Логически какая бы ситуация не произошла, на reciever она не влияет даже если мы это перепишем как привыкли
можно конечно навесить на это errorHandler и таки потом пропихнуть куда нужно бесполезную информацию, но это будет так дико выглядеть, что хочешь не хочешь, а ясность придет. сама. и не уйдет.
В случае с более обширными вещами и эффекты могут быть интереснее
Вообще, подозреваю, монады могут быть формализмом чуть ли не для всех идиом, что программирование придумало до них. А не только для состояний, деструктивных апдейтов и ввода-вывода.
А то вот лично у меня по поводу глобальных переменных всегда была непонятка — что они выражают вообще такое и какая связь между модулями, которые ее вместе используют. И меня это всегда здорово напрягало, когда я не мог себе объяснить почему я сам сделал так, а не иначе. Или еще хуже — когда не мог решить как сделать.
А сейчас вот не думаю, хожу в каске и хихикаю, да тряпки жгу.
Это я так, на жизнь жалуюсь. Вроде бы конкретную проблему пофиксал — но удовольствия никакого: как будто собственные шерстяные носки бельевой верёвкой заштопал.
VD>Ну, давай поспорим какой из ассеблеров лчший из языков программирования. Мне вот x86 нравится. У него код из далека выглядит стройнее. Такие три колоночки... очень эстетично знаете ли.
А мне forth-ассемблеры нравились, знаешь ли... Очень удобно было производить манипуляцию битами и при этом вся мощь собственного фреймворка прямо в строках программы на ассемблере.
V>>Но если в языке нет break, continue, return, то без goto порой получается тот самый синтаксический оверхед и лишняя "искусственная" запутанность кода.
VD>Не, не. Не отвлекайся.
Я??? Это ж ты толкнул про ассемблеры. А я про goto. Во многих ассемблерах, кстати, goto тоже вещь не тривильная. Не всегда можно вот так запросто сделать jump (jmp, jp, etc). Иногда только через приседания.
VD>Давай уж поговорим о превосходстве Дековского ассемблера над разумом.
Удачная разработка — она и в африке удачная разработка. Говоря об удачности ассемблера имеют ввиду, разумеется, удачную систему команд проца.
Здравствуйте, reductor, Вы писали:
V>>Но если в языке нет break, continue, return, то без goto порой получается тот самый синтаксический оверхед и лишняя "искусственная" запутанность кода.
R>А по-моему все наоборот становится понятнее R>Вот в ML и Haskell нет ни break ни return ни continue ни goto — ну по крайней мере в прямом смысле
Опять ты про функциональный стиль? Нафига вообще козе баян? А замечание про отсекающие условия я уже делал.
R>И никакого синтаксического оверхеда
Ясен пень. Вся императивщина скрыта в недрах компилятора/интерпретатора. Но согласись, пока что еще слишком много императивных задач, хотя бы из соображений эффективности. Вон даже длину списка подсчитать в Лисп или Пролог нетривиально (с т.з. ресурсов), подозреваю, что такая же хрень в Haskell.
Вставлю свои 5 копеек. В С++ допустима перезагрузка оператора new. Мне неоднократно приходилось писат свои менеджеры памяти на С++. Т.е. все предельно разумно — на каждый конкретный случай, требующий эффективности можно написать идеально подходящий для данного случая менеджер памяти.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, reductor, Вы писали:
V>Вставлю свои 5 копеек. В С++ допустима перезагрузка оператора new. Мне неоднократно приходилось писат свои менеджеры памяти на С++. Т.е. все предельно разумно — на каждый конкретный случай, требующий эффективности можно написать идеально подходящий для данного случая ...
...менеджер памяти. и операционную систему
Написать свой аллокатор где угодно не проблема, просто за пределами С++ это требуется несколько реже
Опять же — учитывая сколько в современном С++ своих объектов, а сколько всякого boost'a и прочего, сия возможность как-то не сильно обнадеживает.
Здравствуйте, reductor, Вы писали:
R>Я когда-нибудь того человека, который придумал термин "функциональное программирование" отловлю и скормлю крокодилам.
Тогда остановимся на термине "функциональный стиль". Мы же должны оперировать какими-нибудь краткими терминами.
R>и самое главное — все эти goto теряют смысл, когда есть замыкания и ты можешь просто передать куда-то функцию для дальнейшей обработки.
Синтаксически это присутствует уже в C# 2.0, никто не спорит. В С++ та же идиома обыгрывается функторами и там тоже goto не нужен. Это не те случаи и мы отклонились.
R>Можно подумать, Nemerle или C# 3.0 — это "функциональные" языки. Или там ruby... R>"Функциональных" языка толком два — это Haskell и Clean, в остальных случаях — это просто языки без комплексов
V>>Ясен пень. Вся императивщина скрыта в недрах компилятора/интерпретатора.
R>Ну скрыта или не скрыта — это как считать. Си вот тоже некоторым образом "функциональный" язык. все функция, всегда есть возвращаемый тип, функции передавать можно. ну и тп. большая абстракция.
В С++, повторю, есть еще и функторы. Весь STL писан в расчете на них (ф-ии и функторы).
v>>Но согласись, пока что еще слишком много императивных задач, хотя бы из соображений эффективности. Вон даже длину списка подсчитать в Лисп или Пролог нетривиально (с т.з. ресурсов), подозреваю, что такая же хрень в Haskell. R>Длину связного списка посчитать везде стоит одинаково.
Самое время задуматься, почему связанные списки редко где используются в императвных участках кода.К тому же — побочный эффект насчет попаданий в кеш тоже играет свою роль. Далее, "сплошные" массивы более компактны, value-типы в .Net будет гораздо эффективней хранить в массивах и т.д.
В STL есть итераторы, причем работа с ними в основных алгоритмах не зависит от способа организации списка. Разница м/у итераторами — суть длина списка. Неплохая абстракция.
R>а описывается задача очень просто: R>
С++
R>другое дело, что длину знать их — это очень редко, когда нужно. по индексу их никто не итерирует и т.п
Если у меня свой собственный распределитель памяти, или я вызываю ф-ии АПИ ОС, или я пишу свой загрузчик и т.д.?
R>мощная штука, жаль, пока что без аппаратной поддержки медленнее, чем массивы
Есть инциденты аппаратной поддержки кеширования списочных структур?
R>резюме: R>Императивных задач же конечно много, но это не повод лишать себя удобства в виде матчинга, замыканий и хвостовой рекурсии.
STL/boost
с замыканиями сложнее, их приходтся эмулировать руками, в виде... объектов.
R>Причина существования окамла, между прочим (который не менее императивный, чем функциональный)
а что серьезного уже написано на окамле? (не стеб, если есть навскидку инфа — поделись)
Пролог — тоже весьма мощная штука, но блин чего-то не пошел в массы, даже удивительно... Даже с ОО- и императивными расширениями.
E>А чего здесь вообще должно делаться? Матрица на матрицу перемножаться?
E>Ну и сколько Scheme-программисту нужно будет изучать C++ и boost::mpl для того, чтобы сделать то же самое через C++ные expression templates?
blitz++, готовая, легко расширяемая либа для матричных и прочих вычислений. Очень элегентна и проста в использовании.
Здравствуйте, vdimas, Вы писали:
V>а что серьезного уже написано на окамле? (не стеб, если есть навскидку инфа — поделись)
Unison File Synchronizer, насколько я знаю. В отличии от rsync он был оптимизирован для синхронизации файлов, которые дописываются в конец (логи, к примеру).
Только rsync есть на гораздо большем количестве платформ, чем unison.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
V>В STL есть итераторы, причем работа с ними в основных алгоритмах не зависит от способа организации списка. Разница м/у итераторами — суть длина списка. Неплохая абстракция.
Мимо. operator- поддерживается только random access итераторами. Для произвольных итераторов есть std::distance.
R>>другое дело, что длину знать их — это очень редко, когда нужно. по индексу их никто не итерирует и т.п
А еще все стандратные контейнеры свой размер кэшируют. И сделать то же самое на любом ФЯ можно (только не нужно).
Здравствуйте, Глеб Алексеев, Вы писали:
V>>В STL есть итераторы, причем работа с ними в основных алгоритмах не зависит от способа организации списка. Разница м/у итераторами — суть длина списка. Неплохая абстракция. ГА>Мимо. operator- поддерживается только random access итераторами. Для произвольных итераторов есть std::distance.
речь шла о фичах, а не о внешнем их выражении.
R>>>другое дело, что длину знать их — это очень редко, когда нужно. по индексу их никто не итерирует и т.п ГА>А еще все стандратные контейнеры свой размер кэшируют. И сделать то же самое на любом ФЯ можно (только не нужно).
Нет, не можно. Голова списка (cons) — это может быть середина другого списка.
Здравствуйте, reductor, Вы писали:
R>Здравствуйте, vdimas, Вы писали:
V>>Здравствуйте, reductor, Вы писали:
V>>Вставлю свои 5 копеек. В С++ допустима перезагрузка оператора new. Мне неоднократно приходилось писат свои менеджеры памяти на С++. Т.е. все предельно разумно — на каждый конкретный случай, требующий эффективности можно написать идеально подходящий для данного случая ...
R>...менеджер памяти. и операционную систему
Согласись, что написание своего менеджера памяти — это тот самый "особый случай", который не возникает сам по себе.
R>Написать свой аллокатор где угодно не проблема, просто за пределами С++ это требуется несколько реже
В Лисп — проблема, в Пролог — проблема. Не знаю как в других новомодных.
R>Опять же — учитывая сколько в современном С++ своих объектов, а сколько всякого boost'a и прочего, сия возможность как-то не сильно обнадеживает.
В любой программе содержится счетное кол-во типов. Гораздо более счетно кол-во типов действительно требующих своего аллокатора. Обычно в командах С++ давно есть несколько разновидностей аллокаторов, которые просто прикручиваются к требуемым типам.
Здравствуйте, vdimas, Вы писали:
R>>...менеджер памяти. и операционную систему :)
V>Согласись, что написание своего менеджера памяти — это тот самый "особый случай", который не возникает сам по себе.
Не уверен, что понял.
Просто у меня это очень достаточно задача и на такие вещи я как правило не оглядываюсь.
R>>Написать свой аллокатор где угодно не проблема, просто за пределами С++ это требуется несколько реже :)
V>В Лисп — проблема, в Пролог — проблема. Не знаю как в других новомодных.
R>>Опять же — учитывая сколько в современном С++ своих объектов, а сколько всякого boost'a и прочего, сия возможность как-то не сильно обнадеживает.
V>В любой программе содержится счетное кол-во типов. Гораздо более счетно кол-во типов действительно требующих своего аллокатора. Обычно в командах С++ давно есть несколько разновидностей аллокаторов, которые просто прикручиваются к требуемым типам.
не просто :)
впрочем, это, опять же, зависит от специфики.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>reductor,
>> ПК> Пожалуй, правильнее говорить об управлении временем жизни объектов, с чем C++, действительно, справляется лучше ряда других языков благодаря детерминированному разрушению объектов. GC этой задачи не решает. >> >> Я все же не понимаю кое-чего. Для каких задач нужно такое управление?
ПК>Для любых, включающих необходимость своевременного освобождения внешних по отношению к программе ресурсов: файлы, сокеты, соединения с базами данных, хэндлы операционной системы и т.п. Основная проблема не столько в том, чтобы не забывать освобождать внешние ресурсы, а в том, чтобы надежно делать это в реальных условиях, когда, фактически, любая функция может выбросить исключение.
Здравствуйте, vdimas, Вы писали:
V>речь шла о фичах, а не о внешнем их выражении.
Ну извините, я, видимо, не понял, о каких именно. ГА>>А еще все стандратные контейнеры свой размер кэшируют. И сделать то же самое на любом ФЯ можно (только не нужно). V>Нет, не можно.
Что я не так делаю ?
type 'a cached_size_list = CSList of 'a list * int
let make_cs_list list = CSList (list, List.length list)
let add_cs_list (CSList (lst, n)) item = CSList (item::lst, n+1)
let cs_list_length (CSList (_, n)) = n
let cs_list_head (CSList (lst, _)) = List.hd lst
let cs_list_tail (CSList (lst, n)) = CSList (List.tl lst, n-1)
# let ls = make_cs_list [1;2;3;4];;
val ls : int cached_size_list = CSList ([1; 2; 3; 4], 4)
# let ls1 = add_cs_list ls 0;;
val ls1 : int cached_size_list = CSList ([0; 1; 2; 3; 4], 5)
# let ls2 = cs_list_tail ls1;;
val ls2 : int cached_size_list = CSList ([1; 2; 3; 4], 4)
V>Голова списка (cons) — это может быть середина другого списка.
Список — не объект, это значение, у него нет identity. Пока мы играем по функциональным правилам и 1) не интересуемся физическим равенством объектов (в ОКамл такое можно) и 2) не модифицируем mutable объекты внутри списков, нас совершенно не интересует, что несколько логически различных списков имеют физически общий хвост.
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Список — не объект, это значение, у него нет identity. Пока мы играем по функциональным правилам и 1) не интересуемся физическим равенством объектов (в ОКамл такое можно) и 2) не модифицируем mutable объекты внутри списков, нас совершенно не интересует, что несколько логически различных списков имеют физически общий хвост.
Глеб, извини за оффтопик, а тебе, когда ты учился, функциональное программирования или Пролог читали или нет?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Глеб, извини за оффтопик, а тебе, когда ты учился, функциональное программирования или Пролог читали или нет?
Да ничего. Я надеюсь, остальные участники нас простят.
Нет, я, к сожалению, учился не там, где это могли преподавать (эх, если бы я заканчивал MIT, я бы прошел SICP на первом курсе, а сейчас по ночам приходится ). На 90% все свои обрывочные знания о программировании добыл самостоятельно. Разве что мой будущий научный руководитель посоветовал обратить внимание на Пролог и подкинул пару тестовых задачек.
Здравствуйте, eao197, Вы писали:
E>Понятно. А нам читали Пролог. Может быть поэтому у меня примеры программ в функциональном стиле вызывают неприятие E>Как в школе: чтобы отвратить человека от русской литературы, нужно ему эту литературу насильно преподавать. . Ну, это не страшно. Т.к. Пролог — не функциональный. Я вот музыкальныю школу по классу ф-но закончил, по идее, музыку ненавидеть должен, а на деле это мне не мешает в меру сил жужжать на электрогитаре .
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Что я не так делаю ?
Все не так. Я ведь и в конец могу элементы добавить
V>>Голова списка (cons) — это может быть середина другого списка. ГА>Список — не объект, это значение, у него нет identity. Пока мы играем по функциональным правилам и 1) не интересуемся физическим равенством объектов (в ОКамл такое можно) и 2) не модифицируем mutable объекты внутри списков, нас совершенно не интересует, что несколько логически различных списков имеют физически общий хвост.
Именно, тем более не имеем право кешировать размеры списков, если нам не дано упрвлять их физическим представлением.
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, vdimas, Вы писали:
V>>Нет, не можно. Голова списка (cons) — это может быть середина другого списка.
Z>Про фичи тоже сильно написано, но тут не смог удержаться: cons — это конструктор, и не списка, а пары
cons — это термин ячейки, которые образуют связанный список, состав этой ячеки — элементы car и cdr. Имхо, ты перепутал термины с названиями одноименных ф-ий.
Одна ячейка cons — это и есть список. Ничто другое списком не является, кроме nil.
Здравствуйте, vdimas, Вы писали:
ГА>>Что я не так делаю ? V>Все не так. Я ведь и в конец могу элементы добавить
Ну, добавлять элементы в конец односвязного списка — неэффективная и оттого редкая операция. А двусвязные библиотечные списки есть (в extLib).
let cs_list_append (CSList (lst, n)) item = CSList (lst @ [item], n+1)
# let l1 = make_cs_list [1;2;3;4];;
val l1 : int cached_size_list = CSList ([1; 2; 3; 4], 4)
# let l2 = cs_list_append l1 5;;
val l2 : int cached_size_list = CSList ([1; 2; 3; 4; 5], 5)
На этот раз что не так?
Это бессмысленный пример, просто для демонстрации возможности. В классическом понимании указатель на узел — это уже список. В STL просто указатель на голову списка завернули в дополнительный объект, в котором реализовано все управление и дополнительно хранится размер. Никто не мешает то же самое сделать на ОКамле, что я и показал. Для пущей строгости инкапсулировать можно все в отдельный модуль, и работать с полученным cached_size_list'ом только через интерфейсные функции. Только не нужно это, ни длина не нужна, ни инкапсуляция списка, т.к. в работе со списками очень важен pattern matching. Но если в какой-то задаче окажется, что мне ежемиллисекундно нужна длина списка, уверяю вас, прокэширую и проигнорирую тот факт, что это невозможно .
V>>>Голова списка (cons) — это может быть середина другого списка. ГА>>Список — не объект, это значение, у него нет identity. Пока мы играем по функциональным правилам и 1) не интересуемся физическим равенством объектов (в ОКамл такое можно) и 2) не модифицируем mutable объекты внутри списков, нас совершенно не интересует, что несколько логически различных списков имеют физически общий хвост. V>Именно, тем более не имеем право кешировать размеры списков, если нам не дано упрвлять их физическим представлением.
Пока не сильно убедительно .
Если очень хочется управлять физическим представлением — пожалуйста, просто не нужно это.
Если нужно модифицировать, например, строку внутри списка — что, думаю, нужно нечасто, и обезопасить себя от изменений в других списках, достаточно строки явно скопировать. Пример:
# let ls1 = ["Hello"; "cruel"; "world"];;
val ls1 : string list = ["Hello"; "cruel"; "world"]
# let ls2 = List.tl ls1;;
val ls2 : string list = ["cruel"; "world"]
# let ls3 = "Yo"::ls2;;
val ls3 : string list = ["Yo"; "cruel"; "world"]
# let cruel = List.hd ls2;;
val cruel : string = "cruel"
# cruel.[0] <- 'C';;
- : unit = ()
# ls1;;
- : string list = ["Hello"; "Cruel"; "world"]
# ls2;;
- : string list = ["Cruel"; "world"]
# ls3;;
- : string list = ["Yo"; "Cruel"; "world"]
# let ls4 = List.map (String.copy) ls1;;
val ls4 : string list = ["Hello"; "Cruel"; "world"]
# cruel.[0] <- 'c';;
- : unit = ()
# ls1;;
- : string list = ["Hello"; "cruel"; "world"]
# ls4;;
- : string list = ["Hello"; "Cruel"; "world"]
#
з.ы. Во-первых, давайте жить дружно . А во-вторых, давайте сначала попробуем, а потом будем утверждать, что что-то невозможно.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>reductor,
>> ПК>Для любых, включающих необходимость своевременного освобождения внешних по отношению к программе ресурсов: файлы, сокеты, соединения с базами данных, хэндлы операционной системы и т.п. Основная проблема не столько в том, чтобы не забывать освобождать внешние ресурсы, а в том, чтобы надежно делать это в реальных условиях, когда, фактически, любая функция может выбросить исключение. >> >> http://www.rsdn.ru/Forum/Message.aspx?mid=1522461&only=1
Я понял вас прекрасно
Но вы в общем-то понимаете, что RAII — это хак сам по себе?
Причем, не очень красивый. Способ внести элемент хаоса и избежать проектирования.
Вот это "необязательно ограничено лексической областью видимости" ужасно на самом деле.
Сначала создаем связь и зависимость, а потом снимаем ограничения.
Но ладно, в конечном итоге каждый придумывает себе проблемы как хочет, конечно.
Если хотите получить такое в окамле — http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html
посмотрите на alarm, finalise, counters и тп. еще можно в общем-то описать то, что хочется через FFI и Си. + определить там свои функции-операторы для каких-то вещей или вообще свой интерфейс работы с классами через camlp4
Но имейтей в виду, еще, что в окамле классы используются сами по себе раз в 50 реже, чем в С++. И вообще нужность их там под вопросом, у окамла достаточно продвинутая система типов, чтобы классы что-то значили сами по себе.
Здравствуйте, reductor, Вы писали:
R>Но имейтей в виду, еще, что в окамле классы используются сами по себе раз в 50 реже, чем в С++. И вообще нужность их там под вопросом, у окамла достаточно продвинутая система типов, чтобы классы что-то значили сами по себе.
Интересно. Хочется задать вопрос: а к ООП ты вообще как относишься?
Личное: может давай(те) на "ты" перейдем? А то как-то неудобно получается...
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
R>>Но имейтей в виду, еще, что в окамле классы используются сами по себе раз в 50 реже, чем в С++. И вообще нужность их там под вопросом, у окамла достаточно продвинутая система типов, чтобы классы что-то значили сами по себе.
E>Интересно. Хочется задать вопрос: а к ООП ты вообще как относишься?
Примерно так же, как и Dijkstra:
Object-oriented programming is an exceptionally bad idea which could only have originated in California.
Жаль только, я не такой умный как Дйкстра и мне потребовалось слишком много времени, чтобы прийти к тому же выводу (флеймить я здесь не буду).
E>Личное: может давай(те) на "ты" перейдем? А то как-то неудобно получается... :shuffle:
Здравствуйте, reductor, Вы писали:
E>>Интересно. Хочется задать вопрос: а к ООП ты вообще как относишься?
R>Примерно так же, как и Dijkstra: R>
Object-oriented programming is an exceptionally bad idea which could only have originated in California.
R>Жаль только, я не такой умный как Дйкстра и мне потребовалось слишком много времени, чтобы прийти к тому же выводу (флеймить я здесь не буду).
Круто. Не флейма ради, а для прояснения ситуации. Я так понимаю, что ООП тебя не миновала. Но затем пришло понимание, что функциональный (не знаю как точнее его назвать) дает больше, чем может дать ООП. Так?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
R>>>другое дело, что длину знать их — это очень редко, когда нужно. по индексу их никто не итерирует и т.п
V>>Если у меня свой собственный распределитель памяти, или я вызываю ф-ии АПИ ОС, или я пишу свой загрузчик и т.д.?
R>Это к чему?
Ну... к тому, что я системный программист, например. Разрабатываю автоматы, парсеры, сетевые ср-ва на соккетах и не только и пр
R>>>мощная штука, жаль, пока что без аппаратной поддержки медленнее, чем массивы
V>>Есть инциденты аппаратной поддержки кеширования списочных структур?
R>Ну, смотря что считать... R>http://citeseer.ist.psu.edu/187280.html
Ну... в том направлении, но вряд ли это применимо до подробностей ячейки cons из Лисп.
R>Вообще это большая тема с затрагиванием фон ноймана против гарварда и тп
Иногда и гарвард более приемлим. В embedded-устройствах, где на счету каждый бит, банально разная ширина шин дает неплохие бенефиты. Хотя, и там возможно написать тот же Forth, и вот уже наши данные — как программа В общем, одну модель сейчас беззастенчиво эмулируют на базисе другой (например .Net — противоположный пример) и обратно же.
R>http://www-rocq.inria.fr/syndex/
впечатляет, скачал — поиграюсь
R>А так, кое в каких очень немаленьких компаниях используется в очень немаленьких внутренних системах. R>Но те же молчат и другим велят
странная позиция
V>>Пролог — тоже весьма мощная штука, но блин чего-то не пошел в массы, даже удивительно... Даже с ОО- и императивными расширениями.
R>У пролога трагическая судьба R>Его загубили PC и слишком большие ожидания. Как и лисп R>Пролог-машины, лисп-машины, Красота. а тут персоналки, мать их. R>И все, всем считать байты
Не только. Многие программировали GUI, это было востребовано/модно и мало кто это умел. Сейчас вот ажиотаж уже лет 5 как прошел, должен снова проснуться интерес к другим подходам.
reductor wrote: > > Примерно так же, как и Dijkstra: > Object-oriented programming is an exceptionally bad idea which could > only have originated in California.
Прелесть какая! А откуда это, хотелось бы прочитать целиком...
Здравствуйте, eao197, Вы писали:
E>>>Интересно. Хочется задать вопрос: а к ООП ты вообще как относишься?
R>>Примерно так же, как и Dijkstra: R>>
Object-oriented programming is an exceptionally bad idea which could only have originated in California.
R>>Жаль только, я не такой умный как Дйкстра и мне потребовалось слишком много времени, чтобы прийти к тому же выводу (флеймить я здесь не буду).
E>Круто. Не флейма ради, а для прояснения ситуации. Я так понимаю, что ООП тебя не миновала. Но затем пришло понимание, что функциональный (не знаю как точнее его назвать) дает больше, чем может дать ООП. Так?
Функциональное программирование и ООП ортогональны друг другу, это не фундаментально разные или тем более противоположные вещи.
ООП может быть и в Хаскеле.
Просто, когда программируешь на том же хаскеле, понимаешь, что все ООП — это лишь неловкая попытка эмулировать некоторые эффекты тех же замыканий, higher order functions и нормальной модульности.
Хотя, в общем, даже без хаскеля можно это ощутить.
Но это долгий разговор.
Здравствуйте, Pzz, Вы писали:
Pzz>reductor wrote: >> >> Примерно так же, как и Dijkstra: >> Object-oriented programming is an exceptionally bad idea which could >> only have originated in California.
Pzz>Прелесть какая! А откуда это, хотелось бы прочитать целиком...
Ну это я так понимаю просто приписывается ему. Вполне вероятно, что он в свою очередь кого-то процитировал.
но гугл другого источника не находит.
а так: http://en.wikiquote.org/wiki/Edsger_Dijkstra
Здравствуйте, reductor, Вы писали:
R>Не уверен, что понял. R>Просто у меня это очень достаточно задача и на такие вещи я как правило не оглядываюсь.
(достаточно редкая?)
Да редкая, но задача, к тому же — специфичная. Например, я обрабатываю огромные потоки символьных данных на серверном приложении (EDI — направление). Для многопоточных систем аллокаторы работают так себе... Я пишу свой аллокатор, который работает только в контексте текущего потока/вызова и не требует синхронизации. Отработав один запрос, я просто опять "взвожу" аллокатор в начальное состояние. Т.е. я даже память у его блоков не освобождаю (не путать с вызовом методов-деструкторов), т.к. это незачем для локальных контекстов. Ты как раз про регионы говорил, в общем, похожий принцип, но "изобретенный" мною много лет назад.
Это какое-то нестандартное непереносимое расширение. Хотя, мотивация мне понятна.
R>>>Опять же — учитывая сколько в современном С++ своих объектов, а сколько всякого boost'a и прочего, сия возможность как-то не сильно обнадеживает.
V>>В любой программе содержится счетное кол-во типов. Гораздо более счетно кол-во типов действительно требующих своего аллокатора. Обычно в командах С++ давно есть несколько разновидностей аллокаторов, которые просто прикручиваются к требуемым типам.
R>не просто R>впрочем, это, опять же, зависит от специфики.
К счастью — просто (навскидку).
template<typename BaseT, typename AllocatorT>
class WrapWithAllocator : BaseT {
WrapWithAllocator() : BaseT() {}
template<typename T1> WrapWithAllocator(T1 t1) : BaseT(t1) {}
[...] // до скольки угодно аргументов, пользуемся тем,
// что до реального применения шаблоны не инстанциируются компиляторомvoid* operator new(size_t, void* buff) { return buff; }
void* operator new(size_t size) { return AllocatorT::alloc(size); }
void operator delete(size_t size) { AllocatorT::free(this, size); }
}
Я уже озвучивал, что С++ — достаточно универсальный язык, т.е. встраивать какие-либо механизмы (от низкоуровневых до высокоуровневых) в него наиболее легко. Другое дело, что сам язык унаследовал слишком много низкоуровневых и потенциально опасных конструкций от С, которые вовсе не нужны для успешного программинга на С++.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, reductor, Вы писали:
R>>Не уверен, что понял. R>>Просто у меня это очень достаточно задача и на такие вещи я как правило не оглядываюсь.
V>(достаточно редкая?)
Да. редкая. Что-то идет не так в матрице, я точно помню как писал это слово :)
V>Да редкая, но задача, к тому же — специфичная. Например, я обрабатываю огромные потоки символьных данных на серверном приложении (EDI — направление). Для многопоточных систем аллокаторы работают так себе... Я пишу свой аллокатор, который работает только в контексте текущего потока/вызова и не требует синхронизации. Отработав один запрос, я просто опять "взвожу" аллокатор в начальное состояние. Т.е. я даже память у его блоков не освобождаю (не путать с вызовом методов-деструкторов), т.к. это незачем для локальных контекстов. Ты как раз про регионы говорил, в общем, похожий принцип, но "изобретенный" мною много лет назад.
V>Я уже озвучивал, что С++ — достаточно универсальный язык, т.е. встраивать какие-либо механизмы (от низкоуровневых до высокоуровневых) в него наиболее легко. Другое дело, что сам язык унаследовал слишком много низкоуровневых и потенциально опасных конструкций от С, которые вовсе не нужны для успешного программинга на С++.
Да чем это все отличается от самого крайнего случая с тем же окамлом — написанием модуля на Си и линковкой с ним.
Это по-моему что-то психологическое, скорее :)
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Ну, добавлять элементы в конец односвязного списка — неэффективная и оттого редкая операция.
какая разница, семантика должна быть полной
ГА>На этот раз что не так?
n+1 надо сделать у кеш-счетчика каждого элемента списка
да, это решаемо... но в таком виде — это уже не есть кешированное значение длины списка, т.е. смысл кеширования теряется (ты еще не забыл, с чего обсуждение началось? )
ГА>Это бессмысленный пример, просто для демонстрации возможности. В классическом понимании указатель на узел — это уже список. В STL просто указатель на голову списка завернули в дополнительный объект, в котором реализовано все управление и дополнительно хранится размер. Никто не мешает то же самое сделать на ОКамле, что я и показал. Для пущей строгости инкапсулировать можно все в отдельный модуль, и работать с полученным cached_size_list'ом только через интерфейсные функции. Только не нужно это, ни длина не нужна, ни инкапсуляция списка, т.к. в работе со списками очень важен pattern matching. Но если в какой-то задаче окажется, что мне ежемиллисекундно нужна длина списка, уверяю вас, прокэширую и проигнорирую тот факт, что это невозможно .
Да верю, только нафига это все? Если для каких-то задач потребуется ежемиллисекундно узнавать длину вектора, то лучше взять подходящий язык, не правда ли?
[скипнут код]
ГА>з.ы. Во-первых, давайте жить дружно . А во-вторых, давайте сначала попробуем, а потом будем утверждать, что что-то невозможно.
Понимаешь, универсальные языки потому и являются универсальными, что на них легко делать весьма многое,
вот за пол-часа на С# (мини-лисп, к нему легко прикрутить парсинг входного потока):
using System;
using System.Collections;
using System.Collections.Specialized;
namespace Probe {
public sealed class Lisp {
private static void Main() {
SETQ("A", LIST(LIST(1, 2), LIST(3, 4, LIST(5, 6), NIL)));
object a = SYMB("A");
PRIN1(a);
PRINC("\n");
PRIN1(CAR(a));
PRINC("\n");
PRIN1(CADR(a));
PRINC("\n");
PRIN1(CDAR(a));
PRINC("\n");
}
// краткая реализацияinternal class Cons {
internal object car, cdr;
public Cons(object car, object cdr) {
this.car = car;
this.cdr = cdr;
}
}
public static readonly object T = true;
public const object NIL = null;
private static readonly Hashtable s_symbols = CollectionsUtil.CreateCaseInsensitiveHashtable(100);
public static object ATOM(object o) {
if (o is Cons)
return NIL;
return T;
}
public static object CAR(object l) {
return ((Cons) l).car;
}
public static object CDR(object l) {
return ((Cons) l).cdr;
}
public static object CONS(object car, object cdr) {
return new Cons(car, cdr);
}
public static object LIST(params object[] objects) {
object list = NIL;
for (int i = objects.Length - 1; i >= 0; i--)
list = CONS(objects[i], list);
return list;
}
public static object SETQ(string symbol, object value) {
s_symbols[symbol] = value;
return value;
}
public static void _PRINC(string str) {
Console.Write(str);
}
public static object PRINC(object o) {
if (o == NIL)
_PRINC("NIL ");
else if (ATOM(o) == T)
_PRINC(o.ToString());
else
throw new ArgumentException("param #1 is not an atom");
return o;
}
public static object PRIN1(object o) {
if (ATOM(o) == T)
PRINC(o);
else {
PRINC("(");
print_list((Cons) o);
PRINC(")");
}
return o;
}
internal static void print_list(Cons list) {
PRIN1(list.car);
if (list.cdr != NIL) {
PRINC(" ");
if (ATOM(list.cdr) == T)
PRINC(list.cdr);
else
print_list((Cons) list.cdr);
}
}
public static object SYMB(string symbol) {
return s_symbols[symbol];
}
public static object CADR(object l) {
return CAR(CDR(l));
}
public static object CDAR(object l) {
return CDR(CAR(l));
}
// и т.д. и т.п.
}
}
Здравствуйте, vdimas, Вы писали:
V>n+1 надо сделать у кеш-счетчика каждого элемента списка
Нет, не надо. Точно так же, как не надо это в С++.
А спорить дальше не вижу смысла, уже все сказал и не знаю, как по-другому:
ГА>>В классическом понимании указатель на узел — это уже список. В STL просто указатель на голову списка завернули в дополнительный объект, в котором реализовано все управление и дополнительно хранится размер. Никто не мешает то же самое сделать на ОКамле, что я и показал.
V>Понимаешь, универсальные языки потому и являются универсальными, что на них легко делать весьма многое, V>вот за пол-часа на С# (мини-лисп, к нему легко прикрутить парсинг входного потока):
Уверен, многие присутствующие за полчаса и с гораздо большим успехом изобразят мини-лисп на ОКамле. Да еще и встроят его поддержку в исходном коде с помощью camlp4.
Вам нравится утверждать, что С++, Ява и C# — достаточно универсальные языки, и все остальные можно посылать подальше, даже не попробовав их на тех задачах, в которых они сильны (кстати, вы писали, что разрабатываете парсеры — так это же задача номер раз для ML-языков, примеров найдете немало). Я убежден в обратном. Кое-кто поопытнее меня убежден в этом настолько, что делает на этом бизнес: Работа на OCaml в Москве
V>Да верю, только нафига это все? Если для каких-то задач потребуется ежемиллисекундно узнавать длину вектора, то лучше взять подходящий язык, не правда ли?
и
V>Понимаешь, универсальные языки потому и являются универсальными, что на них легко делать весьма многое, V>вот за пол-часа на С# (мини-лисп, к нему легко прикрутить парсинг входного потока):
Я или чего-то не понимаю или здесь утверждение, что окамл или лисп менее универсальны, чем С#?
Здравствуйте, reductor, Вы писали:
V>>Да верю, только нафига это все? Если для каких-то задач потребуется ежемиллисекундно узнавать длину вектора, то лучше взять подходящий язык, не правда ли?
R>и
V>>Понимаешь, универсальные языки потому и являются универсальными, что на них легко делать весьма многое, V>>вот за пол-часа на С# (мини-лисп, к нему легко прикрутить парсинг входного потока):
R>Я или чего-то не понимаю или здесь утверждение, что окамл или лисп менее универсальны, чем С#?
OCaml — нет (насколько я понял из вчерашнего моего первого знакомства с ним), Лисп — да, менее универсален. То, что я показал, позволяет прямо в C# программе "орудовать" по лисповым правилам игры. Я даже уже продумал как обыграть макросы Нетрудно это все превратить в интерпретатор или даже в компилятор Лиспа (там и макросы легче будет сделать). Сделать же наоборот на Лиспе — прямо в коде писать по правилам C# (или интерпретатор или компилятор C#) не так уж просто. Первое — вообще нереально.
V>Извини, но я как программист могу захотеть получить cdddr списка и далее работать с ним. Твоя кешированная схема не сработала. А если делать коррекцию n+1 каждого элемента списка, после вставки в конец, то это все теряет свой первоначальный смысл.
Это потому что вы не заметили пары функций (они очень короткие, легко не заметить):
let cs_list_head (CSList (lst, _)) = List.hd lst
let cs_list_tail (CSList (lst, n)) = CSList (List.tl lst, n-1)
Про инкапсуляцию в модуль я тоже вроде говорил. (Да, в С++ я могу откастить итератор к какому-нибудь _ListNode<T>* и вперед, к новым вершинам, зачем мне insert(), когда есть _ListNode<T>* Pnext , это разве аргумент?).
V>Кстати, когда-то я подобную "игруху" делал и на С++, т.е. программа выглядела примерно так:
V>
V>NTerm A, B, C;
V>A = 'a' | 'b';
V>A = C & B;
V>C = 'c' | C & 'c';
V>B = A & C | C & C & A | A;
V>B = 'b'
V>
V>И нисходящий разбор к нему. Вполне позволяла "играть", менять приоритет правил и т.д. Куда уж минимальнее.
Симпатишно! Еще чуть-чуть, и будет буст::спирт . Жаль только, вы реализацию этой красоты не привели.
Ладно, не буду играть на чужом поле, я компиляторы не пишу.
V>Я вообще ни в чем не убежден и по-сути действую по обстоятельствам.
V>Виртуально есть обсуждение подходов, реально у меня стоит задача подбора людей в свою команду и я даже не могу найти нормальных спецов на С++/C#/Java. Про обсуждаемые языки вообще говорить не приходится. V>Не все, к сожалению живут в Москве, где срабатывают законы больших чисел, и находятся несколько человек даже на экзотику.
Я нашел нишу ФЯ лично для себя — прототипирование. Здесь эти причины не действуют.
V>Сам я слежу за ходом дисскуссий с удовольствием и уже планирую "как только так сразу" поближе познакомиться с Haskel.
Аналогично!
Здравствуйте, eao197, Вы писали:
ГА>>Я нашел нишу ФЯ лично для себя — прототипирование. Здесь эти причины не действуют. E>А почему не эту роль, к примеру, Smalltalk не подошел?
Я Smalltalk не знаю. Мнения на его счет не имею никакого. И никогда не слышал, чтобы смоллток был хорош для прототипирования научных и алгоритмических задач. Дело в том, что на основной работе я занимаюсь Win32/GUI/C++ + все понемножку (коммуникация по COM-порту с устройством, OPC-сервер и т.д., все эта солянка применяется в последнем проекте). А вот в аспирантуре (рекламировать себя не буду, т.к. ни черта толкового еще не вышло, и неизвестно, защищусь ли в результате) столкнулся с Natural Language Processing. С верой в буст и непогрешимость святого стандарта, кинулся я на это дело с С++ наперевес. Затея провалилась, все время ударяюсь в какие-то частности. Первые скромные результаты с применением (пока малознакомого!!!) ОКамла получены быстрее и выглядят значительно более многообещающе (тьфу-тьфу, чтоб не сглазить). Такие вот дела.
Здравствуйте, vdimas, Вы писали:
V>OCaml — нет (насколько я понял из вчерашнего моего первого знакомства с ним), Лисп — да, менее универсален. То, что я показал, позволяет прямо в C# программе "орудовать" по лисповым правилам игры. Я даже уже продумал как обыграть макросы :) Нетрудно это все превратить в интерпретатор или даже в компилятор Лиспа (там и макросы легче будет сделать).
Написать компилятор лиспа на чем угодно несложно, только это не его недостаток, а достоинство :)
V>Сделать же наоборот на Лиспе — прямо в коде писать по правилам C# (или интерпретатор или компилятор C#) не так уж просто. Первое — вообще нереально.
Конечно же реально.
Макросы в лиспе — это полноценный же лисп и есть.
Даже если мы на них напишем LR-парсер, то все равно это будет только парсер, рантайм, интероп с лиспом и некоторые оптимизации мы получим даром. Весь разбор C#-синтаксиса будет идти при компиляции.
Что в случае с C# не так.
Это очень важный момент вообще — лисп сам по себе представляет из себя мета-платформу для быстрого создания множества языков.
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>>>Я нашел нишу ФЯ лично для себя — прототипирование. Здесь эти причины не действуют. E>>А почему не эту роль, к примеру, Smalltalk не подошел?
ГА>Я Smalltalk не знаю.
Вопрос. Откуда ты можешь знать, что решаешь некую задачу оптимально, если ты просто банально не знаешь, какие еще подходы к ее решению существуют?
Может Smalltalk был бы еще эффективнее
ГА>столкнулся с Natural Language Processing.
Тогда все становится на свои места.
ГА> С верой в буст и непогрешимость святого стандарта, кинулся я на это дело с С++ наперевес.
А вот вера в Буст -- это напрасно, имхо.
ГА>Первые скромные результаты с применением (пока малознакомого!!!) ОКамла получены быстрее и выглядят значительно более многообещающе (тьфу-тьфу, чтоб не сглазить).
Удачи!
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Вопрос. Откуда ты можешь знать, что решаешь некую задачу оптимально, если ты просто банально не знаешь, какие еще подходы к ее решению существуют?
E>Может Smalltalk был бы еще эффективнее
Сомневаюсь, но мого быть, попробую. Потом, когда время будет. Если вы заметили, я целиком и полностью согласен с Арамисом (ой, с WFrag'ом): чтобы судить о языках, нужно на них попрограммировать (чуть не сказал пописать) чуток. Но не разорваться же мне, сначала одно, потом другое. А кроме того, в ОКамле меня привлекает мощная (а в Хаскеле — и того мощнее) система типов, которая не путается под ногами, а очень помогает при работе с навороченными структурами данных (если я не ошибаюсь, смолток — он динамически типизируемый, так?). А кроме того (опять же понаслышке, никакой категоричности), смолток — классика ОО, а ОО — не самое нужное при экспериментах со сложными алгоритмами. Пройтись по дереву в 3 строчки — вот что нужно.
ГА>>столкнулся с Natural Language Processing. E>Тогда все становится на свои места.
Кажется, на мне поставили клеймо .
ГА>> С верой в буст и непогрешимость святого стандарта, кинулся я на это дело с С++ наперевес. E>А вот вера в Буст -- это напрасно, имхо.
А я до сих пор уверен, что там масса полезных вещей. И знаете, в чем между нами разница? Я буст попробовал. Просто его оказалось недостаточно. (Тут я осознаю, что у Вас опыта побольше, и в Ваших условиях он может быть категорично неприменим, просто у меня сложилось впечатление, что с некоторых пор Вы встречаете в штыки все радикальные веяния: в С++ не нужны шаблонные навороты, ФЯ нормальному человеку тоже не нужны, программисты-прагматики любят С++, Руби и юнит-тесты . Просто впечатление, без обид).
ГА>>Первые скромные результаты с применением (пока малознакомого!!!) ОКамла получены быстрее и выглядят значительно более многообещающе (тьфу-тьфу, чтоб не сглазить). E>Удачи!
Спасибо огромное .
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>чтобы судить о языках, нужно на них попрограммировать (чуть не сказал пописать) чуток.
Собственно, похожие вещи я пытаюсь утверждать только относительно "знания" языка -- чтобы знать язык недостаточно прочитать пару книг о нем и написать несколько hello world-ов. Соответственно, чтобы знать много языков нужно много времени и усилий. Может быть даже слишком много.
ГА>А кроме того (опять же понаслышке, никакой категоричности), смолток — классика ОО, а ОО — не самое нужное при экспериментах со сложными алгоритмами. Пройтись по дереву в 3 строчки — вот что нужно.
Вполне возможно именно поэтому OCaml тебе и подошел. Но согласись, Natural Language Processing -- это отнюдь не самая распространенная предметная область.
E>>А вот вера в Буст -- это напрасно, имхо. ГА>А я до сих пор уверен, что там масса полезных вещей. И знаете, в чем между нами разница? Я буст попробовал. Просто его оказалось недостаточно. (Тут я осознаю, что у Вас опыта побольше, и в Ваших условиях он может быть категорично неприменим, просто у меня сложилось впечатление, что с некоторых пор Вы встречаете в штыки все радикальные веяния: в С++ не нужны шаблонные навороты, ФЯ нормальному человеку тоже не нужны, программисты-прагматики любят С++, Руби и юнит-тесты . Просто впечатление, без обид).
А я вообще по природе консервативен, Pink Floyd и Крематорий, к примеру, мне уже лет 15 нравятся. А Space и Jean-Michele Jarre еще больше
Если же серьезно, то я практически так и думаю. Имхо, сложные вещи должны решаться просто. И когда для решения сложных вещей предлагается сложный инструмент, который к тому же не тривиально использовать (я про Boost.Lambda), то мне кажется, что это не правильно. Уж лучше взять другой язык, где все это есть (здесь и твой личный опыт с OCaml в тему). Либо создать такой язык. Я имею в виду DSL с последующей кодогенерацией. Тот же yacc уже лет 30 актуален, потому что использовать его просто.
Что же касается опыта, то он не такой большой, как хотелось бы. Но показывает одну штуку: слишком хитрые и "изящные" решения приходится выбрасывать при сопровождении. Слишком неустойчивыми к изменению условий оказываются. Но это мой субъективный опыт.
А еще более прагматичные программисты, чем я, используют Java и юнит-тесты, и Ruby и юнит-тесты.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Глеб Алексеев, Вы писали:
ГА>>чтобы судить о языках, нужно на них попрограммировать (чуть не сказал пописать) чуток.
E>Собственно, похожие вещи я пытаюсь утверждать только относительно "знания" языка -- чтобы знать язык недостаточно прочитать пару книг о нем и написать несколько hello world-ов. Соответственно, чтобы знать много языков нужно много времени и усилий. Может быть даже слишком много.
Много усилий нужно, чтобы знать 5 языков. Чтобы знать 20-30, нужно не сильно больше.
E>Вполне возможно именно поэтому OCaml тебе и подошел. Но согласись, Natural Language Processing -- это отнюдь не самая распространенная предметная область.
Интересно, а какая самая? любой language processing — это очень важная часть программирования.
E>Если же серьезно, то я практически так и думаю. Имхо, сложные вещи должны решаться просто. И когда для решения сложных вещей предлагается сложный инструмент, который к тому же не тривиально использовать (я про Boost.Lambda), то мне кажется, что это не правильно. Уж лучше взять другой язык, где все это есть (здесь и твой личный опыт с OCaml в тему). Либо создать такой язык. Я имею в виду DSL с последующей кодогенерацией. Тот же yacc уже лет 30 актуален, потому что использовать его просто.
yacc просто использовать?!
видимо, придется попросить определить что такое просто.
А то после комбинаторов мне при виде якка хочется застрелиться.
Здравствуйте, reductor, Вы писали:
R>Смоллтолк — это такой мутировавший в ОО лисп без скобочек R>Интересен в первую очередь своим image-based подходом "все свое ношу с собой" и существующими на рынке средами. R>RAD на стероидах для всяких внутрикорпоративной фигни. R>ОО да, ОО напрягает в смоллтолке больше всего. R>Правда за счет динамической направленности это не настолько давит как в Java, но все же. R>И из-за этого в большинстве своем смоллтолкеры уверены, что отсутствие статической типизации — единственно верный путь
Не удивительно, что это говорит человек, которого даже от Ruby тошнит. А уж от чистого Smalltalk...
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
E>>Собственно, похожие вещи я пытаюсь утверждать только относительно "знания" языка -- чтобы знать язык недостаточно прочитать пару книг о нем и написать несколько hello world-ов. Соответственно, чтобы знать много языков нужно много времени и усилий. Может быть даже слишком много.
R>Много усилий нужно, чтобы знать 5 языков. Чтобы знать 20-30, нужно не сильно больше.
Без обид, но я не увидел, чтобы ты хорошо знал C++.
А знать хорошо C++ -- это может быть посложнее, чем знать 10-15 других языков.
E>>Тот же yacc уже лет 30 актуален, потому что использовать его просто.
R>yacc просто использовать?! R>видимо, придется попросить определить что такое просто.
А что сложного-то? Описываешь правила, прикручиваешь лексический анализатор. Проверяешь. Затем добавляешь синтаксические процедуры. И все дела.
R>Вот. Причем, прошу заметить — ничего не генерируется, это все на самом же языке и пишется. R>http://www.cs.uu.nl/~daan/download/parsec/parsec.html
Выглядит интересно. Но то, что синтаксические правила можно сразу на языке программирования описывать -- не новость: http://i.loveruby.net/en/projects/racc/ (их есть у нас ).
R>На последнем OSCON'e Autrijus Tang показывал как за 15 минут таким образом пишется полный разбор грамматики perl 6.
Уже известной грамматики. И после нескольких часов подготовки к демонстрации.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: офтоп - Брюс Эккель о Руби, эмишах и пр :)
R>>Много усилий нужно, чтобы знать 5 языков. Чтобы знать 20-30, нужно не сильно больше.
E>Без обид, но я не увидел, чтобы ты хорошо знал C++.
Хорошо или нет, я стараюсь на нем не писать и о нем не говорить.
И никому вообще знать его не обещал.
Не самая интересная для меня тема, без обид.
E>А знать хорошо C++ -- это может быть посложнее, чем знать 10-15 других языков.
Прошу прощения, но откуда такие сведения?
Неужели по собственному опыту? :)
E>>>Тот же yacc уже лет 30 актуален, потому что использовать его просто.
E>А что сложного-то? Описываешь правила, прикручиваешь лексический анализатор. Проверяешь. Затем добавляешь синтаксические процедуры. И все дела.
А можно просто — описываешь прямо на месте правила и все? А то мне так привычнее.
R>>Вот. Причем, прошу заметить — ничего не генерируется, это все на самом же языке и пишется. R>>http://www.cs.uu.nl/~daan/download/parsec/parsec.html
E>Выглядит интересно. Но то, что синтаксические правила можно сразу на языке программирования описывать -- не новость: http://i.loveruby.net/en/projects/racc/ (их есть у нас :) ).
Racc (Ruby yACC) is a LALR(1) parser generator for Ruby [..]
Parsers generated by Racc requires "Racc Runtime Module".
Это называется "на языке"?
R>>На последнем OSCON'e Autrijus Tang показывал как за 15 минут таким образом пишется полный разбор грамматики perl 6.
E>Уже известной грамматики. И после нескольких часов подготовки к демонстрации.
Ну с удовольствием посмотрю здесь на разбор этой грамматике на yacc+С++.
Время можно будет прикинуть по количеству строчек там и там.
Здравствуйте, eao197, Вы писали:
R>>Смоллтолк — это такой мутировавший в ОО лисп без скобочек R>>Интересен в первую очередь своим image-based подходом "все свое ношу с собой" и существующими на рынке средами. R>>RAD на стероидах для всяких внутрикорпоративной фигни. R>>ОО да, ОО напрягает в смоллтолке больше всего. R>>Правда за счет динамической направленности это не настолько давит как в Java, но все же. R>>И из-за этого в большинстве своем смоллтолкеры уверены, что отсутствие статической типизации — единственно верный путь
E>Не удивительно, что это говорит человек, которого даже от Ruby тошнит. А уж от чистого Smalltalk...
R>Да чем это все отличается от самого крайнего случая с тем же окамлом — написанием модуля на Си и линковкой с ним. R>Это по-моему что-то психологическое, скорее
С этим спорить не буду, психологических барьеров нет, сам регулярно пишу нечто на универсальных С/С++, и подлинковываю то в VB, то в .Net, то в Windows ScriptHost, то в Дельфи и т.д.
Здравствуйте, reductor, Вы писали:
E>>А знать хорошо C++ -- это может быть посложнее, чем знать 10-15 других языков.
R>Прошу прощения, но откуда такие сведения? R>Неужели по собственному опыту?
Да. И не только моему. Думаю, что многие из учасников форума C/C++ со мной согласятся.
E>>Выглядит интересно. Но то, что синтаксические правила можно сразу на языке программирования описывать -- не новость: http://i.loveruby.net/en/projects/racc/ (их есть у нас ).
R>Это называется "на языке"?
Да, здесь я ошибся, раньше RACC рекламировался как инструмент, в котором правила прямо в Ruby декларировались. Все течет, все изменяется.
R>>>На последнем OSCON'e Autrijus Tang показывал как за 15 минут таким образом пишется полный разбор грамматики perl 6.
E>>Уже известной грамматики. И после нескольких часов подготовки к демонстрации.
R>Ну с удовольствием посмотрю здесь на разбор этой грамматике на yacc+С++. R>Время можно будет прикинуть по количеству строчек там и там.
Просто разбор? А какой в этом смысл, в простом разборе-то?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
E>>Не удивительно, что это говорит человек, которого даже от Ruby тошнит. А уж от чистого Smalltalk...
R>?? R>Можно попросить расшифровать мысль?
Ну просто разработчики Ruby не скрывают, что очень многое было взято из Smalltalk. Только язык попытались сделать прагматиченее.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
V>>cons — это термин ячейки, которые образуют связанный список, состав этой ячеки — элементы car и cdr. Имхо, ты перепутал термины с названиями одноименных ф-ий.
V>>Одна ячейка cons — это и есть список. Ничто другое списком не является, кроме nil.
Z>Мне не жалко, я повторю: cons — это функция, название которой есть сокращение от constructor, которая является конструктором пары.
И?
Z>car и cdr — функции, а не "состав ячейки". Z>То, что вы называете "термин ячейки", называется "pair" или "dotted pair"
Замечание, связанный и dotted список — какая разница?
проверь сам на предикате (atom (cons 42 43)) и заодно посмотри в исходники любого лиспа, что именно проверяет этот предикат.
Z>А так: (cons nil (cons 42 43))?
Туда же.
Z>Не верите мне, наберите в гугле "cons definition", например.
Да верю, просто поверь, что cons-ячейка — это устоявшийся термин. См. "cons cell" в гугле, так же как и ее составные части CAR и CDR.
A cons cell is an object that consists of two slots, called the CAR slot and the CDR slot. Each slot can hold or refer to any Lisp object. We also say that "the CAR of this cons cell is" whatever object its CAR slot currently holds, and likewise for the CDR.
A note to C programmers: in Lisp, we do not distinguish between "holding" a value and "pointing to" the value, because pointers in Lisp are implicit.
A list is a series of cons cells, linked together so that the CDR slot of each cons cell holds either the next cons cell or the empty list. See section 5. Lists, for functions that work on lists. Because most cons cells are used as part of lists, the phrase list structure has come to refer to any structure made out of cons cells.
...
Because cons cells are so central to Lisp, we also have a word for "an object which is not a cons cell". These objects are called atoms.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, reductor, Вы писали:
E>>>А знать хорошо C++ -- это может быть посложнее, чем знать 10-15 других языков.
R>>Прошу прощения, но откуда такие сведения? R>>Неужели по собственному опыту?
E>Да. И не только моему. Думаю, что многие из учасников форума C/C++ со мной согласятся.
Перечислять эти 15 языков, которые вы знаете, вы, конечно, откажетесь?
R>>Ну с удовольствием посмотрю здесь на разбор этой грамматике на yacc+С++. R>>Время можно будет прикинуть по количеству строчек там и там.
E>Просто разбор? А какой в этом смысл, в простом разборе-то?
чтобы сохранить получившийся AST в виде s-expressions.
Здравствуйте, reductor, Вы писали:
E>>Да. И не только моему. Думаю, что многие из учасников форума C/C++ со мной согласятся.
R>Перечислять эти 15 языков, которые вы знаете, вы, конечно, откажетесь?
Нет. Но я не знаю 15 языков.
На сегодняшний момент я пользуюсь двумя: С++ и Ruby. Знаю их на относительно среднем уровне.
Зато ты, как я понимаю, знаешь больше 15-ти, но C++ толком не знаешь. Хотя, как мне кажется, С++ в этот список будет входить.
R>>>Ну с удовольствием посмотрю здесь на разбор этой грамматике на yacc+С++. R>>>Время можно будет прикинуть по количеству строчек там и там.
E>>Просто разбор? А какой в этом смысл, в простом разборе-то?
R>чтобы сохранить получившийся AST в виде s-expressions.
Не, на уровне AST я пас. Никогда его не строил.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
E>>Не, на уровне AST я пас. Никогда его не строил.
R>Потрясающее откровение.
А я вообще редко обманываю.
R>Знаете что такое "знать язык" в моем понимании? R>Это когда понимаешь как он работает — когда можешь написать компилятор или интерпретатор этого языка.
А в моем понимании, когда на этом языке ты можешь написать эффективную и корректную реализацию поставленной перед тобой задачи. Без скрытых багов, обусловленных незнанием языка.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
V>Да верю, просто поверь, что cons-ячейка — это устоявшийся термин. См. "cons cell" в гугле, так же как и ее составные части CAR и CDR.
Про "cons cell" верю, думаю, в 60-х годах прошлого века так и говорили, а CAR и CDR были буквально ассемблерными командами для доступа к частям регистра на IBM-704. Но даже тогда "cons" обозначало конструктор, который не мог быть ни головой списка ни термином ячейки
V>>Голова списка (cons) — это может быть середина другого списка V>>cons — это термин ячейки, которые образуют связанный список...
DEA>Пожалуйста. Никогда не претендовал на "истину в последней инстанции". Более того, за варианты рефакторинга, которые меня (хотя бы) заинтрересуют, сполна отвешу оценками — минусов обещаю не ставить . Но... только за варианты рефакторинга.
Да замечательно он о Ruby отзывается (насколько позволяют мне его понять мои познания в английском):
But hey, if Ruby pushes the right buttons for you, great. It's probably the tool that will make you most productive right now, and that's what you should use.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
R>Так на каком тогда основании делается предположение, что С++ сложнее 15 языков?
На основании твоих высказываний в данном форуме.
E>>Зато ты, как я понимаю, знаешь больше 15-ти, но C++ толком не знаешь. Хотя, как мне кажется, С++ в этот список будет входить.
R>А вы уверены, что вы знаете С++ достаточно, чтобы оценить насколько его знаю я? R>Если уж вы так настойчиво хотите обсудить эту тему.
Давай так, если считаешь, что знаешь C++, то ответь на вопрос, заданный мной в: Re[17]: Goto's are evil?
V>>Да верю, просто поверь, что cons-ячейка — это устоявшийся термин. См. "cons cell" в гугле, так же как и ее составные части CAR и CDR.
Z>Про "cons cell" верю, думаю, в 60-х годах прошлого века так и говорили, а CAR и CDR были буквально ассемблерными командами для доступа к частям регистра на IBM-704. Но даже тогда "cons" обозначало конструктор, который не мог быть ни головой списка ни термином ячейки
Здравствуйте, eao197, Вы писали:
R>>А вы уверены, что вы знаете С++ достаточно, чтобы оценить насколько его знаю я? R>>Если уж вы так настойчиво хотите обсудить эту тему.
E>Давай так, если считаешь, что знаешь C++, то ответь на вопрос, заданный мной в: Re[17]: Goto's are evil?
Здравствуйте, reductor, Вы писали:
R>Здравствуйте, R.K., Вы писали:
RK>>Здравствуйте, reductor, Вы писали:
R>>>Прагматичнее, да. R>>>Мацумото во всеуслышание объявляет, что у него взорвался мозг, когда он пытался разобраться с хаскелем, после чего идет делать "прагматичный" язык.
RK>>И с этим можно согласиться, после такого: append = foldr ((.).( id -- вот как это понять, кроме как разложить (.) на лямбды? (дваждыи, в особенности, такого: cfold' f z [] = z
R>Я даже на секунду не задумался, а в чем проблема?
Вот именно, что проблема состоит в сложности понимания не синтаксиса, а самого принципа действия таких конструкций. Причем все составляющие известны:
(.)f g = \x -> g(f x)
-- (:) = cons
foldr f z [] = z
foldr f z (x:xs) = f x (foldr f z xs)
Всё понятно, никаких проблем.
Но это не добавляет ясности До тех пор, пока не вставить недостающие параметры, скобки и не переписать в виде лямбд:
append l l' = (foldr ((.).(:)) id l) l'
append l l' = (foldr (\x -> (.)(x:)) id l) l'
-- все, приехали, дальше только foldr надо заменять на что-то другое
По-моему, последняя инкарнация выглядит чуть понятнее, чем начальная, но всё же... Какой у неё "физический" смысл? Как надо понимать её действие?
R>В хаскеле вообще нет неоднозначностей и быть не может — у него строгая семантика. 100% лямбда.
В этом не хочется сомневаться
[skip: это всё ясно] R>Элементарно и без вариантов (в сомнительных случаях см. спецификацию хаскеля).
RK>>cfold' f z (x:xs) = f x z (\y -> cfold' f y xs) RK>>cfold f z l = cfold' (\x t g -> f x (g t)) z l -- это ж надо столько рекурсивных лямбд наворотить![/code]
R>_Вся_ программа на хаскеле после desugarer'a превращается в чистую лямбду. Нужно только выучить правила трансляции. R>Ничего сложного здесь нет.
А как можно посмотреть результаты трансляции в лямбду? И есть ли в интерпретаторе Хаскеля что-то типа (trace 'func-name)? Очень бы помогло.
R>>>Почему-то мне кажется, что хаскель он не смог освоить, потому что у него уже был разорванный мозг. Смоллтолком. RK>>Може и так. А у меня, значит, Лиспом
R>Не знаю, я и лисп и хаскель люблю. Хаскель, правда, если честно, больше R>Я на нем могу программировать в уме — не ошибаясь
Программировать в уме и я могу без ошибок. Правда такого ЯП ещё не выдумали
RK>>PS Я не против Хаскеля, он мне очень понравился, это хорошее продолжение традиций Лиспа, но некоторые вещи, с виду совсем простые, иногда очень не просто понять.
R>Нет, хаскель — не продолжение лиспа. Это важно понять. Это продолжение ISWIM и Миранды.
Таких зверей не знаем Тоже функциональные и ленивые?
> E>>Свои знания C++ я оцениваю весьма скромно. > R>А почему вы тогда спрашиваете? вы антисемит? > Имхо, гораздо проще и быстрее было продемострировать знания, если > таковые имелись.
Кстати да, вопрос очень простой. Свой любимый вопрос (про shared memory)
я даже задавать не буду
reductor wrote:
> да легко > как раз монады такие вещи очень лихо формализуют > просто идет инверсия и хэндл сверху отдается внутрь — вообще странно, > это даже в ООП-мире успело появиться в виде стандартного паттерна — > inversion of control (dependency injection)
Я уже по-моему раза три сказал, что инверсия управления невозможна в
нормальном виде, если используются два ресурса с частично
перекрывающимся временем жизни. IoC умеет работать нормально только с
вложенными жизненными циклами.
Ну и в многопоточных случаях ни IoC, ни регионы (для работы с памятью)
не помогают. Но такие случаи все же достаточно редкие, так что их можно
не считать.
Мне лично один раз пришлось править программу на Erlang (чистый
функциональный язык для параллельных программ), где происходила утечка
описателей устройств (а они были очень дефецитны, утечка всего десятка
из них приводила систему в ступор). Это было ОЧЕНЬ неприятно —
приходилось делить логически единый код на куски, которые можно
вкладывать друг-в-друга. В итоге в следующей версии (ее уже делал не я)
эту программу на Erlang переписали на С++ (с использованием ACE). До сих
пор работает и совершенствуется.
Здравствуйте, Cyberax, Вы писали:
C>Я уже по-моему раза три сказал, что инверсия управления невозможна в C>нормальном виде, если используются два ресурса с частично C>перекрывающимся временем жизни. IoC умеет работать нормально только с C>вложенными жизненными циклами. C>Ну и в многопоточных случаях ни IoC, ни регионы (для работы с памятью) C>не помогают. Но такие случаи все же достаточно редкие, так что их можно C>не считать.
У меня какое-то дикое желание кого-нибудь уволить тут же возникло.
Вы отдаете себе отчет, что управление памятью — это формальная задача со своей алгеброй?
Что существует, например, исчисление регионов?
Что 15 лет уже как в хаскеле монады это дело неявно описывают?
Короче, жду от вас формальное представление RAII и доказательства того, что регионы "не помогают", а RAII помогает.
На неформальный ответ не прореагирую.
Потому два ресурса с "частично перекрывающимся" временем жизни — это полная дичь.
Даже лень объяснять почему. По-моему, это должно быть очевидно.
C>Мне лично один раз пришлось править программу на Erlang (чистый C>функциональный язык для параллельных программ), где происходила утечка C>описателей устройств (а они были очень дефецитны, утечка всего десятка C>из них приводила систему в ступор). Это было ОЧЕНЬ неприятно — C>приходилось делить логически единый код на куски, которые можно C>вкладывать друг-в-друга. В итоге в следующей версии (ее уже делал не я) C>эту программу на Erlang переписали на С++ (с использованием ACE). До сих C>пор работает и совершенствуется.
Воздержусь от комментариев даже не смотря на то, что все жду, когда уже меня отсюда удалят.
Как не стыдно только такое писать.
делить код на куски и вкладывать друг-в-друга
нет слов
чикатило!
Здравствуйте, Кодт, Вы писали:
К>Эти и другие люди прославились тогда, когда они о своей славе не заботились (шпилька в адрес Вирта нынешнего); упрекать их в том, что она не заслужена, — несерьёзно. Заслужена.
Я почти со всем в данном посте согласен.
Кроме вот этой фразы со "шпилькой".
ИМХО, если так хочется вставить "шпильку", не надо брать на себя роль миротворца или судьи.
А то получается как у капрала Шовинэ: солдаты всех армий примерно одинаковы, за исключением разве что французов.
По содержанию же этой "шпильки" могу сказать следущее. Нынешний "честолюбивый" (на Ваш взгляд) Вирт отстаивает те же принципиальные положения, что и в эпоху своей "скромности". В этом нетрудно убедиться, сопоставляя сказанное им сейчас с тем, что он говорил "тогда".
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, vdimas, Вы писали:
V>Я??? Это ж ты толкнул про ассемблеры. А я про goto. Во многих ассемблерах, кстати, goto тоже вещь не тривильная. Не всегда можно вот так запросто сделать jump (jmp, jp, etc). Иногда только через приседания.
Я думл ты поймешь мою шутку юмора. Сори.
V>Удачная разработка — она и в африке удачная разработка. Говоря об удачности ассемблера имеют ввиду, разумеется, удачную систему команд проца.
Ты серьезно хочешь поговорить о ассемблерах? В общем, то не вопрос. Могу отделить ветку, но меня это не интересует.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
reductor wrote:
> Вы отдаете себе отчет, что управление памятью — это формальная задача > со своей алгеброй?
Я отдаю себе отчет, что это практическая задача, лучше С++ которую пока
никто еще не решает.
> Короче, жду от вас формальное представление RAII и доказательства > того, что регионы "не помогают", а RAII помогает.
Often, the increase in memory with case 3 pools is acceptable. These are
cases where there is limited wasted memory from pools with overlapping
lifetimes, in spite of not freeing memory back to the system (possibly due
to a lot of pool memory self-reuse).
Обратите внимание на слова "wasted memory" — у меня как раз был такой
случай, только вместо памяти терялся критичный ресурс. А вот RAII
позволяет достичь нулевого оврехеда, в случае region inference это
невозможно для перекрывающихся участков.
> Даже лень объяснять почему. По-моему, это должно быть очевидно.
Здравствуйте, klapaucius, Вы писали: K>IBM была первой? А разве не Rand?
Так, для справки: изначально IBM называлась "Hollerith's Tabulating Machine Company", так как была создана Германом Холлеритом для производства табуляторов по заказу правительства США — нужно было проводить перепись населения. http://www-03.ibm.com/ibm/history/history/year_1896.html. По сравнению с нею, Ранд (1948 г.р.) — молокососы. K>Вот и получается, что для того чтобы запомнили — первым быть недостаточно.
Не, не получается.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Есть такая программа re2c. она генерирует распознаватели регулярных выражений в C-код. DEA>Там есть несколько вариантов генерации. (1)используя goto (2)используя if-ы (3)используя таблицу состояний. Почему-то, самый быстрый код получается в варианте (1)...
А почему? Скорее всего это особенности реализации а вовсе не фундаментальное преимущество goto.
DEA>Простая и бесхитросная реализация бинарного алгоритма возведения в степень больших чисел. С использованием GOTO. в данном случае goto спасает (а)от достаточно неприятного дублирования кода, (б) ничуть не вредит ясности текста. DEA>
DEA>//rn = (an ** en) mod mn
DEA>umodexp(data* rn, data const* an, data const* en, data const* mn)
DEA>{
DEA> data *n1 = rn; n1->copy(an);
DEA> data *n2 = data::alloc(rn->capacity);//пусть этот меморилик вас не смущает
DEA> //код немного упрощен для наглядности
DEA> data::byte_type const* ep = en->data + en->size - 1;
DEA> data::byte_type mask = 1 << (data::bits-1);
DEA> while( 0 == (*ep & mask) )
DEA> mask >>= 1;//skip to first '1' bit
DEA> reduction_algo reduce(mn);
DEA> goto start;
DEA> for(;;) {
DEA> umul(n1, n2, n2);
DEA> reduce(n2, n1);
DEA> if( *ep & mask ) {
DEA> umul(n1, n2, an);
DEA> start: reduce(n2, n1);
DEA> }
DEA> if( 0 == (mask >>= 1) ) {
DEA> if( --ep < en->data_ ) break;
DEA> mask = 1 << (data::bits-1);
DEA> }
DEA> }
rn->>copy(n2);
DEA>}
DEA>
DEA>Посему, вопрос: должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет.
Я не антифанат goto. Для него тоже есть малюсенький уголок в программировании, но этот пример крайне неудачен и чисто формально преобразуем в более понятный вид без goto:
Всего одна строчка кода вместо goto start и метки. Это можно назвать дублированием? Кода стало меньше(число нажатий клавиш), читабельность и ясность (структурирование) улучшились.
По-моему это просто более ясная запись алгоритма. И код должен стать эффективнее поскольку компилятору не нужно разбираться с дополнительным входом ВНУТРЬ ЦИКЛА, а именно в неоптимальных циклах часто и теряется производительность.
Кроме читабельности кода, если ещё один аспект — использование goto даёт возможность написания кода, который не приводится к вложеной структуре циклов (циклы с несколькими входами). А это делает анализ такого кода на порядок более сложной задачей, а следовательно заметно усложняется задача оптимищации кода компилятором.
Почему, интересно, Линус не восхищается Фортраном, в котором есть возможность написания процедур с несколькими входами.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>>Кроме читабельности кода, если ещё один аспект — использование goto даёт возможность написания кода, который не приводится к вложеной структуре циклов (циклы с несколькими входами). А это делает анализ такого кода на порядок более сложной задачей, а следовательно заметно усложняется задача оптимищации кода компилятором. WH>Старым оптимизаторам это возможно мешало. А современным оптимизаторам это по барабану.
Совершенно верно. Наличие многих входов может мешать только эвристическим оптимизаторам, которые пытаются "узнавать" характерные образцы кода. Нормальный оптимизатор строит CFG (Control Flow Graph), приводит его к SSA или SSI и уже потом начинает трансформации. При этом ему абсолютно безразлична исходная структура кода.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>>>Кроме читабельности кода, если ещё один аспект — использование goto даёт возможность написания кода, который не приводится к вложеной структуре циклов (циклы с несколькими входами). А это делает анализ такого кода на порядок более сложной задачей, а следовательно заметно усложняется задача оптимищации кода компилятором. WH>>Старым оптимизаторам это возможно мешало. А современным оптимизаторам это по барабану. S>Совершенно верно. Наличие многих входов может мешать только эвристическим оптимизаторам, которые пытаются "узнавать" характерные образцы кода. Нормальный оптимизатор строит CFG (Control Flow Graph), приводит его к SSA или SSI и уже потом начинает трансформации. При этом ему абсолютно безразлична исходная структура кода.
Не надо смушать людей умными словами SSA тут ни при чём. После построения CFG допустим строим структуру циклов и... видим, что есть циклы с двумя и более входами и очень, очень огорчаемся. Многие высокоуровневые оптимизации циклов обламываются сразу, а для того, чтобы выполнить те, которые всё-таки возможно произвести потребуется написать примерно столько же кода, сколько и для обработки стандартных случаев. Получается ради 1% случаев приходится писать (тестировать и поддерживать) в два раза больше кода.
Ещё один пример. Допустим у нас расставлены вероятности переходов в CFG. Теперь, зная колличество входов в функцию, нам нужно расставить счётчики исполнения в каждом линейном участке. Это почти линейный алгоритм если все циклы имеют один вход. Если же есть циклы с многими входами, то для точного решения этой задачи потребуется алгоритм с большей вычислительной сложностью.
Так что, я всё-таки настаиваю на своей точке зрения, что CFG программы написаной с использование goto может оптимизироваться хуже (иногда заметно хуже) современными промышленными оптимизирующими копиляторами.
Бабокин Дмитрий wrote: > Не надо смушать людей умными словами SSA тут ни при чём. После > построения CFG допустим строим структуру циклов и... видим, что есть > циклы с двумя и более входами и очень, очень огорчаемся.
Почему? Ведь можно применить простое преобразование и разделить цикл на
два цикла с одной точкой входа.
Здравствуйте, Cyberax, Вы писали:
C>Бабокин Дмитрий wrote: >> Не надо смушать людей умными словами SSA тут ни при чём. После >> построения CFG допустим строим структуру циклов и... видим, что есть >> циклы с двумя и более входами и очень, очень огорчаемся. C>Почему? Ведь можно применить простое преобразование и разделить цикл на C>два цикла с одной точкой входа.
Я говорю про цикл с двумя входами, а не с двумя обратными дугами. Может я чего-то не понимаю — объясни как преобразовать следующий цикл:
if (A) goto L2; //Basic block 1 (goto для простоты за линейный участок не считаем)
L1: //Basic block 2
i+=1;
L2: //Basic block 3
i+=2;
if (i<N) goto L1; //Basic block 4
Цикл сожержит блоки 2-4. 2 и 3 являются точками входа в цикл.
Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>Я говорю про цикл с двумя входами, а не с двумя обратными дугами. Может я чего-то не понимаю — объясни как преобразовать следующий цикл:
БД>
БД>if (A) goto L2; //Basic block 1 (goto для простоты за линейный участок не считаем)
БД>L1: //Basic block 2
БД>i+=1;
БД>L2: //Basic block 3
БД>i+=2;
БД>if (i<N) goto L1; //Basic block 4
БД>
if (A) goto L2; //Basic block 1 (goto для простоты за линейный участок не считаем)
L1_1: //Basic block 2
i+=1;
//Basic block 3
i+=2;
if (i<N) goto L1_1; //Basic block 4
goto END;
L2: //Basic block 3
i+=2;
if (i<N) goto L1_2; //Basic block 4
goto END;
L1_2: //Basic block 2
i+=1;
//Basic block 3
i+=2;
if (i<N) goto L1_2; //Basic block 4
END:
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
То, что ты предлагаешь — это дублицирование кода. Т.е. это некоторая трансформация. Причём если её польза почти очевидна в мальких примерах, то если это большое приложение и у нас не один цикл, а гнездо циклов, такое дублицирование может быть вредно. Кроме того, зачастую хочется проводить сначала полный анализ, а уже потом приступать к трансформациям — в такой модели как раз и мешают циклы с несколькими входами.
Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>То, что ты предлагаешь — это дублицирование кода. Т.е. это некоторая трансформация. Причём если её польза почти очевидна в мальких примерах, то если это большое приложение и у нас не один цикл, а гнездо циклов, такое дублицирование может быть вредно. Кроме того, зачастую хочется проводить сначала полный анализ, а уже потом приступать к трансформациям — в такой модели как раз и мешают циклы с несколькими входами.
Я вобще не понимаю что ты к этим циклам прицепился. ИМХО все без них прекрасно оптимизируется.
В твоем примере оптимизировать просто нечего. Попробуй привести пример с несколькими входами в цикл который нельзя оптимизировать без разбиения на несколько циклов.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>>То, что ты предлагаешь — это дублицирование кода. Т.е. это некоторая трансформация. Причём если её польза почти очевидна в мальких примерах, то если это большое приложение и у нас не один цикл, а гнездо циклов, такое дублицирование может быть вредно. Кроме того, зачастую хочется проводить сначала полный анализ, а уже потом приступать к трансформациям — в такой модели как раз и мешают циклы с несколькими входами. WH>Я вобще не понимаю что ты к этим циклам прицепился. ИМХО все без них прекрасно оптимизируется. WH>В твоем примере оптимизировать просто нечего. Попробуй привести пример с несколькими входами в цикл который нельзя оптимизировать без разбиения на несколько циклов.
Вот пример, который нельзя разбить на несколько циклов:
Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>Вот пример, который нельзя разбить на несколько циклов:
Я просил пример который нельзя оптимизировать. БД>Блоки 2 и 3 являются циклом с двумя входами.
БД>А оптимизировать нечего только пока CFG не наполнен реальным кодом.
Я всеравно не понимаю как это мешает оптимизатору?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>>Вот пример, который нельзя разбить на несколько циклов: WH>Я просил пример который нельзя оптимизировать. БД>>Блоки 2 и 3 являются циклом с двумя входами.
БД>>А оптимизировать нечего только пока CFG не наполнен реальным кодом. WH>Я всеравно не понимаю как это мешает оптимизатору?
Похоже мы смотрим на это с разных колоколен. Я утверждаю, что циклы, написаные с помощь goto могут быть трудны для анализа. В частности, циклы с несколькими входами (от которых всё-таки не всегда можно избавиться). Чем конкретно они могут осложныть анализ? Пример — алгоритм вычисления счётчиков выполнения каждого линейного участка по вероятносям переходов и счётчику входа в функцию. Что значит осложнять анализ — это значит увеличивать размер самого алгоритма и увеличивать его алгоритмическую сложность.
Почему я не говорю непосредственно о случаях, которые "нельзя оптимизировать"? Потому, что глядя на конкретный пример, человек всегда придумает как его соптимизировать. Вопрос как построить оптимизатор, который будет брать все подобные случаи. Вот тут-то мы и приходим к тому, "как это мешает оптимизатору". Это мешает тем, что обработка такой нестандартной структуры CFG требует более сложных алгоритмов анализа, необходимость которые вызывает сомнение. Учитывая то, что тестировать такие алгоритмов намного сложнее из-за редкости таких порнографичных случаев, получаем плохое покрытие этих алгоритмов в тестовой базе. В то же время, абсолютное большинство кода пишется без использования goto, либо использование goto не приводит нестандартной структуре CFG. Теперь вопрос — стоит ли разработчику компилятора добавлять поддержку оптимизации столь редких случаев и при этом заметно осложняя себе жизнь?
Т.е. ответаты на твои вопросы будут такими.
1. Привести пример, который нельзя оптимизировать - я не утверждаю, что есть примеры которые в принципе нельзя оптимизировать только потому, что были использованиы goto.
2. Как это мешает оптимизатору — это осложныет различные виды анализа, как следствие оптимизатор может просто отказаться от некоторых видов оптимизации, либо провести их не совсем верно.
Здравствуйте, Dmi_3, Вы писали:
D_>Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>> reduction_algo reduce(mn); DEA>> goto start; DEA>> for(;) { DEA>> umul(n1, n2, n2); DEA>> reduce(n2, n1); DEA>> if( *ep & mask ) { DEA>> umul(n1, n2, an); DEA>> start: reduce(n2, n1); DEA>> } DEA>> if( 0 == (mask >>= 1) ) { DEA>> if( --ep < en->data_ ) break; DEA>> mask = 1 << (data::bits-1); DEA>> } DEA>> } rn->>>copy(n2); DEA>>} DEA>>[/c] DEA>>Посему, вопрос: должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет.
D_>Я не антифанат goto. Для него тоже есть малюсенький уголок в программировании, но этот пример крайне неудачен и чисто формально преобразуем в более понятный вид без goto:
Ну этот код что-то делает и иногда ему это удается. Так он мне читается. Провернув цикл Вы переместило break; в начало цикла.
Видимо здесь есть некое понятное состояние, с которого этот цикл и начинался. Теперь оно спрятано в середине цикла. Вполне возможно что этим Вы совершенно разрушили читабельность кода. Дело в том, что чисто формальный подход здесь может быть не уместен. Не вдаваясь в работу вообще нельзя доказать что этот цикл когдато закончится.
Здравствуйте, Programador, Вы писали:
D_>>Я не антифанат goto. Для него тоже есть малюсенький уголок в программировании, но этот пример крайне неудачен и чисто формально преобразуем в более понятный вид без goto:
P>Ну этот код что-то делает и иногда ему это удается. Так он мне читается. Провернув цикл Вы переместило break; в начало цикла. P> Видимо здесь есть некое понятное состояние, с которого этот цикл и начинался. Теперь оно спрятано в середине цикла. Вполне возможно что этим Вы совершенно разрушили читабельность кода. Дело в том, что чисто формальный подход здесь может быть не уместен. Не вдаваясь в работу вообще нельзя доказать что этот цикл когдато закончится.
. Можно ли подробнее, что это за языки, для каких целей используются, как применяются, какие замечены достоинства/недостатки использования такого количества языков, используется ли это все в рамках одного проекта, какова численность команды и пр.?
1.1.4 stable rev. 510
Перекуём баги на фичи!
.
Какая чушь! Прогнила не наука, а максимум — система обучения. А Наука не приемлет государственных границ.
