Сообщение Re[41]: MS забило на дотнет. Питону - да, сишарпу - нет? от 09.08.2021 22:37
Изменено 09.08.2021 22:56 vdimas
Re[41]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Угу, на паскале.
V>>С общим объемом зависимостей в конкретной программе в несколько десятков символов.
V>>Уже после этого стоило бы завязывать с тобой общение. ))
S>Да я и не настаиваю. Не обязательно писать бред именно мне.
Так остановись, не пиши.
S>Но вы же, наверное, понимаете, что если машинке хватает памяти вычитать X тысяч символов из .h файлов и держать их "в уме", то ей будет ничуть не сложнее вычитать эти же символы из модулей?
Насчёт "эти же символы" — опять было некогда думать? ))
Или хотя бы немного погуглить?
Исторически набор h-файлов обычно шёл уникальный и минимально-необходимый для конкретного С++ файла.
В случае модулей на практике всегда будет максимальный набор символов, а не минимально-необходимый.
Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем.
Еще пример — в нулевых, да и в десятых, в линухах не очень пользовалась успехом технология предкомпиляции общих заголовков, когда в некий stdafx.h/pch.hpp и т.д. как в мусорное ведро пихают максимум зависимостей, а на виндах это было чуть ли не стандартом.
А дело в том, что у виндов зависимостей обычно кот наплакал: одна на всех WinAPI, сверху тоненький в публичном АПИ MFC, ну и всё, собсно.
А в Линухах обычно шли кучерявые бесконечные зависимости, т.е. это всегда была сборная солянка отовсюду.
Там средний вшивости пакет может вытянуть за собой еще 20-50 пакетов.
А если не вытянул — это потому что их уже притянули ранее.
В общем, у самого много раз компиляция под линухами молча подвисала при нехватке памяти в те года, если злоупотреблял предкомпляцией.
S>А скорее даже проще, потому как можно держать готовые символы, а не AST в ожидании того, что же у нас там такое окажется в .cpp файле после всех рекурсивных инклюдов.
Разумеется, можно считывать модули и в lazy-режиме, т.е. изначально читать просто список символов, а определения конкретных шаблонов, инлайн-функций и макросов — лишь по мере их задействования в компиляции.
Но не об этом ведь шла речь, бо, разумеется, это всё не проблема для современных размеров памяти.
Я делал замечание на твою очередную наивность в духе "надо было так сделать сразу!"
Мол, "в нормальных технологиях так давно".
Это значит, что ты никогда не писал достаточно больших проектов на том же Турбо-Паскале, т.е. не в курсе проблематики.
V>>В итоге, на этапе бурного кодирования мне приходится разбивать целевой проект на десятки их, потом склеивая обратно, когда нужный функционал более-менее отлажен, т.е. перетекает в стадию использования и поддержки.
S>Вы просто не умеете пользоваться C#.
У меня другая версия — тебе кажется странной сама задача активного манипулирования описанием билда.
(но таким мнением хвастаться не принято в современном мире)
S>Ничего в этом стыдного нет — нужно просто освоиться, перестать страдать, и начать наслаждаться.
Да ради бога, кто на что учился, как грится.
А то, судя по одному из обсуждений, ты выбрал расслабуху на работе, а реал пошёл по остаточному принципу.
S>Нет никакой нужды ничего разбивать на проекты — ни на единицы, ни на десятки. И склеивать потом не надо. Я пробовал так делать — лишняя боль и страдания на ровном месте.
Эээ, простите, "склеивать"? ))
Т.е. ты в 2021-м не в курсе, что MSBuild уже скоро 20 лет как умеет включать описания проектов друг в друга?
И что удобнее всего описывать проекты небольшими сниппетами, где целевой проект получается как иерархичное их влючение, т.е. типа обычная программа на основе библиотек, но на уровне MSBuild.
В Ant аналогично, кстате, ты же из джавы пришёл, неужели не пользовался такой фичей? ))
Но да, в самом конце "быстрой" первоначальной итерации разработки все-равно придётся код описания проектов переписать начисто, увы.
И стараться не править его из GUI Студии, а то там каша получается, а не исходник.
S>Модули имеет смысл выделять тогда, когда уже видны их логические границы — ни раньше, ни позже.
За одно это утверждение тебя уже можно смело увольнять.
(ниже объяснюсь, это уже не первое подобное заявление и не последнее в ряду их)
S>Если у вас сразу продумана вся архитектура (у меня так бывает редко), то можете сразу напилить нужное количество проектов. Если логические границы становятся понятны только после того, как написано много кода — ну вот тогда и выделяйте.
Художник-абстракционист рассуждает о том, как инженеру лучше чертить. ))
"Логические границы"...
Это в таких категориях ПО разрабатываешь?
S>А вот это вот напиливание избыточного количества проектов — зачем оно?
Почему "избыточного"? ))
См. определения этого слова.
Цель каждого отдельного проекта — быть независимой единицей компиляции.
Поэтому, такой проект может и включает обычно одну некую функциональность.
Низкая связанность/высокое зацепление — это общий принцип, в основе DDD лежит в том числе одним из первых.
Заодно такой подход развязывает руки в экспериментировании, т.е. не надо создавать ветки в гите — это банально лишее, удобней все варинты/эксперименты держать перед глазами одновременно.
В общем, отдельные проекты позволяют такие шалости, не ругая за конфликты имен.
И потому что через систему include MSBuild-описаний, т.е. повторного их использования, можно задешево покрыть относительно большую комбинаторику сочетаний вариантов кода для целей проведения экспериментов.
S>Тем более, что С# всё равно не даст вам собрать проект, который ссылается на разобранные проекты.
Судя по изрекаемому тобой, у тебя малость поверхностное представление насчёт того, куда и как может ссылаться проект C#.
Я ведь могу сделать проект лишь частично разобранным за нулевую трудоёмкость.
Опиши себе один мета-проект, ссылающийся на другие проекты, через один коммент включай-отключай запчасти, комбинируй, пробуй варианты и т.д. и т.п.
Для сравнения, "выключить" в исходнике класс — это нужно бегать, выключать все зависимости от него.
Разбил по проектам (которые на деле всегда подпроекты) — получил изоляцию и управляемость.
В общем, я уже понял, что отношение к задаче описания проекта именно как к задаче, являющейся неотъемлимой частью разработки, лично тебя шокирует.
Слушать это забавно, однако, особенно при рассуждении об интерфейсах и о том, что в какие сборки включать.
Ты опять пытаешься рассуждать о предметной области не погружаясь в неё.
В общем, границы проектов в конце стадии "быстрого роста" дизайна зависят от границ предметных областей и слоёв иерархии доменной модели, и ни от чего более.
Т.е., единицы деплоя, конечно, формируются по-вкусу, в меру испорченности, т.к. не запрещается в одну единицу деплоя пихать несколько элементов дизайна, групп их и т.д., но граница всё-равно проходит по границам элементов доменов (или доменов целиком), а значит и по границам слоёв дизайна (т.к. на каждом слое своя доменная модель).
S>Поэтому я так думаю, что вы сейчас рассказываете про воображаемый опыт в воображаемом программировании.
Это, типа, чего ты не видел лично, того не существует?
Как пакетных менеджеров в С++?
V>>Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить.
S>Что с чем вы предлагаете сравнить?
Наличие всей описанной возни с её отсутствием, ес-но.
V>>Они решают их натурально "пошагово", причём, довольно малюсенькими шажочками: сделают кусочек — проверят, еще небольшой кусочек — опять проверят.
S>Вы так говорите, как будто это плохо.
Это самая низкая производительность программиста из всех возможных.
S>Если я хочу двигаться пошагово — я двигаюсь пошагово.
Акцент был не пошаговости как таковой, а на размерах итераций.
Когда итерация разработки-проверки колеблется на уровне единиц строк (как во всех твоих "примерах в развитии", что ты давал от своего имени) — это примерно нулевая производительность.
V>>Это один из самых медленных способов решения задач, бо требует постоянного переключения внимания и постоянного прекращения кодирования с целью проверки каждого чиха.
S>Если я хочу бурно поиграть с кодом — я так и делаю. И мне никак не мешает то, что полпроекта "красные". Как думаете, почему?
Потому что ты не планируешь довести текущую итерацию до конца?
Т.е. раздать роли и ответственности сущностям дизайна, прописать и обкатать основные сценарии на каждом слое системы?
Даже не любопытно хотя бы просто посмотреть, как это примерно будет выглядеть? ))
V>>На плюсах более устоялся чуть другой подход — сначала достаточно "вольное" описание домена/доменов на текущем слое или куче слоёв (смотря, насколько "вглубину" задача), затем решение задач в терминах домена.
S>Точно также всё работает в C#. Вот ровно также.
Но не прижилось на практике.
Достаточно посмотреть на дизай станартных либ и систему "рекомендаций" от MS (половину из которых уже выкинули нафик к сегодняшнему дню, слава богу).
S>Я пишу вызов foo.SomeMethod() c сигнатурой, и автопорождаю этот метод.
S>Потом, когда (и если) дойдёт до реализации, я заменю все эти NotImplemented на реальный код. Что мешает вам делать также?
Мне мешает то, что это несъедобно.
Ты как раз описываешь одну из причин, почему Джава и C#-программисты позволяют себе злоупотреблять интерфейсами.
По-сути, в Джава и C# интерфейсы выродились более в инструмент развязки зависимостей, чем в инструмент описания абстрактной модели происходящего.
Т.е. я высмеивал то де-факто положение вещей, где задача развязки зависимостей зачастую не диктуется причинами технического плана, но диктуется причинами организационного, сугубо для целей совместной разработки.
V>>А ты думаешь, как мне удаётся с полутыка находить косяки в ваших решениях — твоих и любых других известных гуру даже из MS?
S>Пока вам это удаётся только языком.
Причём, русским.
Причём, обычно после прибегания тобой к чему-то как к якобы доказательству. ))
Одна из последних твоих отсылок к примеру с порождением кучи независимых потоков vs тасков дотнета, и всё это в привычной менторской манере.
А по ссылке тихий от какого-то то ли MS MVP, то ли с должности на MS, что я валяюсь с вашего непуганного заповедника...
С умной рожей приводить более молодым коллегам ошибочные примеры, проявлять строгость и непокобелимость!
Это похлеще маразматического КПСС последней стадии.
Исправленную версию примера я там же в обсуждении приводил, но такое ощущение, что ты участвуешь в обсуждениях не для выяснения истины...
Ты даже не извинился перед тем коллегой, кому дал ссылку на бред.
V>>Я, конечно, не упоротый фанат DDD-подхода, но отлично им владею и использую, среди прочих других.
V>>Но фанаты именно DDD прямо сейчас подняли бы тебя на вилы за демонстрируемую нелепость...
S>Фанаты DDD идут мимо, хоть строем, хоть в разбивку. У них вилы не отросли меня куда-то поднимать.
Фанаты DDD пишут крупнейшие современные проекты.
Я занят не в крупнейших, но в которых, наверно, сильнейшие во всей отрасли технические требования.
А да, твоё "выросло" или "не выросло"...
Ты ведь всё-равно понятия не имеешь, о чём речь.
V>>Твой якобы "вопрос-уточнение" вообще перпендикулярен проблематике.
S>Нет никакой "проблематики", есть невладение языком и средствами разработки.
Ну вот за это и уволить, как и за вопрос выше, где я тоже рекомендовал.
Твой очередной косяк тут:
Вопрос, заданный именно таким образом (в виде упрёка и заламывания рук одновременно) в публичной переписке своему коллеге, способен в любой конторе породить во внутренних чатах-переписке бесконечнейшие срачи.
Потому что вопрос неполон, и его можно привести как к корректному, так и к глупому.
По-форме в любом случае требует письменного публичного извинения и клятвенного обещания больше так не делать.
В любом случае, в такой форме и с таким содержанием вопрос заведомо провокационный, а посему заведомо бестолковый.
Автору подобных манер обычно пару раз делают замечание, если не доходит — тупо увольняют.
Это нормальная, обычная практика.
И если тебя не уволили до сих пор, это означает, что ты, на самом деле, знаешь как необходимо себя вести.
Получается, именно сюда ты ходишь отвести душу, бо общепринятое тебе тебе противоестественно, давит и утомляет. ))
А здесь можно безнаказанно гадить, можно не стараться думать, можо даже строить из себя домохозяйку со стажем.
S>А недостатки C++, в виде возможности иметь заголовки от несуществующих методов, выдаются за его преимущества.
Что позволяло компиллировать большие программы на маленьких машинах.
В 94-м году довольно большое приложение на Паскале и Turbo Vision достигло у нас c товарищами почти полумегабайта (IDE для разработки на ассемблере) и было неспособно компиллироваться в обычном DOS-режиме.
Портировали на Си (многое автоматом через глобальную замену, а многое и так было на Си — целевые парсеры/лексеры ассемблеров) — и всё прекрасно компиллировалось еще долго.
Хотя и дольше по времени. ))
V>>Разберешься — приходи.
S>В сад.
Приходи из сада. ))
Синклер, у вас опять обнаруживаются вопиющие провалы, не соответствующие объему надувания боковых поверхностей лица...
Слушай, а вообще есть в IT хотя бы одна область, в которой ты более-менее разбираешься?
Просто любопытно...
ОК, понятно, что не учился на программера, осваивал самостоятельно.
Но за 25+ лет...
Неужели за этот срок вообще ни одной областью IT ты так и не овладел?
(не, я помню твои круглые глаза когда ты узнал о кеше браузеров и кодах ответов веб-серваков, но это было не на уровне "овладел", это было наполнение эрудиции, там инфы примерно на три первых дня работы современного фронтендера)
V>>Угу, на паскале.
V>>С общим объемом зависимостей в конкретной программе в несколько десятков символов.
V>>Уже после этого стоило бы завязывать с тобой общение. ))
S>Да я и не настаиваю. Не обязательно писать бред именно мне.
Так остановись, не пиши.
S>Но вы же, наверное, понимаете, что если машинке хватает памяти вычитать X тысяч символов из .h файлов и держать их "в уме", то ей будет ничуть не сложнее вычитать эти же символы из модулей?
Насчёт "эти же символы" — опять было некогда думать? ))
Или хотя бы немного погуглить?
Исторически набор h-файлов обычно шёл уникальный и минимально-необходимый для конкретного С++ файла.
В случае модулей на практике всегда будет максимальный набор символов, а не минимально-необходимый.
Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем.
Еще пример — в нулевых, да и в десятых, в линухах не очень пользовалась успехом технология предкомпиляции общих заголовков, когда в некий stdafx.h/pch.hpp и т.д. как в мусорное ведро пихают максимум зависимостей, а на виндах это было чуть ли не стандартом.
А дело в том, что у виндов зависимостей обычно кот наплакал: одна на всех WinAPI, сверху тоненький в публичном АПИ MFC, ну и всё, собсно.
А в Линухах обычно шли кучерявые бесконечные зависимости, т.е. это всегда была сборная солянка отовсюду.
Там средний вшивости пакет может вытянуть за собой еще 20-50 пакетов.
А если не вытянул — это потому что их уже притянули ранее.
В общем, у самого много раз компиляция под линухами молча подвисала при нехватке памяти в те года, если злоупотреблял предкомпляцией.
S>А скорее даже проще, потому как можно держать готовые символы, а не AST в ожидании того, что же у нас там такое окажется в .cpp файле после всех рекурсивных инклюдов.
Разумеется, можно считывать модули и в lazy-режиме, т.е. изначально читать просто список символов, а определения конкретных шаблонов, инлайн-функций и макросов — лишь по мере их задействования в компиляции.
Но не об этом ведь шла речь, бо, разумеется, это всё не проблема для современных размеров памяти.
Я делал замечание на твою очередную наивность в духе "надо было так сделать сразу!"
Мол, "в нормальных технологиях так давно".
Это значит, что ты никогда не писал достаточно больших проектов на том же Турбо-Паскале, т.е. не в курсе проблематики.
V>>В итоге, на этапе бурного кодирования мне приходится разбивать целевой проект на десятки их, потом склеивая обратно, когда нужный функционал более-менее отлажен, т.е. перетекает в стадию использования и поддержки.
S>Вы просто не умеете пользоваться C#.
У меня другая версия — тебе кажется странной сама задача активного манипулирования описанием билда.
(но таким мнением хвастаться не принято в современном мире)
S>Ничего в этом стыдного нет — нужно просто освоиться, перестать страдать, и начать наслаждаться.
Да ради бога, кто на что учился, как грится.
А то, судя по одному из обсуждений, ты выбрал расслабуху на работе, а реал пошёл по остаточному принципу.
S>Нет никакой нужды ничего разбивать на проекты — ни на единицы, ни на десятки. И склеивать потом не надо. Я пробовал так делать — лишняя боль и страдания на ровном месте.
Эээ, простите, "склеивать"? ))
Т.е. ты в 2021-м не в курсе, что MSBuild уже скоро 20 лет как умеет включать описания проектов друг в друга?
И что удобнее всего описывать проекты небольшими сниппетами, где целевой проект получается как иерархичное их влючение, т.е. типа обычная программа на основе библиотек, но на уровне MSBuild.
В Ant аналогично, кстате, ты же из джавы пришёл, неужели не пользовался такой фичей? ))
Но да, в самом конце "быстрой" первоначальной итерации разработки все-равно придётся код описания проектов переписать начисто, увы.
И стараться не править его из GUI Студии, а то там каша получается, а не исходник.
S>Модули имеет смысл выделять тогда, когда уже видны их логические границы — ни раньше, ни позже.
За одно это утверждение тебя уже можно смело увольнять.
(ниже объяснюсь, это уже не первое подобное заявление и не последнее в ряду их)
S>Если у вас сразу продумана вся архитектура (у меня так бывает редко), то можете сразу напилить нужное количество проектов. Если логические границы становятся понятны только после того, как написано много кода — ну вот тогда и выделяйте.
Художник-абстракционист рассуждает о том, как инженеру лучше чертить. ))
"Логические границы"...
Это в таких категориях ПО разрабатываешь?
S>А вот это вот напиливание избыточного количества проектов — зачем оно?
Почему "избыточного"? ))
См. определения этого слова.
Цель каждого отдельного проекта — быть независимой единицей компиляции.
Поэтому, такой проект может и включает обычно одну некую функциональность.
Низкая связанность/высокое зацепление — это общий принцип, в основе DDD лежит в том числе одним из первых.
Заодно такой подход развязывает руки в экспериментировании, т.е. не надо создавать ветки в гите — это банально лишее, удобней все варинты/эксперименты держать перед глазами одновременно.
В общем, отдельные проекты позволяют такие шалости, не ругая за конфликты имен.
И потому что через систему include MSBuild-описаний, т.е. повторного их использования, можно задешево покрыть относительно большую комбинаторику сочетаний вариантов кода для целей проведения экспериментов.
S>Тем более, что С# всё равно не даст вам собрать проект, который ссылается на разобранные проекты.
Судя по изрекаемому тобой, у тебя малость поверхностное представление насчёт того, куда и как может ссылаться проект C#.
Я ведь могу сделать проект лишь частично разобранным за нулевую трудоёмкость.
Опиши себе один мета-проект, ссылающийся на другие проекты, через один коммент включай-отключай запчасти, комбинируй, пробуй варианты и т.д. и т.п.
Для сравнения, "выключить" в исходнике класс — это нужно бегать, выключать все зависимости от него.
Разбил по проектам (которые на деле всегда подпроекты) — получил изоляцию и управляемость.
В общем, я уже понял, что отношение к задаче описания проекта именно как к задаче, являющейся неотъемлимой частью разработки, лично тебя шокирует.
Слушать это забавно, однако, особенно при рассуждении об интерфейсах и о том, что в какие сборки включать.
Ты опять пытаешься рассуждать о предметной области не погружаясь в неё.
В общем, границы проектов в конце стадии "быстрого роста" дизайна зависят от границ предметных областей и слоёв иерархии доменной модели, и ни от чего более.
Т.е., единицы деплоя, конечно, формируются по-вкусу, в меру испорченности, т.к. не запрещается в одну единицу деплоя пихать несколько элементов дизайна, групп их и т.д., но граница всё-равно проходит по границам элементов доменов (или доменов целиком), а значит и по границам слоёв дизайна (т.к. на каждом слое своя доменная модель).
S>Поэтому я так думаю, что вы сейчас рассказываете про воображаемый опыт в воображаемом программировании.
Это, типа, чего ты не видел лично, того не существует?
Как пакетных менеджеров в С++?
V>>Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить.
S>Что с чем вы предлагаете сравнить?
Наличие всей описанной возни с её отсутствием, ес-но.
V>>Они решают их натурально "пошагово", причём, довольно малюсенькими шажочками: сделают кусочек — проверят, еще небольшой кусочек — опять проверят.
S>Вы так говорите, как будто это плохо.
Это самая низкая производительность программиста из всех возможных.
S>Если я хочу двигаться пошагово — я двигаюсь пошагово.
Акцент был не пошаговости как таковой, а на размерах итераций.
Когда итерация разработки-проверки колеблется на уровне единиц строк (как во всех твоих "примерах в развитии", что ты давал от своего имени) — это примерно нулевая производительность.
V>>Это один из самых медленных способов решения задач, бо требует постоянного переключения внимания и постоянного прекращения кодирования с целью проверки каждого чиха.
S>Если я хочу бурно поиграть с кодом — я так и делаю. И мне никак не мешает то, что полпроекта "красные". Как думаете, почему?
Потому что ты не планируешь довести текущую итерацию до конца?
Т.е. раздать роли и ответственности сущностям дизайна, прописать и обкатать основные сценарии на каждом слое системы?
Даже не любопытно хотя бы просто посмотреть, как это примерно будет выглядеть? ))
V>>На плюсах более устоялся чуть другой подход — сначала достаточно "вольное" описание домена/доменов на текущем слое или куче слоёв (смотря, насколько "вглубину" задача), затем решение задач в терминах домена.
S>Точно также всё работает в C#. Вот ровно также.
Но не прижилось на практике.
Достаточно посмотреть на дизай станартных либ и систему "рекомендаций" от MS (половину из которых уже выкинули нафик к сегодняшнему дню, слава богу).
S>Я пишу вызов foo.SomeMethod() c сигнатурой, и автопорождаю этот метод.
S>Потом, когда (и если) дойдёт до реализации, я заменю все эти NotImplemented на реальный код. Что мешает вам делать также?
Мне мешает то, что это несъедобно.
Ты как раз описываешь одну из причин, почему Джава и C#-программисты позволяют себе злоупотреблять интерфейсами.
По-сути, в Джава и C# интерфейсы выродились более в инструмент развязки зависимостей, чем в инструмент описания абстрактной модели происходящего.
Т.е. я высмеивал то де-факто положение вещей, где задача развязки зависимостей зачастую не диктуется причинами технического плана, но диктуется причинами организационного, сугубо для целей совместной разработки.
V>>А ты думаешь, как мне удаётся с полутыка находить косяки в ваших решениях — твоих и любых других известных гуру даже из MS?
S>Пока вам это удаётся только языком.
Причём, русским.
Причём, обычно после прибегания тобой к чему-то как к якобы доказательству. ))
Одна из последних твоих отсылок к примеру с порождением кучи независимых потоков vs тасков дотнета, и всё это в привычной менторской манере.
А по ссылке тихий от какого-то то ли MS MVP, то ли с должности на MS, что я валяюсь с вашего непуганного заповедника...
С умной рожей приводить более молодым коллегам ошибочные примеры, проявлять строгость и непокобелимость!
Это похлеще маразматического КПСС последней стадии.
Исправленную версию примера я там же в обсуждении приводил, но такое ощущение, что ты участвуешь в обсуждениях не для выяснения истины...
Ты даже не извинился перед тем коллегой, кому дал ссылку на бред.
V>>Я, конечно, не упоротый фанат DDD-подхода, но отлично им владею и использую, среди прочих других.
V>>Но фанаты именно DDD прямо сейчас подняли бы тебя на вилы за демонстрируемую нелепость...
S>Фанаты DDD идут мимо, хоть строем, хоть в разбивку. У них вилы не отросли меня куда-то поднимать.
Фанаты DDD пишут крупнейшие современные проекты.
Я занят не в крупнейших, но в которых, наверно, сильнейшие во всей отрасли технические требования.
А да, твоё "выросло" или "не выросло"...
Ты ведь всё-равно понятия не имеешь, о чём речь.
V>>Твой якобы "вопрос-уточнение" вообще перпендикулярен проблематике.
S>Нет никакой "проблематики", есть невладение языком и средствами разработки.
Ну вот за это и уволить, как и за вопрос выше, где я тоже рекомендовал.
Твой очередной косяк тут:
Вам так хочется, чтобы модуль А зависел от конкретного типа, определённого в модуле Б?
Вопрос, заданный именно таким образом (в виде упрёка и заламывания рук одновременно) в публичной переписке своему коллеге, способен в любой конторе породить во внутренних чатах-переписке бесконечнейшие срачи.
Потому что вопрос неполон, и его можно привести как к корректному, так и к глупому.
По-форме в любом случае требует письменного публичного извинения и клятвенного обещания больше так не делать.
В любом случае, в такой форме и с таким содержанием вопрос заведомо провокационный, а посему заведомо бестолковый.
Автору подобных манер обычно пару раз делают замечание, если не доходит — тупо увольняют.
Это нормальная, обычная практика.
И если тебя не уволили до сих пор, это означает, что ты, на самом деле, знаешь как необходимо себя вести.
Получается, именно сюда ты ходишь отвести душу, бо общепринятое тебе тебе противоестественно, давит и утомляет. ))
А здесь можно безнаказанно гадить, можно не стараться думать, можо даже строить из себя домохозяйку со стажем.
S>А недостатки C++, в виде возможности иметь заголовки от несуществующих методов, выдаются за его преимущества.
Что позволяло компиллировать большие программы на маленьких машинах.
В 94-м году довольно большое приложение на Паскале и Turbo Vision достигло у нас c товарищами почти полумегабайта (IDE для разработки на ассемблере) и было неспособно компиллироваться в обычном DOS-режиме.
Портировали на Си (многое автоматом через глобальную замену, а многое и так было на Си — целевые парсеры/лексеры ассемблеров) — и всё прекрасно компиллировалось еще долго.
Хотя и дольше по времени. ))
V>>Разберешься — приходи.
S>В сад.
Приходи из сада. ))
Синклер, у вас опять обнаруживаются вопиющие провалы, не соответствующие объему надувания боковых поверхностей лица...
Слушай, а вообще есть в IT хотя бы одна область, в которой ты более-менее разбираешься?
Просто любопытно...
ОК, понятно, что не учился на программера, осваивал самостоятельно.
Но за 25+ лет...
Неужели за этот срок вообще ни одной областью IT ты так и не овладел?
(не, я помню твои круглые глаза когда ты узнал о кеше браузеров и кодах ответов веб-серваков, но это было не на уровне "овладел", это было наполнение эрудиции, там инфы примерно на три первых дня работы современного фронтендера)
Re[41]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Угу, на паскале.
V>>С общим объемом зависимостей в конкретной программе в несколько десятков символов.
V>>Уже после этого стоило бы завязывать с тобой общение. ))
S>Да я и не настаиваю. Не обязательно писать бред именно мне.
Так остановись, не пиши.
S>Но вы же, наверное, понимаете, что если машинке хватает памяти вычитать X тысяч символов из .h файлов и держать их "в уме", то ей будет ничуть не сложнее вычитать эти же символы из модулей?
Насчёт "эти же символы" — опять было некогда думать? ))
Или хотя бы немного погуглить?
Исторически набор h-файлов обычно шёл уникальный и минимально-необходимый для конкретного С++ файла.
В случае модулей на практике всегда будет максимальный набор символов, а не минимально-необходимый.
Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем.
Еще пример — в нулевых, да и в десятых, в линухах не очень пользовалась успехом технология предкомпиляции общих заголовков, когда в некий stdafx.h/pch.hpp и т.д. как в мусорное ведро пихают максимум зависимостей, а на виндах это было чуть ли не стандартом.
А дело в том, что у виндов зависимостей обычно кот наплакал: одна на всех WinAPI, сверху тоненький в публичном АПИ MFC, ну и всё, собсно.
А в Линухах обычно шли кучерявые бесконечные зависимости, т.е. это всегда была сборная солянка отовсюду.
Там средний вшивости пакет может вытянуть за собой еще 20-50 пакетов.
А если не вытянул — это потому что их уже притянули ранее.
В общем, у самого много раз компиляция под линухами молча подвисала при нехватке памяти в те года, если злоупотреблял предкомпляцией.
S>А скорее даже проще, потому как можно держать готовые символы, а не AST в ожидании того, что же у нас там такое окажется в .cpp файле после всех рекурсивных инклюдов.
Разумеется, можно считывать модули и в lazy-режиме, т.е. изначально читать просто список символов, а определения конкретных шаблонов, инлайн-функций и макросов — лишь по мере их задействования в компиляции.
Но не об этом ведь шла речь, бо, разумеется, это всё не проблема для современных размеров памяти.
Я делал замечание на твою очередную наивность в духе "надо было так сделать сразу!"
Мол, "в нормальных технологиях так давно".
Это значит, что ты никогда не писал достаточно больших проектов на том же Турбо-Паскале, т.е. не в курсе проблематики.
V>>В итоге, на этапе бурного кодирования мне приходится разбивать целевой проект на десятки их, потом склеивая обратно, когда нужный функционал более-менее отлажен, т.е. перетекает в стадию использования и поддержки.
S>Вы просто не умеете пользоваться C#.
У меня другая версия — тебе кажется странной сама задача активного манипулирования описанием билда.
(но таким мнением хвастаться не принято в современном мире)
S>Ничего в этом стыдного нет — нужно просто освоиться, перестать страдать, и начать наслаждаться.
Да ради бога, кто на что учился, как грится.
А то, судя по одному из обсуждений, ты выбрал расслабуху на работе, а реал пошёл по остаточному принципу.
S>Нет никакой нужды ничего разбивать на проекты — ни на единицы, ни на десятки. И склеивать потом не надо. Я пробовал так делать — лишняя боль и страдания на ровном месте.
Эээ, простите, "склеивать"? ))
Т.е. ты в 2021-м не в курсе, что MSBuild уже скоро 20 лет как умеет включать описания проектов друг в друга?
И что удобнее всего описывать проекты небольшими сниппетами, где целевой проект получается как иерархичное их влючение, т.е. типа обычная программа на основе библиотек, но на уровне MSBuild.
В Ant аналогично, кстате, ты же из джавы пришёл, неужели не пользовался такой фичей? ))
Но да, в самом конце "быстрой" первоначальной итерации разработки все-равно придётся код описания проектов переписать начисто, увы.
И стараться не править его из GUI Студии, а то там каша получается, а не исходник.
S>Модули имеет смысл выделять тогда, когда уже видны их логические границы — ни раньше, ни позже.
За одно это утверждение тебя уже можно смело увольнять.
(ниже объяснюсь, это уже не первое подобное заявление и не последнее в ряду их)
S>Если у вас сразу продумана вся архитектура (у меня так бывает редко), то можете сразу напилить нужное количество проектов. Если логические границы становятся понятны только после того, как написано много кода — ну вот тогда и выделяйте.
Художник-абстракционист рассуждает о том, как инженеру лучше чертить. ))
"Логические границы"...
Это в таких категориях ПО разрабатываешь?
S>А вот это вот напиливание избыточного количества проектов — зачем оно?
Почему "избыточного"? ))
См. определения этого слова.
Цель каждого отдельного проекта — быть независимой единицей компиляции.
Поэтому, такой проект может и включает обычно одну некую функциональность.
Низкая связанность/высокое зацепление — это общий принцип, в основе DDD лежит в том числе одним из первых.
Заодно такой подход развязывает руки в экспериментировании, т.е. не надо создавать ветки в гите — это банально лишее, удобней все варинты/эксперименты держать перед глазами одновременно.
В общем, отдельные проекты позволяют такие шалости, не ругая за конфликты имен.
И потому что через систему include MSBuild-описаний, т.е. повторного их использования, можно задешево покрыть относительно большую комбинаторику сочетаний вариантов кода для целей проведения экспериментов.
S>Тем более, что С# всё равно не даст вам собрать проект, который ссылается на разобранные проекты.
Судя по изрекаемому тобой, у тебя малость поверхностное представление насчёт того, куда и как может ссылаться проект C#.
Я ведь могу сделать проект лишь частично разобранным за нулевую трудоёмкость.
Опиши себе один мета-проект, ссылающийся на другие проекты, через один коммент включай-отключай запчасти, комбинируй, пробуй варианты и т.д. и т.п.
Для сравнения, "выключить" в исходнике класс — это нужно бегать, выключать все зависимости от него.
Разбил по проектам (которые на деле всегда подпроекты) — получил изоляцию и управляемость.
В общем, я уже понял, что отношение к задаче описания проекта именно как к задаче, являющейся неотъемлимой частью разработки, лично тебя шокирует.
Слушать это забавно, однако, особенно при рассуждении об интерфейсах и о том, что в какие сборки включать.
Ты опять пытаешься рассуждать о предметной области не погружаясь в неё.
В общем, границы проектов в конце стадии "быстрого роста" дизайна зависят от границ предметных областей и слоёв иерархии доменной модели, и ни от чего более.
Т.е., единицы деплоя, конечно, формируются по-вкусу, в меру испорченности, т.к. не запрещается в одну единицу деплоя пихать несколько элементов дизайна, групп их и т.д., но граница всё-равно проходит по границам элементов доменов (или доменов целиком), а значит и по границам слоёв дизайна (т.к. на каждом слое своя доменная модель).
S>Поэтому я так думаю, что вы сейчас рассказываете про воображаемый опыт в воображаемом программировании.
Это, типа, чего ты не видел лично, того не существует?
Как пакетных менеджеров в С++?
V>>Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить.
S>Что с чем вы предлагаете сравнить?
Наличие всей описанной возни с её отсутствием, ес-но.
V>>Они решают их натурально "пошагово", причём, довольно малюсенькими шажочками: сделают кусочек — проверят, еще небольшой кусочек — опять проверят.
S>Вы так говорите, как будто это плохо.
Это самая низкая производительность программиста из всех возможных.
S>Если я хочу двигаться пошагово — я двигаюсь пошагово.
Акцент был не на пошаговости как таковой, а на размерах итераций.
Когда итерация разработки-проверки колеблется на уровне единиц строк (как во всех твоих "примерах в развитии", что ты давал от своего имени) — это примерно нулевая производительность.
V>>Это один из самых медленных способов решения задач, бо требует постоянного переключения внимания и постоянного прекращения кодирования с целью проверки каждого чиха.
S>Если я хочу бурно поиграть с кодом — я так и делаю. И мне никак не мешает то, что полпроекта "красные". Как думаете, почему?
Потому что ты не планируешь довести текущую итерацию до конца?
Т.е. раздать роли и ответственности сущностям дизайна, прописать и обкатать основные сценарии на каждом слое системы?
Даже не любопытно хотя бы просто посмотреть, как это примерно будет выглядеть? ))
V>>На плюсах более устоялся чуть другой подход — сначала достаточно "вольное" описание домена/доменов на текущем слое или куче слоёв (смотря, насколько "вглубину" задача), затем решение задач в терминах домена.
S>Точно также всё работает в C#. Вот ровно также.
Но не прижилось на практике.
Достаточно посмотреть на дизай станартных либ и систему "рекомендаций" от MS (половину из которых уже выкинули нафик к сегодняшнему дню, слава богу).
S>Я пишу вызов foo.SomeMethod() c сигнатурой, и автопорождаю этот метод.
S>Потом, когда (и если) дойдёт до реализации, я заменю все эти NotImplemented на реальный код. Что мешает вам делать также?
Мне мешает то, что это несъедобно.
Ты как раз описываешь одну из причин, почему Джава и C#-программисты позволяют себе злоупотреблять интерфейсами.
По-сути, в Джава и C# интерфейсы выродились более в инструмент развязки зависимостей, чем в инструмент описания абстрактной модели происходящего.
Т.е. я высмеивал то де-факто положение вещей, где задача развязки зависимостей зачастую не диктуется причинами технического плана, но диктуется причинами организационного, сугубо для целей совместной разработки.
V>>А ты думаешь, как мне удаётся с полутыка находить косяки в ваших решениях — твоих и любых других известных гуру даже из MS?
S>Пока вам это удаётся только языком.
Причём, русским.
Причём, обычно после прибегания тобой к чему-то как к якобы доказательству. ))
Одна из последних твоих отсылок к примеру с порождением кучи независимых потоков vs тасков дотнета, и всё это в привычной менторской манере.
А по ссылке тихий от какого-то то ли MS MVP, то ли с должности на MS, что я валяюсь с вашего непуганного заповедника...
С умной рожей приводить более молодым коллегам ошибочные примеры, проявлять строгость и непокобелимость!
Это похлеще маразматического КПСС последней стадии.
Исправленную версию примера я там же в обсуждении приводил, но такое ощущение, что ты участвуешь в обсуждениях не для выяснения истины...
Ты даже не извинился перед тем коллегой, кому дал ссылку на бред.
V>>Я, конечно, не упоротый фанат DDD-подхода, но отлично им владею и использую, среди прочих других.
V>>Но фанаты именно DDD прямо сейчас подняли бы тебя на вилы за демонстрируемую нелепость...
S>Фанаты DDD идут мимо, хоть строем, хоть в разбивку. У них вилы не отросли меня куда-то поднимать.
Фанаты DDD пишут крупнейшие современные проекты.
Я занят не в крупнейших, но в которых, наверно, сильнейшие во всей отрасли технические требования.
А да, твоё "выросло" или "не выросло"...
Ты ведь всё-равно понятия не имеешь, о чём речь.
V>>Твой якобы "вопрос-уточнение" вообще перпендикулярен проблематике.
S>Нет никакой "проблематики", есть невладение языком и средствами разработки.
Ну вот за это и уволить, как и за вопрос выше, где я тоже рекомендовал.
Твой очередной косяк тут:
Вопрос, заданный именно таким образом (в виде упрёка и заламывания рук одновременно) в публичной переписке своему коллеге, способен в любой конторе породить во внутренних чатах-переписке бесконечнейшие срачи.
Потому что вопрос неполон, и его можно привести как к корректному, так и к глупому.
По-форме в любом случае требует письменного публичного извинения и клятвенного обещания больше так не делать.
В любом случае, в такой форме и с таким содержанием вопрос заведомо провокационный, а посему заведомо бестолковый.
Автору подобных манер обычно пару раз делают замечание, если не доходит — тупо увольняют.
Это нормальная, обычная практика.
И если тебя не уволили до сих пор, это означает, что ты, на самом деле, знаешь как необходимо себя вести.
Получается, именно сюда ты ходишь отвести душу, бо общепринятое тебе тебе противоестественно, давит и утомляет. ))
А здесь можно безнаказанно гадить, можно не стараться думать, можо даже строить из себя домохозяйку со стажем.
S>А недостатки C++, в виде возможности иметь заголовки от несуществующих методов, выдаются за его преимущества.
Что позволяло компиллировать большие программы на маленьких машинах.
В 94-м году довольно большое приложение на Паскале и Turbo Vision достигло у нас c товарищами почти полумегабайта (IDE для разработки на ассемблере) и было неспособно компиллироваться в обычном DOS-режиме.
Портировали на Си (многое автоматом через глобальную замену, а многое и так было на Си — целевые парсеры/лексеры ассемблеров) — и всё прекрасно компиллировалось еще долго.
Хотя и дольше по времени. ))
V>>Разберешься — приходи.
S>В сад.
Приходи из сада. ))
Синклер, у вас опять обнаруживаются вопиющие провалы, не соответствующие объему надувания боковых поверхностей лица...
Слушай, а вообще есть в IT хотя бы одна область, в которой ты более-менее разбираешься?
Просто любопытно...
ОК, понятно, что не учился на программера, осваивал самостоятельно.
Но за 25+ лет...
Неужели за этот срок вообще ни одной областью IT ты так и не овладел?
(не, я помню твои круглые глаза когда ты узнал о кеше браузеров и кодах ответов веб-серваков, но это было не на уровне "овладел", это было наполнение эрудиции, там инфы примерно на три первых дня работы современного фронтендера)
V>>Угу, на паскале.
V>>С общим объемом зависимостей в конкретной программе в несколько десятков символов.
V>>Уже после этого стоило бы завязывать с тобой общение. ))
S>Да я и не настаиваю. Не обязательно писать бред именно мне.
Так остановись, не пиши.
S>Но вы же, наверное, понимаете, что если машинке хватает памяти вычитать X тысяч символов из .h файлов и держать их "в уме", то ей будет ничуть не сложнее вычитать эти же символы из модулей?
Насчёт "эти же символы" — опять было некогда думать? ))
Или хотя бы немного погуглить?
Исторически набор h-файлов обычно шёл уникальный и минимально-необходимый для конкретного С++ файла.
В случае модулей на практике всегда будет максимальный набор символов, а не минимально-необходимый.
Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем.
Еще пример — в нулевых, да и в десятых, в линухах не очень пользовалась успехом технология предкомпиляции общих заголовков, когда в некий stdafx.h/pch.hpp и т.д. как в мусорное ведро пихают максимум зависимостей, а на виндах это было чуть ли не стандартом.
А дело в том, что у виндов зависимостей обычно кот наплакал: одна на всех WinAPI, сверху тоненький в публичном АПИ MFC, ну и всё, собсно.
А в Линухах обычно шли кучерявые бесконечные зависимости, т.е. это всегда была сборная солянка отовсюду.
Там средний вшивости пакет может вытянуть за собой еще 20-50 пакетов.
А если не вытянул — это потому что их уже притянули ранее.
В общем, у самого много раз компиляция под линухами молча подвисала при нехватке памяти в те года, если злоупотреблял предкомпляцией.
S>А скорее даже проще, потому как можно держать готовые символы, а не AST в ожидании того, что же у нас там такое окажется в .cpp файле после всех рекурсивных инклюдов.
Разумеется, можно считывать модули и в lazy-режиме, т.е. изначально читать просто список символов, а определения конкретных шаблонов, инлайн-функций и макросов — лишь по мере их задействования в компиляции.
Но не об этом ведь шла речь, бо, разумеется, это всё не проблема для современных размеров памяти.
Я делал замечание на твою очередную наивность в духе "надо было так сделать сразу!"
Мол, "в нормальных технологиях так давно".
Это значит, что ты никогда не писал достаточно больших проектов на том же Турбо-Паскале, т.е. не в курсе проблематики.
V>>В итоге, на этапе бурного кодирования мне приходится разбивать целевой проект на десятки их, потом склеивая обратно, когда нужный функционал более-менее отлажен, т.е. перетекает в стадию использования и поддержки.
S>Вы просто не умеете пользоваться C#.
У меня другая версия — тебе кажется странной сама задача активного манипулирования описанием билда.
(но таким мнением хвастаться не принято в современном мире)
S>Ничего в этом стыдного нет — нужно просто освоиться, перестать страдать, и начать наслаждаться.
Да ради бога, кто на что учился, как грится.
А то, судя по одному из обсуждений, ты выбрал расслабуху на работе, а реал пошёл по остаточному принципу.
S>Нет никакой нужды ничего разбивать на проекты — ни на единицы, ни на десятки. И склеивать потом не надо. Я пробовал так делать — лишняя боль и страдания на ровном месте.
Эээ, простите, "склеивать"? ))
Т.е. ты в 2021-м не в курсе, что MSBuild уже скоро 20 лет как умеет включать описания проектов друг в друга?
И что удобнее всего описывать проекты небольшими сниппетами, где целевой проект получается как иерархичное их влючение, т.е. типа обычная программа на основе библиотек, но на уровне MSBuild.
В Ant аналогично, кстате, ты же из джавы пришёл, неужели не пользовался такой фичей? ))
Но да, в самом конце "быстрой" первоначальной итерации разработки все-равно придётся код описания проектов переписать начисто, увы.
И стараться не править его из GUI Студии, а то там каша получается, а не исходник.
S>Модули имеет смысл выделять тогда, когда уже видны их логические границы — ни раньше, ни позже.
За одно это утверждение тебя уже можно смело увольнять.
(ниже объяснюсь, это уже не первое подобное заявление и не последнее в ряду их)
S>Если у вас сразу продумана вся архитектура (у меня так бывает редко), то можете сразу напилить нужное количество проектов. Если логические границы становятся понятны только после того, как написано много кода — ну вот тогда и выделяйте.
Художник-абстракционист рассуждает о том, как инженеру лучше чертить. ))
"Логические границы"...
Это в таких категориях ПО разрабатываешь?
S>А вот это вот напиливание избыточного количества проектов — зачем оно?
Почему "избыточного"? ))
См. определения этого слова.
Цель каждого отдельного проекта — быть независимой единицей компиляции.
Поэтому, такой проект может и включает обычно одну некую функциональность.
Низкая связанность/высокое зацепление — это общий принцип, в основе DDD лежит в том числе одним из первых.
Заодно такой подход развязывает руки в экспериментировании, т.е. не надо создавать ветки в гите — это банально лишее, удобней все варинты/эксперименты держать перед глазами одновременно.
В общем, отдельные проекты позволяют такие шалости, не ругая за конфликты имен.
И потому что через систему include MSBuild-описаний, т.е. повторного их использования, можно задешево покрыть относительно большую комбинаторику сочетаний вариантов кода для целей проведения экспериментов.
S>Тем более, что С# всё равно не даст вам собрать проект, который ссылается на разобранные проекты.
Судя по изрекаемому тобой, у тебя малость поверхностное представление насчёт того, куда и как может ссылаться проект C#.
Я ведь могу сделать проект лишь частично разобранным за нулевую трудоёмкость.
Опиши себе один мета-проект, ссылающийся на другие проекты, через один коммент включай-отключай запчасти, комбинируй, пробуй варианты и т.д. и т.п.
Для сравнения, "выключить" в исходнике класс — это нужно бегать, выключать все зависимости от него.
Разбил по проектам (которые на деле всегда подпроекты) — получил изоляцию и управляемость.
В общем, я уже понял, что отношение к задаче описания проекта именно как к задаче, являющейся неотъемлимой частью разработки, лично тебя шокирует.
Слушать это забавно, однако, особенно при рассуждении об интерфейсах и о том, что в какие сборки включать.
Ты опять пытаешься рассуждать о предметной области не погружаясь в неё.
В общем, границы проектов в конце стадии "быстрого роста" дизайна зависят от границ предметных областей и слоёв иерархии доменной модели, и ни от чего более.
Т.е., единицы деплоя, конечно, формируются по-вкусу, в меру испорченности, т.к. не запрещается в одну единицу деплоя пихать несколько элементов дизайна, групп их и т.д., но граница всё-равно проходит по границам элементов доменов (или доменов целиком), а значит и по границам слоёв дизайна (т.к. на каждом слое своя доменная модель).
S>Поэтому я так думаю, что вы сейчас рассказываете про воображаемый опыт в воображаемом программировании.
Это, типа, чего ты не видел лично, того не существует?
Как пакетных менеджеров в С++?
V>>Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить.
S>Что с чем вы предлагаете сравнить?
Наличие всей описанной возни с её отсутствием, ес-но.
V>>Они решают их натурально "пошагово", причём, довольно малюсенькими шажочками: сделают кусочек — проверят, еще небольшой кусочек — опять проверят.
S>Вы так говорите, как будто это плохо.
Это самая низкая производительность программиста из всех возможных.
S>Если я хочу двигаться пошагово — я двигаюсь пошагово.
Акцент был не на пошаговости как таковой, а на размерах итераций.
Когда итерация разработки-проверки колеблется на уровне единиц строк (как во всех твоих "примерах в развитии", что ты давал от своего имени) — это примерно нулевая производительность.
V>>Это один из самых медленных способов решения задач, бо требует постоянного переключения внимания и постоянного прекращения кодирования с целью проверки каждого чиха.
S>Если я хочу бурно поиграть с кодом — я так и делаю. И мне никак не мешает то, что полпроекта "красные". Как думаете, почему?
Потому что ты не планируешь довести текущую итерацию до конца?
Т.е. раздать роли и ответственности сущностям дизайна, прописать и обкатать основные сценарии на каждом слое системы?
Даже не любопытно хотя бы просто посмотреть, как это примерно будет выглядеть? ))
V>>На плюсах более устоялся чуть другой подход — сначала достаточно "вольное" описание домена/доменов на текущем слое или куче слоёв (смотря, насколько "вглубину" задача), затем решение задач в терминах домена.
S>Точно также всё работает в C#. Вот ровно также.
Но не прижилось на практике.
Достаточно посмотреть на дизай станартных либ и систему "рекомендаций" от MS (половину из которых уже выкинули нафик к сегодняшнему дню, слава богу).
S>Я пишу вызов foo.SomeMethod() c сигнатурой, и автопорождаю этот метод.
S>Потом, когда (и если) дойдёт до реализации, я заменю все эти NotImplemented на реальный код. Что мешает вам делать также?
Мне мешает то, что это несъедобно.
Ты как раз описываешь одну из причин, почему Джава и C#-программисты позволяют себе злоупотреблять интерфейсами.
По-сути, в Джава и C# интерфейсы выродились более в инструмент развязки зависимостей, чем в инструмент описания абстрактной модели происходящего.
Т.е. я высмеивал то де-факто положение вещей, где задача развязки зависимостей зачастую не диктуется причинами технического плана, но диктуется причинами организационного, сугубо для целей совместной разработки.
V>>А ты думаешь, как мне удаётся с полутыка находить косяки в ваших решениях — твоих и любых других известных гуру даже из MS?
S>Пока вам это удаётся только языком.
Причём, русским.
Причём, обычно после прибегания тобой к чему-то как к якобы доказательству. ))
Одна из последних твоих отсылок к примеру с порождением кучи независимых потоков vs тасков дотнета, и всё это в привычной менторской манере.
А по ссылке тихий от какого-то то ли MS MVP, то ли с должности на MS, что я валяюсь с вашего непуганного заповедника...
С умной рожей приводить более молодым коллегам ошибочные примеры, проявлять строгость и непокобелимость!
Это похлеще маразматического КПСС последней стадии.
Исправленную версию примера я там же в обсуждении приводил, но такое ощущение, что ты участвуешь в обсуждениях не для выяснения истины...
Ты даже не извинился перед тем коллегой, кому дал ссылку на бред.
V>>Я, конечно, не упоротый фанат DDD-подхода, но отлично им владею и использую, среди прочих других.
V>>Но фанаты именно DDD прямо сейчас подняли бы тебя на вилы за демонстрируемую нелепость...
S>Фанаты DDD идут мимо, хоть строем, хоть в разбивку. У них вилы не отросли меня куда-то поднимать.
Фанаты DDD пишут крупнейшие современные проекты.
Я занят не в крупнейших, но в которых, наверно, сильнейшие во всей отрасли технические требования.
А да, твоё "выросло" или "не выросло"...
Ты ведь всё-равно понятия не имеешь, о чём речь.
V>>Твой якобы "вопрос-уточнение" вообще перпендикулярен проблематике.
S>Нет никакой "проблематики", есть невладение языком и средствами разработки.
Ну вот за это и уволить, как и за вопрос выше, где я тоже рекомендовал.
Твой очередной косяк тут:
Вам так хочется, чтобы модуль А зависел от конкретного типа, определённого в модуле Б?
Вопрос, заданный именно таким образом (в виде упрёка и заламывания рук одновременно) в публичной переписке своему коллеге, способен в любой конторе породить во внутренних чатах-переписке бесконечнейшие срачи.
Потому что вопрос неполон, и его можно привести как к корректному, так и к глупому.
По-форме в любом случае требует письменного публичного извинения и клятвенного обещания больше так не делать.
В любом случае, в такой форме и с таким содержанием вопрос заведомо провокационный, а посему заведомо бестолковый.
Автору подобных манер обычно пару раз делают замечание, если не доходит — тупо увольняют.
Это нормальная, обычная практика.
И если тебя не уволили до сих пор, это означает, что ты, на самом деле, знаешь как необходимо себя вести.
Получается, именно сюда ты ходишь отвести душу, бо общепринятое тебе тебе противоестественно, давит и утомляет. ))
А здесь можно безнаказанно гадить, можно не стараться думать, можо даже строить из себя домохозяйку со стажем.
S>А недостатки C++, в виде возможности иметь заголовки от несуществующих методов, выдаются за его преимущества.
Что позволяло компиллировать большие программы на маленьких машинах.
В 94-м году довольно большое приложение на Паскале и Turbo Vision достигло у нас c товарищами почти полумегабайта (IDE для разработки на ассемблере) и было неспособно компиллироваться в обычном DOS-режиме.
Портировали на Си (многое автоматом через глобальную замену, а многое и так было на Си — целевые парсеры/лексеры ассемблеров) — и всё прекрасно компиллировалось еще долго.
Хотя и дольше по времени. ))
V>>Разберешься — приходи.
S>В сад.
Приходи из сада. ))
Синклер, у вас опять обнаруживаются вопиющие провалы, не соответствующие объему надувания боковых поверхностей лица...
Слушай, а вообще есть в IT хотя бы одна область, в которой ты более-менее разбираешься?
Просто любопытно...
ОК, понятно, что не учился на программера, осваивал самостоятельно.
Но за 25+ лет...
Неужели за этот срок вообще ни одной областью IT ты так и не овладел?
(не, я помню твои круглые глаза когда ты узнал о кеше браузеров и кодах ответов веб-серваков, но это было не на уровне "овладел", это было наполнение эрудиции, там инфы примерно на три первых дня работы современного фронтендера)