Здравствуйте, LaptevVV, Вы писали:

LVV>Процедура и сейчас должна быть маленькой...

Почему?

LVV>И дело не в экране.
LVV>А в размере страницы памяти и кэша.

Т.е. размеры экранов должны увеличиваться пропорционально размерам страницы памяти и кеша?

LVV>>И дело не в экране.
LVV>>А в размере страницы памяти и кэша.
IT>Т.е. размеры экранов должны увеличиваться пропорционально размерам страницы памяти и кеша?
Зачем?
При чем здесь экран.
Если функция помещается в страницу, то на ней не будет качания страниц.
Если функция помещается в кэш, то на ней не будет качания кэша.

Здравствуйте, LaptevVV, Вы писали:

LVV>Если функция помещается в страницу, то на ней не будет качания страниц.
LVV>Если функция помещается в кэш, то на ней не будет качания кэша.

Мы с тобой об одних и тех же страницах?

Здравствуйте, IT, Вы писали:

IT>...простые диаграммы вынуждают нас прокручивать их по вертикали...

Это не так. Прокручивать по вертикали ничто не вынуждает. Если простая диаграмма (примитив) имеет большую высоту, это ошибка и нарушение правил. Нужно ее разделить на части и превратить в силуэт.

IT>Интересно, как будет выглядеть такая диаграмма, если у неё в одном блоке будет 15 элементов, а в другом 2. Боюсь, что таких ровненьких алгоритмов, как в этой презентации, в жизни существует не много.

Блок (ветка силуэта) из 15 икон надо разделить по смыслу на две (или даже три) ветки. Тут нет никакой проблемы. Это делается моментально.

В программе "ИС Дракон" вопрос "изменить высоту схемы" решается просто.

В контекстных меню есть пункты "Разделить Примитив, Ветку" и "Объединить Ветки".

https://forum.drakon.su/viewtopic.php?p=104975#p104975

IT>Этот способ известен лет сорок и звучит как "процедура должна помещаться на экране".

Вы ищете аналоги в текстовом программировании (textual programming).
Дракон — это визуальное программирование (visual programming).
Тут надо соблюдать осторожность с выводами. Прямых аналогий здесь нет.

Здравствуйте, Владимир Паронджанов

Поменьше болда, пожалуйста.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Вы ищете аналоги в текстовом программировании (textual programming).
ВП>Дракон — это визуальное программирование (visual programming).
ВП>Тут надо соблюдать осторожность с выводами. Прямых аналогий здесь нет.
В общем случае взаимодействие объектов это граф. Каждую ветвь графа можно отобразить как алгоритм. Или как двухмерное изображение как графики Дракона. Т.е. в общем случае необходимо иметь несколько видов редактирования. Графический-типа Consructor для формирования общего взаимодействия типа как строятся формы, графический типа дракон-блок схема, графический в виде графа, текстовый и даже табличный для отображения объектов одного класса, и само собой текстовый! Все эти виды должны быть равноправны в смысле резудьтата.

LVV>>Если функция помещается в страницу, то на ней не будет качания страниц.
LVV>>Если функция помещается в кэш, то на ней не будет качания кэша.
IT>Мы с тобой об одних и тех же страницах?
Вообще не понял.
Мы на разных машинах.

Здравствуйте, LaptevVV, Вы писали:

IT>>Мы с тобой об одних и тех же страницах?
LVV>Вообще не понял.
LVV>Мы на разных машинах.

Ты уже бухой что-ли? Вроде рано ещё.

IT>>>Мы с тобой об одних и тех же страницах?
LVV>>Вообще не понял.
LVV>>Мы на разных машинах.
IT>Ты уже бухой что-ли? Вроде рано ещё.
Я не пью...
Поясни, при чем здесь мы с тобой, да еще на одних страницах?
Вроде шел разговор о том, что надо писать маленькие процедуры.
Кроме того, что они читабельные, повышают сопровождаемость проекта, так еще аппаратные причины есть писать их маленькими.
О чем я и сказал.
А ты о чем?

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Если простая диаграмма (примитив) имеет большую высоту, это ошибка и нарушение правил.

Т.е. если диаграмма не вмещается на мониторе моего лаптопа с 13" дисплеем, то это нарушение правил. Но если она же помещается на 34" мониторе повёрнутым вертикально, то это уже вовсе не нарушение правил. Понятно. Именно это я и хотел прояснить.

ВП>Нужно ее разделить на части и превратить в силуэт.

А когда закончится ширина экрана, то во что будем превращать силуэт?

IT>>Интересно, как будет выглядеть такая диаграмма, если у неё в одном блоке будет 15 элементов, а в другом 2. Боюсь, что таких ровненьких алгоритмов, как в этой презентации, в жизни существует не много.

ВП>Блок (ветка силуэта) из 15 икон надо разделить по смыслу на две (или даже три) ветки. Тут нет никакой проблемы. Это делается моментально.

Это если в разделении есть смысл. А если нету?

IT>>Этот способ известен лет сорок и звучит как "процедура должна помещаться на экране".

