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

V>>Изачально ведь был автокод.
V>>Это и был "технический проект"?
V>>А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый.
L>И? Они до сих пор оба используются. Кое-где.

Дык, они и тогда использовались "кое-где", а основное сложное ПО, про которое можно было сказать, что это ПО имеет архитектуру — оно писалось на автокоде.
Повторяю вопрос: автокод — это и был "технический проект"?


L>Только какое они имеют отношение к осбуждаемой теме?

Это демонстрация изрекаемой тобой чуши.

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


L>>>То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы.
V>>Программа точно так же без проблем разбивается на любые "квадратики" в любом своём слое.
L>Совершенно верно. И в большинстве случаев — совершенно бессмысленно.

Большинство написанного кода тоже выкидывается.
Хотя бы в процессе его улучшения/переписывания.

Означает ли это, что код не надо писать вовсе? ))


L>Если разработчику при работе над конкретным модулем нужно держать в голове 7 уровенй иерархий проектирования

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


L>то вы проектируете что-то не то. Или не так. Или все вместе.

Или ты сталкивался только с простейшими вещами по работе.


V>>Поэтому, графические представления никогда из программирования не уйдут.
V>>И не важно, по какой нотации они выполнены.
L>Натравливаешь на код doxygen, он рисует достаточное графическое представление.

))


V>>Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде.
V>>Мы не молимся на UML в своей конторе ни разу, но расписать в различных графических нотациях роли и поведение основных сущностей мне как-то пришлось, потому что из кода не понималось.
L>Так согласно одной довольно известной догме программирования, это означает, что код — говно-с

С таким подходом для тебя любой код говно-с, который чуть сложнее 2+2.

Чтобы понимать код, в первую очередь надо понимать, что именно он делает.
И вот код делает что-то нетривиальное — без предварительного понимания закодированных процессов смотреть в код бесполезно.


L>А если серьезно, то никаких проблем в комментариях описать диаграмму поведения модуля на языке plantuml, и доксиген тебе ее интегрирует прямо в документашку.

Диаграмма поведения на ём толком не описывалась и сегодня имеет ряд ограничений.
Например, мне надо несколько стартовых точек и несколько конечных.

И эта диаграмма описывает поведение системы из примерно десятка объектов.
В комментари к какому из них мне нарисовать диаграмму их общей многопоточной активности?

Правильный ответ — ни к какому, оно будет жить отдельно от каждого из участвующих объектов, как и есть сейчас.


V>>Туда же псевдокод для обяснения сущности применённых "трюков".
L>А не надо применять "трюки".

Бгг, "трюки" нужны для кодирования даже банального JPG (БПФ).


L>>>Короче, для кода САПР — это IDE со всеми плюшками.
V>>САПР в программировании — это примерно такое:
L>Ага, вот именно вот так и продавались аналоги RR в начале нулевых. Как пылесосы Кирби.

Да там один вменяемый был аналог.


L>Категоричность?
L>Софтовые конторы сейчас рисуют подробные UML модели примерно... ээ, да никогда.

"Подробные" — это стадия торговли.
Или таки абсолютно никогда?
Если последнее — сразу ха-ха три раза.
Это в наколенных конторах не рисуют, где ничего сложного и не разрабатывают.


L>Затраты времени на их построение себя не оправдывают.
L>Вот набросать квадратиков за 15 минут — да.

Оно примерно столько времени и требует.
Пусть иногда чуть больше, чем 15 минут, а даже около часа на некую подробную sequence-диаграмму, но оно потом экономит многие человекодни.



L>>>Нет смысла запоминать изначально ущербную вымученную нотацию.
V>>"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так.
V>>Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного.
V>>И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна.
L>Иными словами — это лишняя сущность. Вымученная. О чем я тебе и говорю.

Твоё "говорю" означает "раздавать оценочные суждения", т.е. суждения нулевой полезности. ))


L>Если ты собрался брать меня на слабо, то ты опоздал на сорок лет.
L>Конечные автоматы — моя любимая фишка в принципе. Наличие state diagram в любом UML редакторе лично мне помогает вбивать в голову юным падаванам правильные инженерные практики.

Но state diagram однопоточна.
Что делать в случае трёх и более взаимодействующих потоков?

Неужели надо брать другой вид диаграммы?


V>>Разумеется, в этих моих рассуждениях суть была не конкретно в диаграмме состояний, а в твоей категоричности.
V>>Про диаграмму состояний — это лишь очередной пример, демонстрирующий нелепость феномена упоротости.
L>Пока что только ты показываешь узость кругозора и приписываине собеседнику своих домыслов.

Пока что мне просто весело от такой незамутнённости.


V>>Да ладно, многие коллеги прекрасно читают без словаря.
L>А ты сам?

Длиннее в любом случае.


V>>Загвоздка чаще в том как стиллистически грамотно писать, какой оборот речи каким понятиям/ситуациям или даже комбинациям слов больше подходит — вот тут требуется выход на следующий уровень владения языком. ))
L>И чтобы на этот уровень выйти, нужно на языке общаться, читать и писать.

Отож.


V>>В UML примерно так же, как и в любой другой области.
V>>Например, понимать уже готовые электрически схемы гораздо проще, чем проектировать их.
V>>Понимать принципы действия ДВС со всеми новомодными "трюками" тоже проще, чем эти трюки изобретать/проектировать, и т.д. и т.п.
L>Какая-то у тебя каша в голове, честное слово.

Да там сразу было понятно, что тебе ничего не понятно.
State-диаграмм ему достаточно.
Ну ОК, с этого надо было начинать. ))

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

