Про Python вопрос

Изучаю тут последние веяния в преподавании так называемой информатики. Например, в небезызвестной 179 школе Денис Кириенко использует для обучения матшкольников Python.

http://server.179.ru/wiki/?page=DenisKirienko/Python

В принципе, ничего сверхестественного в этом нет — задания не сильно отличаются от того, что обычно делается с использованием Pascal. Более того, какие-то специфические возможности Python используются крайне редко. Но вот почитал я «сопроводительные материалы», подумал маленько, погуглил — но так и не понял один очень простой вопрос. На размышления меня навела вот эта крохотная оговорка:

можно использовать структуру данных, называемую в Питоне список (в большинстве же языков программирования используется другой термин “массив”)

С высоты своих нынешних знаний я могу сказать, что массив «в большинстве языков программирования» и список — это совершенно разные вещи, которые смешивать не стоит, особенно если в последующих задачах речь заходит о разных способах сортировки. Но как обстоит дело в Python — я не знаю. Может быть, тамошний «список» настолько хорош, что и время доступа к элементам по индексу там от этого индекса не зависит?

В принципе, это можно установить простым экспериментом — но мне лень ставить Python и экспериментировать с ним, так что спрошу питонознатцев — у вас там настоящие списки, с линейно растущим временем доступа по индексу, или же гибриды списков и массивов?

Не дергайтесь, за вас все решили

Читаю иногда из энтомологического интереса ЖЖ [info]maxkatz. Имею все основания предполагать, что оный Кац если не сидит на заплате от правительства Москвы, то хотя бы какие-то ништяки за его деятельность ему иногда перепадают. Подчеркну, что не за просто так — а именно за деятельность.

Глупо думать, что основная оплачиваемая деятельность Каца — это просиживание штанов в муниципальном собрании или зарубежные поездки с Варламовым. Правительство Москвы имеет свою выгоду от существования этого персонажа. Что предлагает Кац в своем блоге? Якобы он на «любительском» уровне занимается урбанистикой, то есть наукой о правильном устройстве городов. В рамках этого своего увлечения он рассказывает о рецептах, как сделать «хорошо и правильно». Рецепты сводятся к ущемлению автомобилистов — вплоть до демонтажа дорог в городе, и некоему призрачному «развитию общественного транспорта». Но вот что интересно — вплоть до риторики («автомобилисты — после пенсионеров самая дотационная часть российского общества») они совпадают с правительственной «Стратегией-2020», которая любому здравомыслящему человеку кажется полным издевательством:

http://www.autoreview.ru/_archive/section/detail.php?ELEMENT_ID=123858&SECTION_ID=6970

Правда, у нас в стране накоплен богатый опыт по внедрению нововведений «по просьбам трудящихся», добровольно и с песней. Собственно, этим Кац и занимается.

Кто в ЖЖ считается «большим специалистом» по вопросам урбанистики и городского транспорта? Конечно же Кац. Транслируемые Кацем идеи практически повторяют предложения Стратегии-2020, но в отличие от них — воспринимаются как «глас народа». Все большее и большее число людей находит у Каца какие-то здравые мысли, повторяет их — а через некоторое время перестает отличать от собственных. Хорошие и правильные идеи у Каца, безусловно, встречаются — как встречаются они и в Mein Kampf, например. Но в обоих случаях в «рассуждениях» скрываются какие-нибудь логические ошибки или неявные допущения, позволяющие перейти от правильных посылок к неверным выводам. Для примера возьмем вот эту запись:

http://maxkatz.livejournal.com/90818.html

Все красиво, нарисованы какие-то графики — причем нарисованы не средствами Excel, а «художественно» — в общем, читатель готов поверить в то, что если прижать автомобилистов к ногтю, то настанет полный кайф. Но это доверчивый читатель, не видящий за формой комикса его содержания. Тот, кто не потерял остатков критического мышления, задумается, например, над тем, почему точка пересечения графиков объявляется «точкой равновесия» — а ведь все выводы Кац делает на основании этого утверждения. Впрочем, это никому не интересно — а как показывают результаты ЕГЭ, умение читать графики превратилось в редкое вуду, доступное лишь Посвященным :)

