И если вы обратите внимание, то этот пост - это уже шаг на пути к цели - обратить внимание общественности на проблему чтобы решить ее для взаимной выгоды всех сторон.
интересная тема, игры с локациями и\или историями как раз можно представить в виде деревьев или графов
как в принципе и UI-приложения, если экран приложения представить в виде карты, и переключение между экранами как переключение между локациями, т.е. сам UI может выступать в роли структуры данных
я как раз сейчас делаю нечто подобное, посмотрим что из этого выйдет :)
Можешь в двух словах рассказать что там у Кейси Маратори про ООП интересного, для затравки так сказать? 😁
Я на С\С++ лет 20 назад писал в последний раз, говорят что сейчас он сильно развился, как впрочем и все остальное
К слову о деструкторах, мне нравится как сделали в Objective C с полуавтоматическим подсчетом ссылок, если говорить о +- низкоуровневых языках, это конечно не полностью автоматическая сборка мусора как в Java\C#\Kotlin\Swift\Dart, но все равно удобства добавляет
"сторонники ООП не могут решить как именно оформлять код" - да есть такое, на каждом проекте что-то свое и приходится договариваться.
По сути ООП позволяет разработчикам создать свой язык которым они описывают проект. Что несет с собой как плюсы общего языка для общения на проекте, так и минусы для людей еще этого языка не знающих.
P.S. Ну и говоря о языке можно вспомнить историю про Вавилонскую Башню и дать ссылку на семантику в которой как раз поднимаются и осмысляются эти штуки))
Я считаю что тут нет лучшего, лучшее то что решает мои задачи оптимальным на данный момент способом. В каждом подходе можно найти плюсы и минусы, и здесь нет какого-то идеального варианта. Тут больше играет роль привычки.
Хорошую архитектуру можно построить как на ФП так и на ООП, так и в процедурном стиле, и по структуре она будет напоминать дерево (хотя конечно чаще всего это граф, так как некоторые узлы мы зацикливаем на какие-то ветки).
Мне понятно о чем вы пишете, просто вы смотрите на мир с этой стороны, это нормально как по мне.
Я было дело холиварил по молодости, но потом понял что сколько людей столько и представлений одного и того же "слона".
Я недавно осознал что классы - это просто самописные структуры данных, как раз то что вы написали.
Еще я понял что функция - это по сути тоже структура данных. Класс можно рассматривать как функцию, а функцию как класс.
Можно написать классами программу в функциональном стиле, и так же можно написать функциями программу в стиле ООП. Разница парадигм на самом деле несущественна.
Да синтаксически отличается при этом суть одна и та же у функций и у классов - это блоки каких-то данных вперемешку с инструкциями преобразования этих данных.
Не понял цитаты.
А если по тексту - то совершенствование инструментов труда неизбежно, и перестройка процесса работы тоже как следствие этого.
Да, это можно считать проблемой, но это другая проблема.
Я же хочу решить проблему трудоустройства где все еще человек нанимает человека.
И человек разрабатывает алгоритмы и схемы для наема на работу или отказа в ней.
В том и дело что все собирают членские взносы, а воз и ныне там.
Очевидно что они не решают истинной проблемы, возможно они решают какие-то другие, но в целом ситуация не меняется уже много лет.
Значит надо делать что-то другое чтобы получить другой результат.
Мне ближе подход Ганди в данной ситуации :)
И если вы обратите внимание, то этот пост - это уже шаг на пути к цели - обратить внимание общественности на проблему чтобы решить ее для взаимной выгоды всех сторон.
Хочется ответить стихами Асадова:
В любых делах при максимуме сложностейПодход к проблеме все-таки один:
Желанье — это множество возможностей,
А нежеланье — множество причин.
Есть такое :)
по опыту я конечно слукавил
не 12, а 12+, 13-14 лет опыта где-то так
когда я начинал были книги по Android 1.2 кажется, стабильным был Android 1.5 и передовым Android 1.6, а фрагментов и композа не было даже в проекте)
с определенного момента начинаешь не завышать, а занижать возраст 😂
есть реальность и есть отношение, отношение реальности не меняет
Чем-то напоминает стейт-машину с конечными автоматами (Finite State Machine, FSM)
Ага, да это она и есть! :)
Так же как за разработку, оплатили кол-во затраченных часов.
Ценное осознание!
Приятно видеть когда здравый смысл разрушает оковы заблуждений :)
интересная тема, игры с локациями и\или историями как раз можно представить в виде деревьев или графов
как в принципе и UI-приложения, если экран приложения представить в виде карты, и переключение между экранами как переключение между локациями, т.е. сам UI может выступать в роли структуры данных
я как раз сейчас делаю нечто подобное, посмотрим что из этого выйдет :)
Забавная история 😁
Интересно, спасибо, ECS прям открытие для меня)
Хотя сейчас такая ситуация на рынке труда, что может быть оно и лучше будет оставаться на C/C++, сам смотри в общем)
А чего Kotlin не затащишь или Rust? Какие-то платформенные ограничения?
Как по мне так - это достаточно удобная альтернатива тому же C++
Спасибо, принято :)
Можешь в двух словах рассказать что там у Кейси Маратори про ООП интересного, для затравки так сказать? 😁
Я на С\С++ лет 20 назад писал в последний раз, говорят что сейчас он сильно развился, как впрочем и все остальное
К слову о деструкторах, мне нравится как сделали в Objective C с полуавтоматическим подсчетом ссылок, если говорить о +- низкоуровневых языках, это конечно не полностью автоматическая сборка мусора как в Java\C#\Kotlin\Swift\Dart, но все равно удобства добавляет
Игра в консоли в процедурном стиле - это сильно :)
На что спорили то? 😁
"сторонники ООП не могут решить как именно оформлять код" - да есть такое, на каждом проекте что-то свое и приходится договариваться.
По сути ООП позволяет разработчикам создать свой язык которым они описывают проект. Что несет с собой как плюсы общего языка для общения на проекте, так и минусы для людей еще этого языка не знающих.
P.S. Ну и говоря о языке можно вспомнить историю про Вавилонскую Башню и дать ссылку на семантику в которой как раз поднимаются и осмысляются эти штуки))
Принято, спасибо :)
Я считаю что тут нет лучшего, лучшее то что решает мои задачи оптимальным на данный момент способом. В каждом подходе можно найти плюсы и минусы, и здесь нет какого-то идеального варианта. Тут больше играет роль привычки.
Хорошую архитектуру можно построить как на ФП так и на ООП, так и в процедурном стиле, и по структуре она будет напоминать дерево (хотя конечно чаще всего это граф, так как некоторые узлы мы зацикливаем на какие-то ветки).
Принято, +1 :)
Мне понятно о чем вы пишете, просто вы смотрите на мир с этой стороны, это нормально как по мне.
Я было дело холиварил по молодости, но потом понял что сколько людей столько и представлений одного и того же "слона".
Я недавно осознал что классы - это просто самописные структуры данных, как раз то что вы написали.
Еще я понял что функция - это по сути тоже структура данных. Класс можно рассматривать как функцию, а функцию как класс.
Можно написать классами программу в функциональном стиле, и так же можно написать функциями программу в стиле ООП. Разница парадигм на самом деле несущественна.
Да синтаксически отличается при этом суть одна и та же у функций и у классов - это блоки каких-то данных вперемешку с инструкциями преобразования этих данных.