ВП>Вы ищете аналоги в текстовом программировании (textual programming).

Я ищу аналоги в здравом смысле. Пока я вижу, что дракон решает, что программист делает правильно, а что неправильно в зависимости от разрешения его монитора. Именно об этом я и говорил в своём первом сообщении: проходили, вердикт — нафик, вернёмся, когда мониторы будут поддерживать расширения 100000x50000.

Здравствуйте, LaptevVV, Вы писали:

IT>>Ты уже бухой что-ли? Вроде рано ещё.
LVV>Я не пью...

Вот и я не понял

LVV>Поясни, при чем здесь мы с тобой, да еще на одних страницах?

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

LVV>Вроде шел разговор о том, что надо писать маленькие процедуры.

Да, это идиотский разговор. Не надо писать маленькие процедуры. Надо писать такие процедуры, которые надо.

LVV>Кроме того, что они читабельные, повышают сопровождаемость проекта, так еще аппаратные причины есть писать их маленькими.

Искуственное разбиение кода на типа читабельные методы там, где это не нужно совершенно не делает код более читабельным и обязательно снижает сопровождаемость проекта. А по поводу аппаратных причин, у тебя есть статистика, исследования, что-нибудь посмотреть и сравнить? Или это просто домыслы? Хорошо бы пример кода на C#, который можно было бы погонять в домашних условиях.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Это не так. У языка Дракон есть мощные средства декомпозиции.
Имхо графические схемы не нужны при описании алгоритмов. Они нужны при описании процессов (где исполнитель не один и всё крутится одновременно и событийно).
Вот интересно какие такие мощные средства декомпозиции. Из презентации видно даже простая логика обработки отказов превращается дикий ужас. Не говоря уже о вложенных алгоритмах.
ВП>Чем сложнее алгоритмы, тем больше выигрыш от использования Дракона.
https://www.youtube.com/watch?v=P2yr-3F6PQo&t=1394

IT>Выше говорилось, что размер процедур в одну страницу — это дебильное правило, продиктованное прежде всего ограничениями архаичных мониторов, с отсутсвием скроллинга как такового. Ты же начал про размер страниц памяти
LVV>>Вроде шел разговор о том, что надо писать маленькие процедуры.
IT>Да, это идиотский разговор. Не надо писать маленькие процедуры. Надо писать такие процедуры, которые надо.
LVV>>Кроме того, что они читабельные, повышают сопровождаемость проекта, так еще аппаратные причины есть писать их маленькими.
IT>Искуственное разбиение кода на типа читабельные методы там, где это не нужно совершенно не делает код более читабельным и обязательно снижает сопровождаемость проекта. А по поводу аппаратных причин, у тебя есть статистика, исследования, что-нибудь посмотреть и сравнить? Или это просто домыслы? Хорошо бы пример кода на C#, который можно было бы погонять в домашних условиях.
1. Есть вот такая книжка: https://www.labirint.ru/books/562034/
Там автор со статистикой приводит доводы в пользу небольших размеров.
2. Мой личный опыт разработки научных программ по моделированию перколяционных процессов показал мне влияние кэша на скорость работы.
Правда у меня это касалось конкретно кэша данных.

Здравствуйте, LaptevVV, Вы писали:

LVV>1. Есть вот такая книжка: https://www.labirint.ru/books/562034/
LVV>Там автор со статистикой приводит доводы в пользу небольших размеров.

И какие они должны быть небольшие? В KB или MB?

LVV>2. Мой личный опыт разработки научных программ по моделированию перколяционных процессов показал мне влияние кэша на скорость работы.
LVV>Правда у меня это касалось конкретно кэша данных.

Мой личный опыт разработки энтерпрайз и open-source проектов показал мне абсолютное отсутствие какого-либо влияния кеша на скорость работы. При этом оптимизациям производительности в этих проектах уделяется существенное внимание.

LVV>>1. Есть вот такая книжка: https://www.labirint.ru/books/562034/
LVV>>Там автор со статистикой приводит доводы в пользу небольших размеров.
IT>И какие они должны быть небольшие? В KB или MB?
Там мужик, видимо из консалтинговой конторы, приводит данные по успешным проектам.
Написано, что 85% методов/функций должны быть в объеме 15-30 строк исходного кода.
Тогда проект по сопровождаемости/модификации имеет ранг 4 звезды (всего — 5 звезд — как это принято на западе... ).
Мартин Фаулер в новом издании книжки Рефакторинг в 1 вводной главе проводит рефакторинг функции из примерно 50-70 строк (может 100 — не уточнял)
и разбивает ее на смысловые независимые части, которые оформляет в более короткие функции.
LVV>>2. Мой личный опыт разработки научных программ по моделированию перколяционных процессов показал мне влияние кэша на скорость работы.
LVV>>Правда у меня это касалось конкретно кэша данных.
IT>Мой личный опыт разработки энтерпрайз и open-source проектов показал мне абсолютное отсутствие какого-либо влияния кеша на скорость работы. При этом оптимизациям производительности в этих проектах уделяется существенное внимание.
Ну, скорее всего, там производительность зависит от работы с базой данных.
У меня была другая ситуация.
Квадратная матрица со стороной 10000/20000/30000/40000 элементов заполняется определенным образом отрезками элементов по вертикали и горизонтали.
Отрезки размером от 2 элементов и больше — все одинаковые.
1 раз заполнение — это 1 шаг моделирования.
Потом матрицу очищаем и по-новой.
Таких шагов — не менее 1000, а лучше больше.
Поэтому скорость выполнения 1 шага — критична.
Да, и работа велась еще в 32-битной системе на моем ноуте с win7.
Естественно, делал профилирование, смотрел все показатели.
И заметил, что при работе в матрице по вертикали скорость в 4 раза меньше, чем при работе по горизонтали.
Работа совершенно идентичная, кроме порядка индексов.
Повысил скорость, перед работой по вертикали переписывал столбец в голизонтальный вектор.
Замедление составило 1.25, по сравнению с 4 это очень существенно.
Поэтому для задач-числодробилок больших объемов в памяти кэш играет рояль.