Кроме того, Кац ссылается на совершенно определенных авторитетов в области урбанистики — на одного из авторов пресловутой «Стратегии» М. Блинкина и некоего В. Вучика. Блинкин сам по себе — тот еще персонаж. В статье «Авторевю» его обозвали «авторитетным научным руководителем государственного дорожного НИИ (РосДорНИИ)» — спутав ФГУП РосДорНИИ с «Некоммерческим партнерством «НИИ Транспорта и дорожного хозяйства»» — то есть частной лавочкой с громким названием и невнятными целями. Последние мои сомнения рассеялись тогда, когда Кац написал о встрече с М. Ликсутовым, министром транспорта Москвы. Пасьянс сложился — Блинкин и Вучик — боги, Кац — их пророк, а Ликсутов — няшечка, потому что беседовал с самим Вучиком.

Есть ли другие точки зрения, есть ли возражения на аргументы Вучика и Блинкина — Кац об этом молчит. Как говорил Джакомо Казанова, Guardati da colui che non ha letto che un libro solo — бойся того, кто прочел всего одну книгу. Вместо дискуссии о том, как правильно, создается ее имитация. Никто не сомневается в том, что транспортные проблемы в Москве есть, никто не сомневается в том, что их надо решать. Вместо того, чтобы представить различные варианты, создается миф о том, что раньше московское правительство все делало неправильно, а вот теперь — услышало «глас народа» в лице Каца, побеседовало с Вучиком, и вообще, Ликсутов такой мимими :)

Нет, к «гласу народа» никто прислушиваться не будет. Его видимость просто создадут — с чем всех и поздравляю.

Советы по работе с компьютером

Очень полезные советы из серии «как перестать тупить в интернетике»:

http://sandyclaws.livejournal.com/150007.html

1) Не пользуюсь мессенджерами. Когда-то завел себе жаббер, да и туда не захожу.

2) Вконтакте сижу только из-за одной-единственной группы. Не понимаю, что люди там находят. Но вообще я мерзкий асоциальный тип.

3) Стараюсь свести все «регулярно читаемые» источники информации в интернете к френдленте в ЖЖ, буквально десятку сайтов в RSS-аггрегаторе и главной «Яндекса». Именно поэтому перестал ходить по форумам — просто неудобно. Пользуюсь последними только для поиска конкретной информации, хотя по выражению [info]bmwservice «Это как пытаться напиться из пожарного брандспойта — и не напьетесь и рот порвете».

4) Не пользуюсь. Френдлента пока обозрима за 30-40 минут чтения «по диагонали».

5) Не люблю «чужие» онлайновые сервисы. Вместо этого у меня есть собственный блог :)

6) Печатаю быстро, но «зрячим» методом.

7) На работе — «личный» Mantis, плюс бумажка с текущими задачами. «Для себя» пока хватает памяти. Одно время пользовался «напоминалкой» в мобильном. Думаю перейти на ежедневник по методу «Грибных эльфов»:

Из-за систематического употребления кислоты нам приходилось идти на крайние меры. Например, я вел для Крейзи своеобразный ежедневник, в котором отражал все наши намерения на несколько суток вперед. В нем было три графы: «где нам надо быть», «во сколько», и «кого мы должны будем там встретить». А после ряда прискорбных случаев мы ввели еще две — «о чем нам следует говорить» и «зачем нам все это нужно».

8) Не понял, если честно.

9) Для распространения информации модно использовать стены в общественных сортирах.

Business Objects: Re-Engineering for Re-Use, или кому не хватает ООП

По наводке [info]ailev ознакомился с книжкой Криса Партриджа «Business Objects: Re-Engineering for Re-Use». Прекрасное чтение после какого-нибудь руководства по «мейнстримному» объектно-ориентированному проектированию с использованием UML, а главное — в любимом мной жанре «прикладной философии».

