Ну вообще это выигранная битва, но проигранная война, если тролль никак не пострадал. Он должен нести существенные издержки для того, чтобы это нельзя было использовать.
Это не означает, что они самые лучшие и не нужно думать о том, как сделать лучше. Например JS популярен не потому, что такой хороший, а потому, что интернет и браузеры популярны. Миллион попыток его исправить, типа TypeScript, говорит об этом.
Не совсем понимаю, в чем ваш комментарий противоречит моему) Понятно, что в 45-м американцы были пионерами по многим причинам, в том числе и потому, что остальной мир был сильно занят. Другие развитые страны тоже построили свои ЭВМ через годы, серьезный проект своего времени. До какого то момента это были единичные вещи для институтов.
Это не из-за того, что копировали. Какая разница, что терять, развитую экспертизу или не развитую, если все равно теряешь? И с другой стороны - 35 лет уже прошло, за это время можно было построить целые индустрии с нуля, что некоторые страны, кстати, и сделали. Вопрос целеполагания.
CCCР был условно на уровне только с первыми ЭВМ и отдельными образцами. Отставать он стал сразу с появлением рынка IBM System/360. Он был сравнительно массовым, к нему появился рынок периферии и рынок программ (идея, что под каждый компьютер не нужно писать софт так но не простая) Ну и в оный были вложены колоссальные бабки.
А к началу 80-х отставание уже было очевидным - там были сотни тысяч индивидуальных пользователей, рынок софта, рынок совместимого оборудования, куча энтузиастов, куча программ под существующие модели. Клонировать компьютеры, чтобы хотя бы использовать готовый софт - было разумным решением.
Мне кажется вы путаете причинно-следственные. Копирование, или, скажем, подсматривание, было всегда. Но вот цельнотянутое копирование началось когда поняли, что зоопарк своих технологий даже близко не дотягивается до разнообразия чужих. К тому времени начали формироваться крупные игроки, переносимые программы создали рынок оных, в котором действовали независимые игроки. Соответственно просто по математике проигрывали - наши КБ не только не хотят, но не могут написать программ больше, чем десятки тысяч энтузиастов со всего света.
К моменту появления ПК отставание было очевидным, можно сколько угодно создавать свои компьютеры, но они не будут и на 5% так полезны, потому что софт.
Просто лучше-хуже это не только техническая характеристика и вообще не одна характеристика. Можно быть хуже по одной шкале и лучше по другой. Spectrum был сильно лучше конкурентов по шкале доступности, и не так плох по шкале "мощности и мультимедийных возможностей"
Странная статья. Сложность предсказания будущего в то и упирается, что тяжело предсказать взрывные тренды.
Скажем мир серьезно изменился с 2005 в контексте сервисов, смартфонов, голосовых ассистентов. Все армии мира прямо сейчас чешут голову в попытке понять, нужно ли увеличить производство беспилотников на 5000% или этого маловато? С нейросетями и роботами столько людей нацелилось на результат, что странно ожидать, что оно будет так же. Уже миллиарды вложены, это не может не сказаться никак. Да, возможно мы не получим AGI, но эффект от LLM может продвинуть автоматизацию во многих областях на 2 порядка. Генерируемый контент серьезно меняет сеть прямо сейчас - часть сайтов теряет траффик и пользователей, появляются новые лидеры.
В общем даже если недооценивать эти тренды, мир не будет примерно таким же.
Статья, как водится, пустовата. Возможно полезнее объяснять, не что делать, но почему.
Вот, например, другой разбор. Не то, как вам следует использовать SOLID, а как его использовала сама Unity и где можно поучиться.
Single responsibility principle - про единую ответственность. Это необходимо для организации, чтобы код был написан так, чтобы смежные изменения затрагивали ограниченное количество файлов, а не расползались по системе. Важно тут не то, что функция/класс делает что-то одно, а то, что она делает это в интересах одной цели. Unity великолепно следует этому принципу и поставила его во главу угла. Любая сцена состоит из объектов и компонентов на них. Компоненты - буквальное воплощение принципа. Каждый имеет свою задачу и независим от других. Если ошибка будет в модуле, ответственном за текст - вам не нужно менять компоненты, ответственные за физику. В некоторых случаях компоненты могут быть связаны, но даже тут они сгруппированы или имеют прямые ссылки друг на друга. К примеру кнопка явно использует графический компонент (например картинку) как свою визуализацию. Вам следует стараться писать ваши логические компоненты в той же парадигме, насколько это возможно. Иногда для сложных систем этого недостаточно - многие объекты должны знать друг о друге. На это призваны ответить различные паттерны организации и принципы, которые выходят за рамки этого принципа, тем не менее он остается полезен.
Open close principle - есть много трактовок этого принципа, но в общем случае это можно понимать как "пишите код, который нужно дополнять, а не переписывать". Тут есть множество нюансов, но юнити - хороший пример, который предполагает, что вы будете писать свои компоненты, которые могут легко взаимодействовать со встроенными. Если вам нужно окно - ваше окно может использовать кнопки, тексты и картинки из стандартных компонентов. Если нужно будет сделать другое - можно выкинуть код этого компонента и написать новый - виджеты не пострадают. Liscov Substitution Principle - тут довольно просто, все дети должны вести себя как минимум как родители. Основная причина - те, кто используют список базовых классов должны получать базовое же поведение, иначе старый и протестированный код можно поломать, написав новые классы (что очень тупо - ошибка то в новых классах, почему страдать должны старые?) Если базовый класс поддерживает операции "нарисуй себя" и "обработай нажатие", то все наследники должны это делать, пусть и по своему. Как минимум они не должны падать с ошибкой или делать кульбиты при отрисовке. Если они реализуют пустую функцию-заглушку - это тоже может быть признаком плохого кода (хотя тут могут быть нюансы) Unity использует это регулярно - у него есть большая иерархия компонентов и пользователь может наследоваться от многих из них и получать стандартное поведение компонентов. Важно отметить, что зачастую не используется прямое наследование (Например Unity находит и вызывает метод Update как то хитро и скрыто). Тем не менее Unity написала тысячи, а пользователи - сотни тысяч и миллионов компонентов, которые ведут себя как компоненты. Что позволяет вам их легко дополнять и даже переиспользовать чужие.
Interface Segregation Principle - тут все просто, интерфейсы должны быть маленькими и специализированными. Основная причина - меньше неиспользуемого кода, более понятные компоненты. Unity использует это даже без интерфейсов со своими основными методами - Update(), OnEnable(), OnDisable(), OnCollisionEnter(collider)
Другой пример - интерфейсы для UI - IPointerClickHandler - IPointerDownHandler - IPointerEnterHandler - IPointerExitHandler - IPointerUpHandler Как видно они связаны и, например, для реализации drag and drop нужно унаследовать несколько. Тем не менее для простых компонентов можно унаследовать лишь один и избежать пустого кода.
Dependency Inversion Principle - это пожалуй самый важный принцип для организации высокоуровневых связей. Если писать код напрямую, то можно получить очень связанную лапшу - ведь кнопка вызывает игру, игра загружает сцену, сцена загружает солдатика а тот загружает пули. Если каждый компонент из списка будет знать друг о друге, то во первых будет месиво, во вторых - код будет хрупким. Удали что-то из списка (например солдатика) и у тебя поломаются сразу сцена и пули. Чтобы этого избежать, прямые зависимости нужно ограничивать только необходимыми местами, а связи осуществлять через абстракции. Примеры из Unity - OnCollisionEnter - вам не нужно знать про коллайдер физики и его тип. А коллайдеру физики не нужно знать про ваш компонент (и все возможные пользовательские компоненты). Вы оба знаете только про абстракцию - интерфейс (в данном случае это метод и Unity использует хак, но принцип тот же). Таким образом любая реализация физики может вызвать столкновение (просто вызвать OnCollisionEnter на всех компонентах, какими бы они ни были). Вы даже можете сделать свой тип коллайдера. А любой логический компонент может быть потребителем события столкновения. Ему не нужно знать про существующие типы коллайдеров и с каким коллайдером мы работаем сейчас. Получается компоненты можно расширять в 2 -х направлениях совершенно не беспокоясь о том, как они будут дружить, и все они не будут знать друг о друге ничего, потому что не нужно.
Другой пример абстракций - это свойства базового компонента. Unity знает, что компонент может быть включен и выключен (enable) И если он включен - нужно вызывать Update(). Движок не интересует, что это за компонент и как он работает. Именно за счет этого Unity так мощна а пользователи могут легко делать и переиспользовать компоненты.
Но мне кажется даже можно взять шире и посмотреть на технологии построения систем из людей. Это ведь тоже своего рода технология, организационная, подобная тому, как зная принцип работы ДВС можно построить разные конфигурации даэвигателей
Некорректно называть это "без интерфейса", потому что в широком смысле интерфейс - это любой тип взаимодействия.
Даже если устройство можно только включить в розетку - это всё ещё интерфейс.
Тут скорее "дизайн без графического интерфейса" ну или "дизайн взаимодействия".
Для этого обычно используют термин UX чтобы избежать путаницы между UI и GUI
В остальном статья хорошая, это действительно важно, думать о том, как твоим сервисом или устройством пользоваться. Некоторые думают, что если, к примеру, делаешь консольное приложение или систему, взаимодействующую с пользователем через почту, то думать про это не нужно
Тем не менее после смерти одного человека и краткой аппаратной борьбы структура довольно серьезно изменилась. Что как бы говорит нам, что методы управления не были институционализированы и дело таки в одном человеке. Ну, технчиески конечно не в одном, но тем не менее.
Да, да, в нашем замечательном 19 веке все уже открыли, ничего нового больше не изобрести. Нужно идти учиться на священника.
То есть никаких других факторов, например длительности и динамики явлений в другом источнике сравнить нельзя? Инструменты строят, чтобы проверить применимость физических теорий. Если результат совпадает, почему его нужно игнорировать? Если есть другой способ проверить теорию - можете предложить, но этот пока неплохо себя показывал.
С бетоном совсем другой разговор, речь про продуктивную судебную систему.
Впрочем о чем это я
Ну вообще это выигранная битва, но проигранная война, если тролль никак не пострадал.
Он должен нести существенные издержки для того, чтобы это нельзя было использовать.
Это не означает, что они самые лучшие и не нужно думать о том, как сделать лучше.
Например JS популярен не потому, что такой хороший, а потому, что интернет и браузеры популярны. Миллион попыток его исправить, типа TypeScript, говорит об этом.
Не совсем понимаю, в чем ваш комментарий противоречит моему)
Понятно, что в 45-м американцы были пионерами по многим причинам, в том числе и потому, что остальной мир был сильно занят.
Другие развитые страны тоже построили свои ЭВМ через годы, серьезный проект своего времени.
До какого то момента это были единичные вещи для институтов.
Но да, уже IBM 360 был действительно массовым.
Это не из-за того, что копировали.
Какая разница, что терять, развитую экспертизу или не развитую, если все равно теряешь?
И с другой стороны - 35 лет уже прошло, за это время можно было построить целые индустрии с нуля, что некоторые страны, кстати, и сделали.
Вопрос целеполагания.
CCCР был условно на уровне только с первыми ЭВМ и отдельными образцами.
Отставать он стал сразу с появлением рынка IBM System/360.
Он был сравнительно массовым, к нему появился рынок периферии и рынок программ (идея, что под каждый компьютер не нужно писать софт так но не простая)
Ну и в оный были вложены колоссальные бабки.
А к началу 80-х отставание уже было очевидным - там были сотни тысяч индивидуальных пользователей, рынок софта, рынок совместимого оборудования, куча энтузиастов, куча программ под существующие модели.
Клонировать компьютеры, чтобы хотя бы использовать готовый софт - было разумным решением.
Мне кажется вы путаете причинно-следственные.
Копирование, или, скажем, подсматривание, было всегда.
Но вот цельнотянутое копирование началось когда поняли, что зоопарк своих технологий даже близко не дотягивается до разнообразия чужих.
К тому времени начали формироваться крупные игроки, переносимые программы создали рынок оных, в котором действовали независимые игроки.
Соответственно просто по математике проигрывали - наши КБ не только не хотят, но не могут написать программ больше, чем десятки тысяч энтузиастов со всего света.
К моменту появления ПК отставание было очевидным, можно сколько угодно создавать свои компьютеры, но они не будут и на 5% так полезны, потому что софт.
Просто лучше-хуже это не только техническая характеристика и вообще не одна характеристика.
Можно быть хуже по одной шкале и лучше по другой.
Spectrum был сильно лучше конкурентов по шкале доступности, и не так плох по шкале "мощности и мультимедийных возможностей"
Странная статья.
Сложность предсказания будущего в то и упирается, что тяжело предсказать взрывные тренды.
Скажем мир серьезно изменился с 2005 в контексте сервисов, смартфонов, голосовых ассистентов.
Все армии мира прямо сейчас чешут голову в попытке понять, нужно ли увеличить производство беспилотников на 5000% или этого маловато?
С нейросетями и роботами столько людей нацелилось на результат, что странно ожидать, что оно будет так же. Уже миллиарды вложены, это не может не сказаться никак.
Да, возможно мы не получим AGI, но эффект от LLM может продвинуть автоматизацию во многих областях на 2 порядка.
Генерируемый контент серьезно меняет сеть прямо сейчас - часть сайтов теряет траффик и пользователей, появляются новые лидеры.
В общем даже если недооценивать эти тренды, мир не будет примерно таким же.
Инициативный идиот хуже катастрофы.
Больше скриптовых языков богу скриптовых языков.
Интересно, почему не подошли существующие?
Да, в классическом смысле тов Сталин - не институт.
С другой стороны - что-то же осталось и продолжило работать, значит что-то было.
Увлекся, почти вышла отдельная статья.
Опубликовать ее что-ли.
Статья, как водится, пустовата.
Возможно полезнее объяснять, не что делать, но почему.
Вот, например, другой разбор.
Не то, как вам следует использовать SOLID, а как его использовала сама Unity и где можно поучиться.
Single responsibility principle - про единую ответственность.
Это необходимо для организации, чтобы код был написан так, чтобы смежные изменения затрагивали ограниченное количество файлов, а не расползались по системе. Важно тут не то, что функция/класс делает что-то одно, а то, что она делает это в интересах одной цели.
Unity великолепно следует этому принципу и поставила его во главу угла. Любая сцена состоит из объектов и компонентов на них. Компоненты - буквальное воплощение принципа. Каждый имеет свою задачу и независим от других. Если ошибка будет в модуле, ответственном за текст - вам не нужно менять компоненты, ответственные за физику.
В некоторых случаях компоненты могут быть связаны, но даже тут они сгруппированы или имеют прямые ссылки друг на друга. К примеру кнопка явно использует графический компонент (например картинку) как свою визуализацию.
Вам следует стараться писать ваши логические компоненты в той же парадигме, насколько это возможно.
Иногда для сложных систем этого недостаточно - многие объекты должны знать друг о друге. На это призваны ответить различные паттерны организации и принципы, которые выходят за рамки этого принципа, тем не менее он остается полезен.
Open close principle - есть много трактовок этого принципа, но в общем случае это можно понимать как "пишите код, который нужно дополнять, а не переписывать".
Тут есть множество нюансов, но юнити - хороший пример, который предполагает, что вы будете писать свои компоненты, которые могут легко взаимодействовать со встроенными. Если вам нужно окно - ваше окно может использовать кнопки, тексты и картинки из стандартных компонентов.
Если нужно будет сделать другое - можно выкинуть код этого компонента и написать новый - виджеты не пострадают.
Liscov Substitution Principle - тут довольно просто, все дети должны вести себя как минимум как родители.
Основная причина - те, кто используют список базовых классов должны получать базовое же поведение, иначе старый и протестированный код можно поломать, написав новые классы (что очень тупо - ошибка то в новых классах, почему страдать должны старые?)
Если базовый класс поддерживает операции "нарисуй себя" и "обработай нажатие", то все наследники должны это делать, пусть и по своему. Как минимум они не должны падать с ошибкой или делать кульбиты при отрисовке. Если они реализуют пустую функцию-заглушку - это тоже может быть признаком плохого кода (хотя тут могут быть нюансы)
Unity использует это регулярно - у него есть большая иерархия компонентов и пользователь может наследоваться от многих из них и получать стандартное поведение компонентов.
Важно отметить, что зачастую не используется прямое наследование (Например Unity находит и вызывает метод Update как то хитро и скрыто).
Тем не менее Unity написала тысячи, а пользователи - сотни тысяч и миллионов компонентов, которые ведут себя как компоненты. Что позволяет вам их легко дополнять и даже переиспользовать чужие.
Interface Segregation Principle - тут все просто, интерфейсы должны быть маленькими и специализированными.
Основная причина - меньше неиспользуемого кода, более понятные компоненты.
Unity использует это даже без интерфейсов со своими основными методами - Update(), OnEnable(), OnDisable(), OnCollisionEnter(collider)
Другой пример - интерфейсы для UI
- IPointerClickHandler
- IPointerDownHandler
- IPointerEnterHandler
- IPointerExitHandler
- IPointerUpHandler
Как видно они связаны и, например, для реализации drag and drop нужно унаследовать несколько. Тем не менее для простых компонентов можно унаследовать лишь один и избежать пустого кода.
Dependency Inversion Principle - это пожалуй самый важный принцип для организации высокоуровневых связей.
Если писать код напрямую, то можно получить очень связанную лапшу - ведь кнопка вызывает игру, игра загружает сцену, сцена загружает солдатика а тот загружает пули.
Если каждый компонент из списка будет знать друг о друге, то во первых будет месиво, во вторых - код будет хрупким. Удали что-то из списка (например солдатика) и у тебя поломаются сразу сцена и пули.
Чтобы этого избежать, прямые зависимости нужно ограничивать только необходимыми местами, а связи осуществлять через абстракции.
Примеры из Unity
- OnCollisionEnter - вам не нужно знать про коллайдер физики и его тип. А коллайдеру физики не нужно знать про ваш компонент (и все возможные пользовательские компоненты). Вы оба знаете только про абстракцию - интерфейс (в данном случае это метод и Unity использует хак, но принцип тот же). Таким образом любая реализация физики может вызвать столкновение (просто вызвать OnCollisionEnter на всех компонентах, какими бы они ни были). Вы даже можете сделать свой тип коллайдера.
А любой логический компонент может быть потребителем события столкновения. Ему не нужно знать про существующие типы коллайдеров и с каким коллайдером мы работаем сейчас.
Получается компоненты можно расширять в 2 -х направлениях совершенно не беспокоясь о том, как они будут дружить, и все они не будут знать друг о друге ничего, потому что не нужно.
Другой пример абстракций - это свойства базового компонента. Unity знает, что компонент может быть включен и выключен (enable)
И если он включен - нужно вызывать Update().
Движок не интересует, что это за компонент и как он работает.
Именно за счет этого Unity так мощна а пользователи могут легко делать и переиспользовать компоненты.
Вообще есть хорошее слово "институты".
Но мне кажется даже можно взять шире и посмотреть на технологии построения систем из людей. Это ведь тоже своего рода технология, организационная, подобная тому, как зная принцип работы ДВС можно построить разные конфигурации даэвигателей
Зато делает врр врр
Некорректно называть это "без интерфейса", потому что в широком смысле интерфейс - это любой тип взаимодействия.
Даже если устройство можно только включить в розетку - это всё ещё интерфейс.
Тут скорее "дизайн без графического интерфейса" ну или "дизайн взаимодействия".
Для этого обычно используют термин UX чтобы избежать путаницы между UI и GUI
В остальном статья хорошая, это действительно важно, думать о том, как твоим сервисом или устройством пользоваться. Некоторые думают, что если, к примеру, делаешь консольное приложение или систему, взаимодействующую с пользователем через почту, то думать про это не нужно
Тем не менее после смерти одного человека и краткой аппаратной борьбы структура довольно серьезно изменилась.
Что как бы говорит нам, что методы управления не были институционализированы и дело таки в одном человеке. Ну, технчиески конечно не в одном, но тем не менее.
Да, да, в нашем замечательном 19 веке все уже открыли, ничего нового больше не изобрести. Нужно идти учиться на священника.
То есть никаких других факторов, например длительности и динамики явлений в другом источнике сравнить нельзя?
Инструменты строят, чтобы проверить применимость физических теорий. Если результат совпадает, почему его нужно игнорировать?
Если есть другой способ проверить теорию - можете предложить, но этот пока неплохо себя показывал.
Ничего не понятно, но если звучит так, как звучит, это весьма сильно (и может даже довольно опасно)