Здравствуйте, IT, Вы писали:

IT>Т.е. если диаграмма не вмещается на мониторе моего лаптопа с 13" дисплеем, то это нарушение правил.

Вовсе нет. Правила Дракона совсем другие.

• Алгоритмы и программы следует изображать как силуэты.
• Сложные алгоритмы и программы следует изображать как силуэты, в которых многократно используются иконы «Вставка». Последние, в свою очередь, раскрываются как силуэты и т.д.
• Примитивы рекомендуется не использовать совсем или использовать в простейших случаях.

IT>А когда закончится ширина экрана, то во что будем превращать силуэт?

Горизонтальная прокрутка или использование Вставок.

IT>Это если в разделении есть смысл. А если нету?

Смысл всегда можно найти. Проблемы нет никакой. Это вопрос об имени ветки.

IT>Я ищу аналоги в здравом смысле. Пока я вижу, что дракон решает, что программист делает правильно, а что неправильно в зависимости от разрешения его монитора. Именно об этом я и говорил в своём первом сообщении: проходили, вердикт — нафик, вернёмся, когда мониторы будут поддерживать расширения 100000x50000.

Увы, Ваше последнее замечание не имеет никакого отношения к языку Дракон.
В качестве ответа на Ваш вердикт повторю слова Романа Озерова:

Я на ДРАКОНе работаю уже 6 лет.
Любое создание программы начинаю с него и при отладке работаю только с ним.

Скорость разработки, качество возрастает в разы!
ДРАКОН это сила, но многие не догоняют, думают, что это обычная блок-схема...

https://bit.ly/2NHnYzb см. комментарии к видео

Здравствуйте, LaptevVV, Вы писали:

IT>>И какие они должны быть небольшие? В KB или MB?
LVV>Там мужик, видимо из консалтинговой конторы, приводит данные по успешным проектам.
LVV>Написано, что 85% методов/функций должны быть в объеме 15-30 строк исходного кода.

А остальные 15% можно по 10000 строк?

LVV>Тогда проект по сопровождаемости/модификации имеет ранг 4 звезды (всего — 5 звезд — как это принято на западе... ).

Да-да, мы сами себе определяем ранги и сами себя по ним оцениваем. Я тоже так умею.

LVV>Мартин Фаулер в новом издании книжки Рефакторинг в 1 вводной главе проводит рефакторинг функции из примерно 50-70 строк (может 100 — не уточнял)
LVV>и разбивает ее на смысловые независимые части, которые оформляет в более короткие функции.

Не стоит произность это имя в приличном обществе. Этот человек, открывший ящик Пандоры, будет гореть в аду и минимум пару тысяч лет будет разгребать свои интерпрайз паттерны в исполнении индусов.

Но главное, что про KB/MB ты мне так и не ответил. А прикол в том, что код на 20-30 строк в компилированном виде вряд ли потянет хотя бы на 1 KB. Т.е. при размере современных кешей в мегабайты, туда целиком может поместиться вся программа. Либо, по твоей логике, одна процедура, даже если в ней не 20-30, а 20-30 * 1000 = 20000-30000 строк

И ещё по поводу строк и размера бинарного кода. Всё зависит от выразительности языка. Например, плотненькие два десятка строк паттерн матчинга легко заменяют пару сотен строк аналогичного кода на ифах, но при этом компилируются в аналогичный код. Как ты это будешь учитывать?

LVV>>>2. Мой личный опыт разработки научных программ по моделированию перколяционных процессов показал мне влияние кэша на скорость работы.
LVV>>>Правда у меня это касалось конкретно кэша данных.
IT>>Мой личный опыт разработки энтерпрайз и open-source проектов показал мне абсолютное отсутствие какого-либо влияния кеша на скорость работы. При этом оптимизациям производительности в этих проектах уделяется существенное внимание.
LVV>Ну, скорее всего, там производительность зависит от работы с базой данных.

В том числе. Вычислений тоже хватает.