Как и полагается в книгах такого типа, где предлагается какой-то фундаментально новый подход, не обошлось без вступления в духе «вы все пидоры, а я Д’Артаньян». Утверждается, что «стандартный» подход к проектированию информационных систем, который автор назвал «сущностным» (entity), несмотря на все заявления его авторов, не позволяет строить сколь-либо сложные модели реальных систем, и не позволяет прямо соотнести возникающие сущности с реальностью. Это подтверждается примером из статьи Стива Кука и Джона Дениэлса «Object-Oriented Methods and the Great Object Myth», в котором «миф» о том, что мир состоит из объектов и операций (взаимно-однозначно соответствующих объектам и операциям в модели) разрушается простым примером — когда мы пьем чай, мы не вызываем операцию «пить», принадлежащую объекту «чашка» — и вообще, представить это простое действие с помощью «объектно-ориентированной» модели очень сложно.

Для нового, единственно верного и всячески правильного подхода к проектированию предлагается сменить парадигму — то есть смотреть на мир, не как на состоящий из сущностей (entity, это общепринятый термин, например, в так называемой ER-модели) или субстанций (substance, это более высокий уровень абстракции и общепринятый философский термин), а составленный из более сложных для представления «объектов». То, что называется «объектами» в учебниках по ООП — это, в терминологии книги, «сущности» либо «субстанции». Картина мира, использующая «сущности», неявно существует и в «бумажных» информационных системах. Взаимно-однозначное соответствие между терминами из теории реляционных БД, «бумажных» картотек и «сущностной» парадигмы — не просто совпадение, а подтверждение единой картины мира, представляемой тремя способами.

В любой предметной области можно выделить четыре «рода» вещей (kinds of things) — конкретные вещи («белый ВАЗ-2101 с проколотыми колесами, ржавеющий в моем дворе»), типы вещей («все автомобили «Жигули»»), отношения между вещами («Иван Иваныч — владелец белого ВАЗ-2101 и далее по тексту») и изменения, происходящие с этими вещами (вышеупомянутым «Жигулям» выбили стекло, вытащили все сиденья и насрали внутри). Оказывается, что модель мира, состоящего из «сущностей» или «субстанций» не вполне адекватно позволяет описывать все это. Например, «сущности» убивает классический пример из все той же греческой философии — «корабль Тесея». Жители Афин поставили корабль, на котором Тесей вернулся с Крита, победив Минотавра, на «вечную стоянку» — как крейсер «Аврора». При этом они его постоянно ремонтировали (как крейсер «Аврора»), и наконец, настал момент, когда все досочки и гвоздики были поменяны (ну точно «Аврора»). Можно, конечно, ввести дополнительную сущность — например, ПТС, где отражать все замены номерных агрегатов — но древние греки до этого не дошли, и более-менее приемлемо парадокс разрешил Аристотель, рассматривая «субстанции» — грубо говоря то, что остается от предмета, если его лишить всех свойств. «Субстанция» нематериальна, и с точки зрения Аристотеля, сохраняется даже при замене всех «материальных» частей.

Так или иначе, но современное ООП предлагает смотреть на мир, как на множество объектов-субстанций, которые имеют изменяющиеся со временем свойства. В аристотелевскую картину мира укладывается и понятие наследования вместе с «общими» категориями объектов — как существование более общих, «вторичных» субстанций и свойств — но не все гладко с отношениями — для них приходится вводить дополнительные свойства объектов (например, у автомобиля есть свойство «владелец») — и с изменениями — фактически предложенное Аристотелем решение предлагает учитывать изменения, как какие-то новые «частицы» в картине мира.

Если непонятно про Аристотеля — то вот более «жизненный» пример. Используемая в проектировании баз данных модель «сущность-связь» (entity-relationship, или ER-модель) возникает как раз при использовании «сущностей» или «субстанций». Отношения (или «связи») в ней предлагается представлять в виде дополнительных атрибутов объектов или же (в случае отношения «многие-ко-многим») — строить «фиктивную» таблицу, представляющую отношения. Эти решения точно так же вводят в картину мира новые «элементарные частицы», которые существуют наравне с «настоящими», но ничего «реального» не представляют.

