И от этого тоже

ну вот теперь умный вид перестал делать и сразу виден уровень твоего IQ и развития )  лучше бы пил и курил (q)

IQ! Я ничего и не делал, просто вы не в теме

да никто не в твоей теме, это явно твоя тема индивидуальная (или как там политкорректнее сказать), просто ты особенный )

О, Джеб, привет. Я тут свою KSP  делаю, только на симулинке

Привет. Хуя, покеж

Да пока только одно тело есть на орбите вокруг кербина и кривая визуализация на юнити

Ой, там не кербин, а Земля

Ща

Охуенно

так как мне надо сделать до 31 числа, думаю, там только задача стыковки с телом на произвольной орбите будет реализована

А ты сколько делаешь уже?

пару недель, но я в основном хуи пинаю и другими делами занимаюсь

За две недели неплохо я считаю

ну я хорошо если день потратил

Ребят подскажите что прописать VSCode в jshint чтобы он сигнализировал если в коде не прописано ;

> ну "признано" - пиши кем, не надо за всех говорить... я вот не признал, значит не признано )
Согласен, использовал лишние weasel word, anonymous authority (https://en.m.wikipedia.org/wiki/Weasel_word), которые как раз и портят многое из того, "о чем люди говорят, книги пишут". Не подумал, что вы не в курсе этой рекомендации с наследованием и слишком резко написал об этом))
Хотя источник на wiki привел, еще больше можно найти запросом "why inheritance worst practices".
Вот тут например краткие практичные ответы:
https://www.quora.com/Is-inheritance-bad-practice-in-OOP-Many-places-that-teach-design-patterns-say-to-opt-for-composition-over-inheritance-but-what-about-when-multiple-classes-share-logic-from-an-abstract-class-such-as-in-the-Template-Method-design-pattern

Мне был интересен не срач, а что Mikhail имел ввиду под пониманием ООП и что это пониманин дало практически. Потому что сам не могу однозначно определить это понимание, т.к. критери ООП для кода нечеткие, их обычно сводят к компромисам принципов SOLID, GRASP, KISS, YAGNI, DRY, Worse is better и т.п.

Для самих языков парадигма ООП более опеделенная - они либо помогают писать в стиле ООП, либо нет. Знакомые профи считают, что если используется язык ООП, это уже технически ООП, отдельный вопрос к качеству конкретного дизайна, которое и служит в итоге критерием понимания ООП. Как стойной "теории", ООП по-моему нет, скорее ОО-дизайн и uml, которые парадигмой ООП и принципами притянуты к теориям и довелены до ума лучшими практиками. Т.о. ООП практиччески бессмысленно учить, а понять  можно только на практике, за много итераций. И по началу уж точно ООП не облегчает жизнь програмиста.

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

Что в ООП можно непонимать для реальной работы/дизайна не так очевидно. Полиморфизм, наверное, самое сложное, в части нюансов статического/динамического связывния и техник избежания явного приведения типов, перекликается и с паттернами и с наследованием. Рефакторинг в ООП стиле - тоже тема непростая, например - не бояться создавать технические классы, которые могут быть только из одной функции или по-другому не похожи на классическое описание объекта. Ещё правильное понимание инкапсуляции - оно полегче, но и правильность применения возмодно проверить только в долгоживущем проекте.
Понять проблематку отдельных паттернов проектирования сложно, слишко глубокие практические корни для начинающих, требующие понимания принципов (SOLID etc.) и нансов реализации поддержки ООП конкретным языком, не всегда  адекватные практике примеры.

Ответы Mikhail дал:

"Множество задач, которые я решал функциональным программированием приобрели для меня иной вид, даже на контролы на форме я стал по другому смотреть". Примерно отвечает, что было непонятно до этого, особенно в плане IU. Но как сформулировать, что было непонятно до этого, не знаю.

"Создать объект, а потом от него создать наследника, использовав методы базового класса, а если очень захочется, то переопределить методы parent-класса, у наследника"
Тоже примерно понятно, что дало понимание наследования и полиморфизма для практики. И опять не очень ясно, что было непонятно до этого.
Я уже не очень понимаю, какие стожности в применении наследования в конкретных языках и, соответственно, как это непонятное проще обьяснить.
Языки предоставляют этот механизм, и часто обязывают им пользоваться как минимум для суперобъекта. Для применения в дизайне, по-моему важней понять, когда наследование не нужно (нарушает инкапсуляцию, LSP и т.п.). С Turbo Pascal тоже немного имел дело (без ООП, формошлёпил немного), там наверное особые усилия нужны именно перейти к парадигме ООП. В Java мне по-началу было больше непонятно наоборот, почему чисто процедурные куски помещаются в объекты, которые не похожи на обьекты по большинству пюопределений и примеров.

Насчет срача по ООП, мне нравятся статьи вроде этой)))

Почему ООП - это плохо
https://medium.com/@konradmusial/why-oop-is-bad-and-possibly-disastrous-e0844fa96c1f

Последний абзац:
ОБНОВЛЕНИЕ: неделю спустя я обнаружил мощь ООП, влюбился в него и теперь чувствую, что ООП может быть потрясающим.