Re[40]: MS забило на дотнет. Питону - да, сишарпу - нет?
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.08.21 14:41
Оценка: +2 :)
Здравствуйте, vdimas, Вы писали:

V>Угу, на паскале.

V>С общим объемом зависимостей в конкретной программе в несколько десятков символов.
V>Уже после этого стоило бы завязывать с тобой общение. ))
Да я и не настаиваю. Не обязательно писать бред именно мне.
Но вы же, наверное, понимаете, что если машинке хватает памяти вычитать X тысяч символов из .h файлов и держать их "в уме", то ей будет ничуть не сложнее вычитать эти же символы из модулей?
А скорее даже проще, потому как можно держать готовые символы, а не AST в ожидании того, что же у нас там такое окажется в .cpp файле после всех рекурсивных инклюдов.

V>От особенностей ЯП растут растут уникальные для ЯП доступные практики.

V>Например, крупные проекты на C# меня раздражают именно озвученным — всё должно быть одновременно компилябельным, чтобы я мог хоть как-то работать с привычной для себя скоростью.
V>В итоге, на этапе бурного кодирования мне приходится разбивать целевой проект на десятки их, потом склеивая обратно, когда нужный функционал более-менее отлажен, т.е. перетекает в стадию использования и поддержки.
Вы просто не умеете пользоваться C#. Ничего в этом стыдного нет — нужно просто освоиться, перестать страдать, и начать наслаждаться.
Нет никакой нужды ничего разбивать на проекты — ни на единицы, ни на десятки. И склеивать потом не надо. Я пробовал так делать — лишняя боль и страдания на ровном месте. Модули имеет смысл выделять тогда, когда уже видны их логические границы — ни раньше, ни позже. Если у вас сразу продумана вся архитектура (у меня так бывает редко), то можете сразу напилить нужное количество проектов. Если логические границы становятся понятны только после того, как написано много кода — ну вот тогда и выделяйте. Это всё делается в несколько движений мышкой.
А вот это вот напиливание избыточного количества проектов — зачем оно? Тем более, что С# всё равно не даст вам собрать проект, который ссылается на разобранные проекты. В любом случае вам придётся либо делать метод-заглушку, либо интерфейс, либо абстрактный класс.

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

V>Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить.

Что с чем вы предлагаете сравнить?

V>Они решают их натурально "пошагово", причём, довольно малюсенькими шажочками: сделают кусочек — проверят, еще небольшой кусочек — опять проверят.

Вы так говорите, как будто это плохо.
Если я хочу двигаться пошагово — я двигаюсь пошагово.

V>Это один из самых медленных способов решения задач, бо требует постоянного переключения внимания и постоянного прекращения кодирования с целью проверки каждого чиха.

Если я хочу бурно поиграть с кодом — я так и делаю. И мне никак не мешает то, что полпроекта "красные". Как думаете, почему?

V>На плюсах более устоялся чуть другой подход — сначала достаточно "вольное" описание домена/доменов на текущем слое или куче слоёв (смотря, насколько "вглубину" задача), затем решение задач в терминах домена.

Точно также всё работает в C#. Вот ровно также. Я пишу вызов foo.SomeMethod() c сигнатурой, и автопорождаю этот метод.
Потом, когда (и если) дойдёт до реализации, я заменю все эти NotImplemented на реальный код. Что мешает вам делать также?

V>А ты думаешь, как мне удаётся с полутыка находить косяки в ваших решениях — твоих и любых других известных гуру даже из MS?

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


V>Я, конечно, не упоротый фанат DDD-подхода, но отлично им владею и использую, среди прочих других.

V>Но фанаты именно DDD прямо сейчас подняли бы тебя на вилы за демонстрируемую нелепость...
Фанаты DDD идут мимо, хоть строем, хоть в разбивку. У них вилы не отросли меня куда-то поднимать.

V>Твой якобы "вопрос-уточнение" вообще перпендикулярен проблематике.

Нет никакой "проблематики", есть невладение языком и средствами разработки. А недостатки C++, в виде возможности иметь заголовки от несуществующих методов, выдаются за его преимущества.

V>Разберешься — приходи.

В сад.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.