DRAKON.SU

Почему это должно раздражать? Я вот умею ходить, умею говорить, умею писать. Это - разные умения. Естественно, что функционально они выражаются разными методами.

to Valery Solovey
Обычный императивный псевдокод.

Подозреваю, примеры были построены на основе дедукции. По непроверенным данным девочкам легче даётся индукция.

Валерий, ну а если пофантазировать? Объект - это нечто целостное. Он имеет поведение. Тоже целостное. Не кажется, что понятие "метод", "вызов" и связанные с ними - просто издержки того, что много объектов приходилось "оживлять" одним потоком выполнения, который шуровал насквозь через них?

Для статистики: мне тоже. Хотя все псих. тесты дают visual mathematician.

Особо навыком игры в шахматы не интересовался. Навскидку. Шахматы это как поступить правильно в данной ситуации. Правильно или не правильно мы узнаём по кинестетике, которая скорее всего зависит от «базы данных», что бы играть лучше нужно пополнить «базу данных» рассматривать как другие и\или сам поступали в разных шахматных ситуациях ситуациях .


Дракон и блок схема превосходно работает на небольших программках. На больших просто затыкается. Потому что В больших проектах всплывает такое понятие как система, сущности этой ситемы(предметная область), какие действия сущности друг над другом производят, какие между ними зависимости, и неплохо бы, визуальное представление системы скрестить с драконом.
Когда разбираю чужой код, дабы расширить функционал, пытаюсь набросать отдельные(маленькие) куски системы, визуально. Иду от общего к частному. Алгоритм примерно такой. Собираю маленькие кусочки, пытаюсь их понять по отдельности, выделяю сущности и ищу между ними зависимости. Периодически пытаюсь собрать всё вместе и понять как они работают. Если не получается делаем наброски дальше. Если получилось. Рисуем общую картину. Вот тут, как то автоматически приходит понимание, как можно дописать, расширить функционал.

Хотелось бы, конечно, смоделировать стратегии с успешных программистов и выяснить в чём фикус. И как они делают, то что делают, как они изучают программы, как составляют и.т.д. Причём как архитекторов, тестировщиков, так и обычных программистов. Думаю, что по результатам такого проекта можно будет существенно пересмотреть подходы как к программированию, так и к обучению программированию. Намётки есть, разбираю свои стратегии как могу. Думаю даже скоро смогу нарисовать как я себе представляю алгоритмы программ.

Опрашивать не надо. Нужно дать дать среднюю программку одним на псевдо коде, а лучше на реальном коде, а второй группе в виде блок схем, диаграмм. Посадить их раздельно. И через полчаса у каждого узнать кто что понял в работе программы.

Этот мягкий знак не к месту лично у меня сильно отбивает желание читать тексты очередного "писателя".
Позволю себе напомнить правило, которое рекомендуют филологи для проверки, где писать мягкий знак. Надо правильно поставить вопрос "что делать?" или "что делает?". И ставить мягкий знак, только если он есть в соответствующем вопросе.
Примеры:
"Что делать?" - "надо стремиться", "будем стараться", "придется обходиться".
"Что делает?" или "что делают" - "он стремится", "они стараются", "она обходится"
Неужели это трудно выучить или слишком накладно применять?

Полагаю, что накладно применять. Во-первых, нужен какой-то "стоп", который заставит остановиться и подумать вовремя. Во-вторых, нужно правильно применить правило (ну, с этим проще). Большинство "двоечников" (проверял!) обязательно напишут "придёться обходится", даже не задумываясь ни о каких правилах

Поэтому важно сразу сформировать правильный образ, чтобы ни правила, ни "стопы" не были нужны вовсе!

Между прочим (опять же проверено!) осознание сути (и происхождения) слова помогает значительно лучше, нежели банальное правило "что делать? что делает?". Для многих понимание того, что "-ся" есть сокращённая и присоединённая к слову форма "себя", было великим и впечатляющим открытием. И, вроде бы, работает успешно!

Почему? Подозреваю, потому, что правило с вопросами обезличенное, абстрактное, скучное, бесконечно далёкое от интересов и потребностей человека с образным видением - вот он и не врубается в эту абстракицю.
А суть слова - она живая! Чувствовать живой язык веселее и проще, чем абстракции псевдокода!

Это всего лишь первый, комбинаторный уровень игры. Выше третьего-второго разряда так не подняться. Качественно новый уровень игры появляется тогда, когда человек оценивает позицию "в целом", видит в понятиях стратегии и тактики, а не в движениях конкретных фигур. Однако и здесь есть предел - возможности комбинирования тех же стратегических паттернов.
Не могу сказать точно, кто поднимается на следующий уровень - может быть, гроссместеры? Там уже действует творчество

Расскажите это Паронджанову, который собаку съел на больших проектах и практически проверил, что именно систематизация графического представления позволяет эти большие проекты успешно вести!

Ну, концепция программы как совокупности автономно живущих объектов, обменивающихся сообщениями мне известна еще по книжке Мейерса "Надежность...".
Но в практическом программировании (на БЭСМ-6, ЕС, СМ и прочими ЭВМ) не приходилось задумываться о практической реализации такой концепции.
Сейчас можно заняться., посмотрим, что получится.

Вот этот аргумент про невозможность графического представления "больших программ" мне кажется не заслуживающим внимания! Широко применяемые средства декомпозиции как раз и служат тому, чтобы программы были не большими, а обозримыми. Человек просто физически не может разом обозреть большую и сложную систему, поэтому система разбивается на небольшие, взаимодействующие меж собой компоненты. Поэтому графическое представление применимо как на уровне внутренней логики компонентов, так и на уровне взаимодействия компонентов.

Смешно сказать, но мне кажется, что блок-схемы более полезны для больших систем, чем для маленьких. Поскольку можно применять раскин-подход для отображения работы системы на разных уровнях.

Точно!

Ну, лично меня тут термин "блок-схемы" раздражает. Потому как в самих блок-схемах нет стройного механизма декомпозиции.
Тогда надо брать SADT или IDEFx - вот там декомпозиция непосредственно в графический язык встроена.
А "блок-схемы" просто устарели.

ДРАКОН - не "блок-схемы".

Это те же стопы.

Не совсем. То, что помогает понять суть, тем самым способствует формированию "идеального образа". Три раза сработает как стоп, на седьмой уже само пойдёт