В книге предлагается принятую в современном ООП аристотелевскую модель последовательно перестраивать, приводя ее к «истинно объектному», по мнению автора, виду — в отличие от понимания «объектов» в современном ООП. Как один из «промежуточных» шагов рассматривается «логическая» модель. Вместо атрибутов предлагается рассматривать принадлежность к классам (не в смысле «обычного» ООП) — например, вышеупомянутые «Жигули» Ивана Ивановича можно отнести к классам «автомобили», «все белое», «все ржавое» и так далее. Для того, чтобы представлять отношения, в картине мира появляются «кортежи» (tuple), которые, как и индивидуальные предметы, могут входить в какие-то классы. Например, пара <Иван Иваныч, ржавые Жигули> входит в класс, который можно назвать «владеет» — равно как и пара <Иван Иваныч, участок в 6 соток за 101 километром>. Точно так же можно представлять отношения из многих элементов — например, «Иван Иваныч выписал любимому внуку доверенность на «Жигули»» можно представить тройкой <Иван Иваныч, любимый внук, Жигули>, входящей в класс «кто-то выписал кому-то доверенность на что-то». Всякий же объект оказывается представителем универсальной категории «логических объектов».

Важное новшество в этой модели — возможность рассматривать «классы объектов» с позиции теории множеств. «Класс» — это множество объектов, которое само может являться подмножеством другого класса. Примером такого взаимоотношения между классами можно назвать цвета — класс «все раскрашенное» содержит классы «все белое» и «все красное» как подмножества. Это позволяет рассматривать иерархии классов, более точно отражающие реальный мир, чем в случае других моделей. Некоторой сложностью в главе про логическую модель оказывается понимание автором теории множеств. Например, если множество «всех красных» объектов — это объекты A и B, а «всех белых» — Y и Z, то описанный выше класс «всего раскрашенного» будет содержать не два описанных класса, а четыре объекта A, B, Y и Z. При этом автор использует термин «member of» — то есть описывает множество {{A, B}, {Y, Z}} вместо {A, B, Y, Z}.

Кстати, с помощью логической модели можно проектировать реляционные базы данных. Да, они получаются сложнее, чем в книжке «PHP и MySQL для чайников» — но понимание того, что таблица БД — это список кортежей, входящих в какое-то отношение (поэтому БД и «реляционная»), а не «записей об объектах», позволяет представлять многие вещи куда эффективнее. Фактически это обобщение принципов, заложенных в ER-модель на отношения с количеством членов, большим двух.

Логическая модель снимает сложности с отношениями, но проблема представления изменений остается. Для ее решения предлагается ввести «четвертое измерение» — время, и вместо локализованных во времени «логических объектов» рассматривать объекты на протяжении всего их жизненного цикла. Фактически, это замена значения функции на саму функцию или ее график, то есть некоторую кривую — очень плодотворная идея в математике и, как ни странно, в науке о представлении окружающего мира. Эту модель автор называет «объектной» — в очередной раз вворачивая модное слово и совершенно смущая читателя — особенно того, который обнаружил в главе о «субстанциальной» модели все понятия современного ООП.

Кстати, в книге очень сложная и непривычная на первый взгляд терминология. Например, «объектами» называют совсем не то, что понимается под словом «объект» в книжках «по UML», а с первого раза понять слово «substance» вообще невозможно. Про странное понимание терминов теории множеств я уже упоминал. Оно только запутывает читателя, хорошо знакомого с этими терминами.

После последовательного построения «объектной» (в терминологии автора) модели она применяется к нескольким примерам, разумеется, весьма успешно. Построенная методология преобразования «сущностных» моделей в «объектные» называется красивыми словами REV-ENG™ (да-да, именно со значком trade mark), предлагается автором в качестве абсолютно универсальной и везде-везде применимой. Насчет абсолютной ее применимости не знаю — хотя очень похожий метод лежит в основе стандарта обмена данными ISO 15926, и по утверждениям все того же [info]ailev, это «наше все» и вообще, будущее человечества. Во всяком случае, книжка круто «расширяет сознание» и заставляет по-новому взглянуть на привычные вещи.

PS Несмотря на то, что я поставил тег «программирование», в книге нет ни единой строчки кода ни на одном из языков программирования. Читать можно всем без исключения, хотя очень желательно понимание существующих методов работы с разнообразными данными — хотя бы в рамках UML и того, что называется «теорией баз данных».