V>>Изачально ведь был автокод.
V>>Это и был "технический проект"?
V>>А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый.
L>И? Они до сих пор оба используются. Кое-где.

Дык, они и тогда использовались "кое-где", а основное сложное ПО, про которое можно было сказать, что это ПО имеет архитектуру — оно писалось на автокоде.
Повторяю вопрос: автокод — это и был "технический проект"?


L>Только какое они имеют отношение к осбуждаемой теме?

Это демонстрация изрекаемой тобой чуши.

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


L>>>То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы.
V>>Программа точно так же без проблем разбивается на любые "квадратики" в любом своём слое.
L>Совершенно верно. И в большинстве случаев — совершенно бессмысленно.

Большинство написанного кода тоже выкидывается.
Хотя бы в процессе его улучшения/переписывания.

Означает ли это, что код не надо писать вовсе? ))


L>Если разработчику при работе над конкретным модулем нужно держать в голове 7 уровенй иерархий проектирования

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


L>то вы проектируете что-то не то. Или не так. Или все вместе.

Или ты сталкивался только с простейшими вещами по работе.


V>>Поэтому, графические представления никогда из программирования не уйдут.
V>>И не важно, по какой нотации они выполнены.
L>Натравливаешь на код doxygen, он рисует достаточное графическое представление.

))


V>>Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде.
V>>Мы не молимся на UML в своей конторе ни разу, но расписать в различных графических нотациях роли и поведение основных сущностей мне как-то пришлось, потому что из кода не понималось.
L>Так согласно одной довольно известной догме программирования, это означает, что код — говно-с

С таким подходом для тебя любой код говно-с, который чуть сложнее 2+2.

Чтобы понимать код, в первую очередь надо понимать, что именно он делает.
И вот код делает что-то нетривиальное — без предварительного понимания закодированных процессов смотреть в код бесполезно.


L>А если серьезно, то никаких проблем в комментариях описать диаграмму поведения модуля на языке plantuml, и доксиген тебе ее интегрирует прямо в документашку.

Диаграмма поведения на ём толком не описывалась и сегодня имеет ряд ограничений.
Например, мне надо несколько стартовых точек и несколько конечных.

И эта диаграмма описывает поведение системы из примерно десятка объектов.
В комментари к какому из них мне нарисовать диаграмму их общей многопоточной активности?

Правильный ответ — ни к какому, оно будет жить отдельно от каждого из участвующих объектов, как и есть сейчас.


V>>Туда же псевдокод для обяснения сущности применённых "трюков".
L>А не надо применять "трюки".

Бгг, "трюки" нужны для кодирования даже банального JPG (БПФ).


L>>>Короче, для кода САПР — это IDE со всеми плюшками.
V>>САПР в программировании — это примерно такое:
L>Ага, вот именно вот так и продавались аналоги RR в начале нулевых. Как пылесосы Кирби.

Да там один вменяемый был аналог.


L>Категоричность?
L>Софтовые конторы сейчас рисуют подробные UML модели примерно... ээ, да никогда.

"Подробные" — это стадия торговли.
Или таки абсолютно никогда?
Если последнее — сразу ха-ха три раза.
Это в наколенных конторах не рисуют, где ничего сложного и не разрабатывают.


L>Затраты времени на их построение себя не оправдывают.
L>Вот набросать квадратиков за 15 минут — да.

Оно примерно столько времени и требует.
Пусть иногда чуть больше, чем 15 минут, а даже около часа на некую подробную sequence-диаграмму, но оно потом экономит многие человекодни.



L>>>Нет смысла запоминать изначально ущербную вымученную нотацию.
V>>"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так.
V>>Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного.
V>>И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна.
L>Иными словами — это лишняя сущность. Вымученная. О чем я тебе и говорю.

Твоё "говорю" означает "раздавать оценочные суждения", т.е. суждения нулевой полезности. ))


L>Если ты собрался брать меня на слабо, то ты опоздал на сорок лет.
L>Конечные автоматы — моя любимая фишка в принципе. Наличие state diagram в любом UML редакторе лично мне помогает вбивать в голову юным падаванам правильные инженерные практики.

Но state diagram однопоточна.
Что делать в случае трёх и более взаимодействующих потоков?

Неужели надо брать другой вид диаграммы?


V>>Разумеется, в этих моих рассуждениях суть была не конкретно в диаграмме состояний, а в твоей категоричности.
V>>Про диаграмму состояний — это лишь очередной пример, демонстрирующий нелепость феномена упоротости.
L>Пока что только ты показываешь узость кругозора и приписываине собеседнику своих домыслов.

Пока что мне просто весело от такой незамутнённости.


V>>Да ладно, многие коллеги прекрасно читают без словаря.
L>А ты сам?

Длиннее в любом случае.


V>>Загвоздка чаще в том как стиллистически грамотно писать, какой оборот речи каким понятиям/ситуациям или даже комбинациям слов больше подходит — вот тут требуется выход на следующий уровень владения языком. ))
L>И чтобы на этот уровень выйти, нужно на языке общаться, читать и писать.

Отож.


V>>В UML примерно так же, как и в любой другой области.
V>>Например, понимать уже готовые электрически схемы гораздо проще, чем проектировать их.
V>>Понимать принципы действия ДВС со всеми новомодными "трюками" тоже проще, чем эти трюки изобретать/проектировать, и т.д. и т.п.
L>Какая-то у тебя каша в голове, честное слово.

Да там сразу было понятно, что тебе ничего не понятно.
State-диаграмм ему достаточно.
Ну ОК, с этого надо было начинать. ))