Так как SwiftUI реализует высокоуровневый слой над UIKit (мы здесь говорим про iOS), то конечно UIViewController продолжает существовать и функционировать в архитектуре. IMO прекрасно, что SwiftUI-разработчик с ним не работает и может быть знает о его существовании только по нечастым случаям следов сообщений в дебаг-логе.
Если посмотреть на исходные идеи MVC конца 1970-х, то контроллер представляет специальную сущность для пользователя управлять состоянием приложения. Это принципиальный архитектурный шаг вперед от терминальных (консольных) приложений с последовательным синхронным (то есть в данном случае вида вопрос - ответ) диалогом к многооконному асинхронному интерфейсу и архитектуре, управляемой множеством событий.
Любая асинхронная архитектура, управляемая событиями (то есть когда приложение продолжает работать без остановки для ожидания следующей порции ввода пользователя как ранее в консольных программах) так или иначе реализует идею контроллера, как бы его не называли.
Мне нравится как элегантно инженеры Apple с учетом требований совместимости решили возможно самую большую проблему для большинства начинающих программистов UIKit передавать изменения состояний из одного экрана в другие. И многие другие вещи.
В итоге, если проверенный временем UIKit традиционно ориентирует внимание разработчика на детали как управлять событиями и состояниями в приложении (отсюда и повышенное внимание разработчиков к паттернам проектирования), то SwiftUI - более высокоуровневый фреймворк это умеет сам (то есть работает контроллером, сам строит констрейнты, управляет событиями, экранными представлениями) и по сути ориентирует разработчика на то, что ему предстоит сделать. Прекрасно!
Я на это смотрю немного по иному. В игре мы всегда внутри себя принимаем ответственность за ее исход, не важно в роли божества или ассоциируемого персонажа. Даже если наша механика - это просто бросать кости. Но есть класс развлечений (это кстати снова бинарное разделение) где мы на самом деле находимся в роли наблюдателя, который ответственность за игру для себя не принимает, даже если у него есть некоторая возможность влиять на ее ход. Эта позиция зрителей на игровых стримах. Донатами и комментариями они влияют на ситуацию, но вся ответственность за игру лежит на стримере. Судя по количеству зрителей эта комфортная для себя позиция многим нравится!
Имеется в виду, что персонажи в файтинге обладают различными уникальными способностями и фишками? Это другое измерение для вовлеченности, это разнообразие выбора с выбором для себя подходящих предпочтений и легенды, если персонажи как в Smash имеют свой story и все это в пределах общего баланса силы.
Однако сам хороший файтинг как действо стремится к тому, как по джентельменски ранее называли бокс: "обмен мыслями при помощи жестов".
// Keep a reference to the current node, 'fox',
// and to the previous node in the list. Indicate the 'dog' node.
mark1 = current;
LinkedListNode<string> mark2 = current.Previous;
current = sentence.Find("dog");
IndicateNode(current, "Test 9: Indicate the 'dog' node:");
будет в Hi выглядеть примерно так:
mark1 = sentence.current
LET mark2 = sentence.prev
sentence.find "dog"
PRINT "Test 9: Indicate the 'dog' node:", sentence.current
Linked list в этой статье делает то же, что пример для С# (кстати, согласен — хороший), только еще проще, например фрагмент:
// Move the last node to be the first node.
mark1 = sentence.Last;
sentence.RemoveLast();
sentence.AddFirst(mark1);
Display(sentence, "Test 4: Move last node to be first node:");
в синтаксисе Hi выглядит так:
sentence.last
LET last = sentence.remove
sentence.insertFirst last
PRINT "Test 4: Move last node to be first node:"
Можно саму трансформацию выразить и одной строкой:
Ладно, продолжим кружок занимательной информатики.
По очередью обычно понимают однонаправленный список (т.е. частный случай), но советская очередь это всё-таки связный список. Об этом говорят типичные фразы:
«Кто последний?» list.last
«А кто перед вами?» list.prev # очередь в информатике не имеет ссылок на пред. элементы
«Я пойду, перед мной вот эта женщина» list.remove
«Я занимала за этим мужчиной!» list.insert aWomen
«Вас здесь не видели!» IF list.current == NIL THEN…
Поясню: для всего списка существуют действия «создать», «очистить», «найти голову/хвост», «изменить указатель на текущий элемент», «изменить текущий элемент», «добавить/удалить элемент».
А элементом списка является структура из данных и двух указателей. Для элемента имеют смысл действия «получить следующий/предыдущий элемент», «изменить данные»
У вас «изменить указатель на текущий элемент» для списка пересекается по смыслу «получить следующий/предыдущий элемент» для элемента. Это же будет уже другой элемент. Аналогично для действия «изменить элемент». Получилась каша в смыслах. Попробуйте рядом с моим API выписать ваши многосложные варианты с разделением для «списков» и «элементов».
Правильные названия — одна из ключевых проблем в программировании.
Разумнее заменить слово «правильные» на «целесообразные», тогда будет корректно. Не бывает априорно «правильных» решений. Следуя вашей логике «правильного» смыслового именования следует каждый раз задумываться как именовать счетчик в циклах вида for i =…
Некоторые военные историки не без оснований считают, что в военных действиях имеет преимущество та сторона, чей язык короче. С другой стороны еще дедушка мог бы рассказать, что логику linked list хорошо знали и использовали в Советском союзе, где был даже соответствующий мем: «Следующий [list.next] — кричит заведующий [owner]».
В первой работе указано назначение языка. Полагаю, с точки зрения документов вида BRD оно выглядит нелепо. Но внутренняя логика есть, она неочевидна, так как основана на своеобразном исходном концепте, примера реализации которого, наверное, на данный момент еще нет.
Поживем, увидим. В любом случае это интересно делать.
То, что вы описали выше я и сам не раз объяснял юным поклонникам Agile, как технологию организацию работ в крупной компании, для которой критична надежность работы корпоративного ПО в режиме эксплуатации.
Впрочем, не всегда водопадный подход работает хорошо даже для крупных проектов. Например, разработка игр. Дело в том, что нельзя создать заведомо качественный BRD для инновационной игры, потому что слишком много неизвестного. Здесь целесообразна итерационная разработка и эксперименты с прототипами. Иногда в процессе создания игры полностью меняется исходный концепт и почти всегда он частично трансформируется. Иногда приходится досрочно завершать разработку, потому что исходные гипотезы не подтверждаются. В книгах по гейм-дизайну, это детальнее описано, например The Art of Game Design: A Book of Lenses (книга вроде есть в русском переводе).
Но в любом случае спасибо, что вы так беспокоитесь и всегда приятно читать хорошо продуманные и изложенные тексты, впрочем,
скатиться в хреносозидательство по причине обострения чешижопицы тут как с добрым утром
Это как раз не беспокоит. Говоря метафорами, наша будущая цель не дать вместо совка лопату [для промышленного использования], а предоставить робота с лопатой. И более интересует, чтобы робот не воткнул лопату в электрический кабель.
… не надо в язык пихать сущностей сверх необходимого («бритва Оккама»). Посмотрите на тот же С++ — есть сам язык, содержащий минимальный набор типов и инструкций и есть библиотеки.
Диалектика для «бритвы Оккама» здесь в том, что сам C++ в том числе с помощью механизма множественного наследования является почти идеальным генератором сущностей и без особой необходимости продуманности в том числе.
Язык, который мы используем определяет характер нашего мышления. Эффективный язык должен доносить сообщение адресату с минимумом затрат на формирование самого сообщения.
Для языка программирования целесообразно включить полный сет встроенных возможностей для целевого использования, следовательно, например, язык, предназначенный для расчетов с математической статистикой должен иметь все необходимые встроенные методы работы с ней, чтобы не искать фреймворки на стороне (в довесок возможно еще иметь конкуренцию фреймворков, риски поддержки) или программисту не собирать из кода велосипед.
Как пример полезной эволюции языка. В ранних версиях Swift не было встроенной поддержки генерации рандомных чисел. Приходилось или подключать свою оболочку, или GameplayKit или использовать в коде довольно тяжеловесные конструкции c конверсией типов из UInt32 вида:
let n = Int(arc4random_uniform(11)) // не все в начале знают, что здесь диапазон генерации от 0 до 10
В версии 4.2 появилась встроенная поддержка:
let n = Int.random(in: 0…10)
Стало логично и гораздо удобнее. Язык вроде как усложнился, а программисту стало проще.
Причина экспериментов с linked list здесь на самом деле другая. Язык Hi конструируется с прицелом на гораздо более широкое применение в будущем, чем просто быстро программировать несложные задачи для начинающих в алгоритмическом стиле с дружелюбным environment.
Чтобы нам спроектировать будущий язык целесообразно [и попутно выполнить декларацию полной выполнимости исходного текстового кода в будущем], нужно пытаться на существующем языке реализовать сложные концепции, для которых он пока еще не предназначен. На примере linked list и еще некоторых примерах стало понятно, что c optionals лучше работать, чем их не иметь в языке даже в базовой версии. Соответственно теперь задача так их интегрировать в выразительные средства, чтобы было логично, просто, надежно. Работа с optionals требует продумывания обработки ситуаций с nil и т.д.
Концептуально создавать простой и понятный, функционально удобный язык очень непросто. Это означает, что в значительной мере сложность задач уходит от программиста к дизайнеру языка.
Спасибо за дельный комментарий!
Так как SwiftUI реализует высокоуровневый слой над UIKit (мы здесь говорим про iOS), то конечно UIViewController продолжает существовать и функционировать в архитектуре. IMO прекрасно, что SwiftUI-разработчик с ним не работает и может быть знает о его существовании только по нечастым случаям следов сообщений в дебаг-логе.
Если посмотреть на исходные идеи MVC конца 1970-х, то контроллер представляет специальную сущность для пользователя управлять состоянием приложения. Это принципиальный архитектурный шаг вперед от терминальных (консольных) приложений с последовательным синхронным (то есть в данном случае вида вопрос - ответ) диалогом к многооконному асинхронному интерфейсу и архитектуре, управляемой множеством событий.
Любая асинхронная архитектура, управляемая событиями (то есть когда приложение продолжает работать без остановки для ожидания следующей порции ввода пользователя как ранее в консольных программах) так или иначе реализует идею контроллера, как бы его не называли.
Мне нравится как элегантно инженеры Apple с учетом требований совместимости решили возможно самую большую проблему для большинства начинающих программистов UIKit передавать изменения состояний из одного экрана в другие. И многие другие вещи.
В итоге, если проверенный временем UIKit традиционно ориентирует внимание разработчика на детали как управлять событиями и состояниями в приложении (отсюда и повышенное внимание разработчиков к паттернам проектирования), то SwiftUI - более высокоуровневый фреймворк это умеет сам (то есть работает контроллером, сам строит констрейнты, управляет событиями, экранными представлениями) и по сути ориентирует разработчика на то, что ему предстоит сделать. Прекрасно!
Я на это смотрю немного по иному. В игре мы всегда внутри себя принимаем ответственность за ее исход, не важно в роли божества или ассоциируемого персонажа. Даже если наша механика - это просто бросать кости. Но есть класс развлечений (это кстати снова бинарное разделение) где мы на самом деле находимся в роли наблюдателя, который ответственность за игру для себя не принимает, даже если у него есть некоторая возможность влиять на ее ход. Эта позиция зрителей на игровых стримах. Донатами и комментариями они влияют на ситуацию, но вся ответственность за игру лежит на стримере. Судя по количеству зрителей эта комфортная для себя позиция многим нравится!
неплохо так закопались, спасибо )
...
Имеется в виду, что персонажи в файтинге обладают различными уникальными способностями и фишками? Это другое измерение для вовлеченности, это разнообразие выбора с выбором для себя подходящих предпочтений и легенды, если персонажи как в Smash имеют свой story и все это в пределах общего баланса силы.
Однако сам хороший файтинг как действо стремится к тому, как по джентельменски ранее называли бокс: "обмен мыслями при помощи жестов".
будет в Hi выглядеть примерно так:
в синтаксисе Hi выглядит так:
Можно саму трансформацию выразить и одной строкой:
Ладно, продолжим кружок занимательной информатики.
По очередью обычно понимают однонаправленный список (т.е. частный случай), но советская очередь это всё-таки связный список. Об этом говорят типичные фразы:
«Кто последний?» list.last
«А кто перед вами?» list.prev # очередь в информатике не имеет ссылок на пред. элементы
«Я пойду, перед мной вот эта женщина» list.remove
«Я занимала за этим мужчиной!» list.insert aWomen
«Вас здесь не видели!» IF list.current == NIL THEN…
У вас «изменить указатель на текущий элемент» для списка пересекается по смыслу «получить следующий/предыдущий элемент» для элемента. Это же будет уже другой элемент. Аналогично для действия «изменить элемент». Получилась каша в смыслах. Попробуйте рядом с моим API выписать ваши многосложные варианты с разделением для «списков» и «элементов».
Разумнее заменить слово «правильные» на «целесообразные», тогда будет корректно. Не бывает априорно «правильных» решений. Следуя вашей логике «правильного» смыслового именования следует каждый раз задумываться как именовать счетчик в циклах вида for i =…
Некоторые военные историки не без оснований считают, что в военных действиях имеет преимущество та сторона, чей язык короче. С другой стороны еще дедушка мог бы рассказать, что логику linked list хорошо знали и использовали в Советском союзе, где был даже соответствующий мем: «Следующий [list.next] — кричит заведующий [owner]».
Использование Goto сразу оживляет призрак Дейкстры (не путать с Дийкстра из Ведьмака) с топором в руках
А вот сформулировали же по другому :-)
В первой работе указано назначение языка. Полагаю, с точки зрения документов вида BRD оно выглядит нелепо. Но внутренняя логика есть, она неочевидна, так как основана на своеобразном исходном концепте, примера реализации которого, наверное, на данный момент еще нет.
Поживем, увидим. В любом случае это интересно делать.
Впрочем, не всегда водопадный подход работает хорошо даже для крупных проектов. Например, разработка игр. Дело в том, что нельзя создать заведомо качественный BRD для инновационной игры, потому что слишком много неизвестного. Здесь целесообразна итерационная разработка и эксперименты с прототипами. Иногда в процессе создания игры полностью меняется исходный концепт и почти всегда он частично трансформируется. Иногда приходится досрочно завершать разработку, потому что исходные гипотезы не подтверждаются. В книгах по гейм-дизайну, это детальнее описано, например The Art of Game Design: A Book of Lenses (книга вроде есть в русском переводе).
Но в любом случае спасибо, что вы так беспокоитесь и всегда приятно читать хорошо продуманные и изложенные тексты, впрочем,
несколько портит впечатление.
Диалектика для «бритвы Оккама» здесь в том, что сам C++ в том числе с помощью механизма множественного наследования является почти идеальным генератором сущностей и без особой
необходимостипродуманности в том числе.Ак как вы предлагаете именовать, допустим, list.next?
Для языка программирования целесообразно включить полный сет встроенных возможностей для целевого использования, следовательно, например, язык, предназначенный для расчетов с математической статистикой должен иметь все необходимые встроенные методы работы с ней, чтобы не искать фреймворки на стороне (в довесок возможно еще иметь конкуренцию фреймворков, риски поддержки) или программисту не собирать из кода велосипед.
Как пример полезной эволюции языка. В ранних версиях Swift не было встроенной поддержки генерации рандомных чисел. Приходилось или подключать свою оболочку, или GameplayKit или использовать в коде довольно тяжеловесные конструкции c конверсией типов из UInt32 вида:
В версии 4.2 появилась встроенная поддержка:
Стало логично и гораздо удобнее. Язык вроде как усложнился, а программисту стало проще.
Причина экспериментов с linked list здесь на самом деле другая. Язык Hi конструируется с прицелом на гораздо более широкое применение в будущем, чем просто быстро программировать несложные задачи для начинающих в алгоритмическом стиле с дружелюбным environment.
Чтобы нам спроектировать будущий язык целесообразно [и попутно выполнить декларацию полной выполнимости исходного текстового кода в будущем], нужно пытаться на существующем языке реализовать сложные концепции, для которых он пока еще не предназначен. На примере linked list и еще некоторых примерах стало понятно, что c optionals лучше работать, чем их не иметь в языке даже в базовой версии. Соответственно теперь задача так их интегрировать в выразительные средства, чтобы было логично, просто, надежно. Работа с optionals требует продумывания обработки ситуаций с nil и т.д.
Концептуально создавать простой и понятный, функционально удобный язык очень непросто. Это означает, что в значительной мере сложность задач уходит от программиста к дизайнеру языка.