AV
Ещё такое есть
Size: a a a
2021 February 16
AV
А по алгоритмической сложности их сравнивать как-то неправильно, имхо (снова-таки, потому что они работают с разными вещами)
SS
А по алгоритмической сложности их сравнивать как-то неправильно, имхо (снова-таки, потому что они работают с разными вещами)
Чому тяжко порівнуювати? Time complexity в ни же буде однаковий O(n). А питання саме про це наскільки я розумію
AV
Чому тяжко порівнуювати? Time complexity в ни же буде однаковий O(n). А питання саме про це наскільки я розумію
Не сложно, а неправильно. Разные ж вещи делают. Это как апельсин с чайником сравнивать
SS
Так ніхто ж не порівнює, спред він працює по протоколу ітерації, тільки там бігає по обєкту а там по масиву
RV
Не сложно, а неправильно. Разные ж вещи делают. Это как апельсин с чайником сравнивать
Апельсин с чайником прекрасно сравниваются. Можно сравнить по весу, занимаемому объему, эти данные релевантны например для отправки почтой)
AR
А разве объект не может поменяться по ссылке?
А ты в рантайме собираешься инжектить другие менеджеры/сервисы?
OJ
Считаете ли вы что неполноценные фронтенд фреймворки (типа библиотека React) занимаются по сути переносом сложности разработки в другую плоскость? В инженерии есть принцип необходимой вариативности: "только сложность может держать под контролем другую сложность." Во фронтенд разработке основная сложность это приведение разрозненных элементов (компонентов) к единому валидному состоянию объекта (в данном случае страницы) за ограниченный промежуток времени. Пользователь не должен видеть переход состояния ( промежуточные состояния) страницы. React например решает эту проблему путем переноса комбиноторной сложности проектирования перехода состояния системы, в сложность проектирования зависимостей состояния елементов от данных и от жизненных циклов состояния. По сути сложность не убирается, она только конвертируется в другую как по мне.
AK
А ты в рантайме собираешься инжектить другие менеджеры/сервисы?
нет
AK
просто почему TS не ругается
AR
Потому что тайпгард для переменной простой, которую замыкаешь
SG
Oleg Junior
Считаете ли вы что неполноценные фронтенд фреймворки (типа библиотека React) занимаются по сути переносом сложности разработки в другую плоскость? В инженерии есть принцип необходимой вариативности: "только сложность может держать под контролем другую сложность." Во фронтенд разработке основная сложность это приведение разрозненных элементов (компонентов) к единому валидному состоянию объекта (в данном случае страницы) за ограниченный промежуток времени. Пользователь не должен видеть переход состояния ( промежуточные состояния) страницы. React например решает эту проблему путем переноса комбиноторной сложности проектирования перехода состояния системы, в сложность проектирования зависимостей состояния елементов от данных и от жизненных циклов состояния. По сути сложность не убирается, она только конвертируется в другую как по мне.
какой вывод из этого следует сделать?
ЗФ
Oleg Junior
Считаете ли вы что неполноценные фронтенд фреймворки (типа библиотека React) занимаются по сути переносом сложности разработки в другую плоскость? В инженерии есть принцип необходимой вариативности: "только сложность может держать под контролем другую сложность." Во фронтенд разработке основная сложность это приведение разрозненных элементов (компонентов) к единому валидному состоянию объекта (в данном случае страницы) за ограниченный промежуток времени. Пользователь не должен видеть переход состояния ( промежуточные состояния) страницы. React например решает эту проблему путем переноса комбиноторной сложности проектирования перехода состояния системы, в сложность проектирования зависимостей состояния елементов от данных и от жизненных циклов состояния. По сути сложность не убирается, она только конвертируется в другую как по мне.
если в двух словах, не считаю
EO
какой вывод из этого следует сделать?
что пора ехать в буковель выращивать гусей, без ваших от этих реактов\перекатов и перенос сложностей)
SG
))) неплохой вариант
какова комбинаторная сложность выращивания 1 гуся?
какова комбинаторная сложность выращивания 1 гуся?
EO
Oleg Junior
Считаете ли вы что неполноценные фронтенд фреймворки (типа библиотека React) занимаются по сути переносом сложности разработки в другую плоскость? В инженерии есть принцип необходимой вариативности: "только сложность может держать под контролем другую сложность." Во фронтенд разработке основная сложность это приведение разрозненных элементов (компонентов) к единому валидному состоянию объекта (в данном случае страницы) за ограниченный промежуток времени. Пользователь не должен видеть переход состояния ( промежуточные состояния) страницы. React например решает эту проблему путем переноса комбиноторной сложности проектирования перехода состояния системы, в сложность проектирования зависимостей состояния елементов от данных и от жизненных циклов состояния. По сути сложность не убирается, она только конвертируется в другую как по мне.
а серьезно, то в этом же и соль, как бы
скрыть сложность от конечного потребителя, в данном случае - разработчика
а если эта абстракция протекает и не скрывает сложности от разработчика - значит плохая абстракция 🤷
скрыть сложность от конечного потребителя, в данном случае - разработчика
а если эта абстракция протекает и не скрывает сложности от разработчика - значит плохая абстракция 🤷
EO
))) неплохой вариант
какова комбинаторная сложность выращивания 1 гуся?
какова комбинаторная сложность выращивания 1 гуся?
42
ЗФ
я думаю каждый по своему понял (или не понял) вопрос про перенос комбинаторной сложности
OJ
а серьезно, то в этом же и соль, как бы
скрыть сложность от конечного потребителя, в данном случае - разработчика
а если эта абстракция протекает и не скрывает сложности от разработчика - значит плохая абстракция 🤷
скрыть сложность от конечного потребителя, в данном случае - разработчика
а если эта абстракция протекает и не скрывает сложности от разработчика - значит плохая абстракция 🤷
ну да. что абстракция в реакте выбрана правильно я не уверен.
SG
что значит "правильно"?