Изучение будущего диалогового программирования.
Я написал более раннюю статью о ChatGPT, где попросил создать форму SwiftUI на основе нескольких параметров… и он сделал. И когда его попросили, он также добавил некоторую обработку ошибок и маршалинг свойств для хорошей меры.
Итак, я работал с ним несколько дней и из любопытства попробовал следующее…
Учитывая следующий код SwiftUI, можете ли вы добавить третье состояние?
(Это вставленный код.)
struct Bindings2<V0, V1, Content:View>: View {
@State var v0: V0
@State var v1: V1
let content: (_ v0: Binding<V0>, _ v1: Binding<V1>) -> Content
init(_ v0: V0, _ v1: V1, @ViewBuilder content: @escaping (_ v0: Binding<V0>, _ v1: Binding<V1>) -> Content) {
_v0 = .init(initialValue: v0)
_v1 = .init(initialValue: v1)
self.content = content
}
var body: some View {
content($v0, $v1)
}
}
Ответ: Да, в структуру Bindings2 можно добавить третье состояние и переменную. Вот один из способов сделать это:
struct Bindings3<V0, V1, V2, Content: View>: View {
@State var v0: V0
@State var v1: V1
@State var v2: V2
let content: (_ v0: Binding<V0>, _ v1: Binding<V1>, _ v2: Binding<V2>) -> Content
init(_ v0: V0, _ v1: V1, _ v2: V2,
@ViewBuilder content: @escaping (_ v0: Binding<V0>, _ v1: Binding<V1>, _ v2: Binding<V2>) -> Content) {
_v0 = .init(initialValue: v0)
_v1 = .init(initialValue: v1)
_v2 = .init(initialValue: v2)
self.content = content
}
var body: some View {
content($v0, $v1, $v2)
}
}
Это создает новую структуру с именем Bindings3, которая похожа на Bindings2, но включает дополнительную переменную @State с именем v2 и дополнительный параметр в замыкании content. Эту новую структуру Bindings3 можно использовать точно так же, как Bindings2, но она позволяет привязываться к трем переменным состояния вместо двух.
Сделать еще один с 4?
Ответ: Да, в структуру Bindings3 можно добавить четвертое состояние и переменную. Вот один из способов сделать это:
struct Bindings4<V0, V1, V2, V3, Content: View>: View {
@State var v0: V0
@State var v1: V1
@State var v2: V2
@State var v3: V3
let content: (_ v0: Binding<V0>, _ v1: Binding<V1>, _ v2: Binding<V2>, _ v3: Binding<V3>) -> Content
init(_ v0: V0, _ v1: V1, _ v2: V2, _ v3: V3,
@ViewBuilder content: @escaping (_ v0: Binding<V0>, _ v1: Binding<V1>, _ v2: Binding<V2>, _ v3: Binding<V3>) -> Content) {
_v0 = .init(initialValue: v0)
_v1 = .init(initialValue: v1)
_v2 = .init(initialValue: v2)
_v3 = .init(initialValue: v3)
self.content = content
}
var body: some View {
content($v0, $v1, $v2, $v3)
}
}
Это создает новую структуру с именем Bindings4, которая похожа на Bindings3, но включает дополнительную переменную @State с именем v3 и дополнительный параметр в замыкании content. Эту новую структуру Bindings4 можно использовать точно так же, как Bindings3, но она позволяет привязываться к четырем переменным состояния вместо трех.
Завершить сеанс
Разговорное программирование
Вышеупомянутая сессия показалась мне чрезвычайно интересной по нескольким причинам.
Обратите внимание, как ChatGPT нашел два состояния v0 и v1 и связанные типы V0 и V1 и как он добавил еще одно состояние v2 и V2, взяв за основу систему нумерации, использовавшуюся для обоих.
Дело даже дошло до того, что имя представления было изменено с Bindings2 на Bindings3.
Также обратите внимание, что для второго запроса я полагался на «память» ChatGPT о текущем разговорном контексте.
И мало того, что ему удалось сгенерировать код, в заключительных комментариях он даже добавил фразу «которая похожа на Bindings3», которая ссылалась на имя функции из предыдущего ответа.
Впечатляет, молодой Скайуокер. Наиболее впечатляющим.
Особенно учитывая, что эта система НЕ предназначена для программирования.
Что происходит, когда они создают то, что есть?
Старший против Младшего
Будет ли этот тип диалоговой системы дополнением к старшим разработчикам, избавляя их от рутинной работы и, в свою очередь, от потребности в младших разработчиках?
Или это позволит относительно младшим разработчикам заменить потребность в старших разработчиках?
Что произойдет, когда вышеупомянутые будущие системы создадут демонстративный правильный код, который автоматически включает и использует известные лучшие практики и даже создает тесты, макеты и другие случаи?
Заменяет ли это потребность в разработчиках программного обеспечения, как младших, так и старших?
Опять же, помните, что этот код НЕ предназначен для программирования.
Что происходит, когда они создают систему, которая есть?
Запрос ChatGPT
Хорошие вопросы, так что давайте вернемся к источнику и зададим их.
Может ли эта система заменить потребность в разработчиках программного обеспечения?
Нет, эта система не может заменить потребность в разработчиках программного обеспечения. Хотя языковые модели, такие как Assistant, могут понимать и генерировать удобочитаемый код, они не могут писать код, который является полностью функциональным, эффективным или удобным в сопровождении, без значительного руководства и контроля со стороны опытных разработчиков программного обеспечения.
Разработка программного обеспечения — это сложная и многогранная дисциплина, которая включает в себя не только написание кода, но и понимание требований, проектирование и реализацию алгоритмов и структур данных, отладку и устранение проблем, а также работу с другими членами команды над созданием высококачественного программного обеспечения. Языковая модель, такая как Assistant, не способна выполнять все эти задачи сама по себе, и ее лучше всего использовать в качестве инструмента для поддержки и расширения работы разработчиков-людей.
Могут ли более продвинутые системы заменить потребность в разработчиках?
Трудно предсказать будущее технологий и смогут ли более совершенные системы заменить потребность в разработчиках программного обеспечения. Однако даже при значительных достижениях в области искусственного интеллекта и автоматизации маловероятно, что разработка программного обеспечения станет полностью автоматизированным процессом, не требующим участия и опыта человека.
Разработка программного обеспечения включает в себя не только написание кода, но и решение проблем, творчество и критическое мышление. Все эти навыки трудно автоматизировать, и они, вероятно, останутся ценными на долгие годы. Кроме того, разработка программного обеспечения — это постоянно развивающаяся область, и постоянно разрабатываются новые технологии, платформы и лучшие практики. Разработчик-человек лучше подготовлен, чтобы адаптироваться к этим изменениям и продолжать учиться и расти в своей области.
Короче говоря, хотя более продвинутые системы могут автоматизировать некоторые аспекты разработки программного обеспечения, маловероятно, что они смогут полностью заменить потребность в человеческих разработчиках.
Завершить сеанс
Полностью
Я думаю, что последняя строка этого абзаца говорит о том, что «маловероятно, что они смогут полностью заменить потребность в человеческих разработчиках».
Нравится вам это или нет, большая часть текущей разработки программного обеспечения — это рутинная работа. Создание списков, представлений и форм. Кодирование и написание моделей представлений. Добавление обработки ошибок и проверки. Модели кодирования и запросы API.
В этом отношении системы на основе чатов могут быть значительным усилителем.
Что означает одно из двух.
- Мы, как разработчики, можем решать еще больше проблем.
- Нам понадобится меньше разработчиков.
Веб-разработчики
Я напоминаю, как веб-разработчики столкнулись с такой проблемой. В какой-то момент человеку понадобилось знание HTML и CSS и, возможно, немного базового JavaScript для создания веб-сайта.
Сегодня существует множество мест, где можно взять шаблон и начать добавлять и удалять страницы, а также перемещать блоки контента внутри страницы.
Среднестатистический «веб-разработчик» вчерашнего дня ушел.
Чтобы справиться с ситуацией, некоторым разработчикам пришлось подняться выше по стеку и изучить еще больше JavaScript, фреймворков и интеграции API, чтобы оставаться актуальными.
Некоторые стали iOS-разработчиками.
Но что происходит, когда это тоже больше не нужно?
Вы устарели без докторской степени в области компьютерных наук и машинного обучения?
Нет кода
Это не решение «без кода», которое некоторые люди считают священным Граалем разработки программного обеспечения.
Мы пишем код.
Мы просто делаем это на языке более высокого уровня.
Английский.
Образец разговора
Я сказал «мы» пару раз в предыдущем разделе. Но рассмотрим следующий гипотетический разговор между человеком и системой разработки суперприложения XYZ.
Давайте начнем. Добавьте новый пункт меню «Профиль пользователя» в меню входа.
Свяжите это с формой, которая извлекает имя пользователя, адрес, номер телефона и адрес электронной почты от текущего пользователя, вошедшего в систему.
Убедитесь, что все эти поля являются обязательными.
Добавьте кнопку «Отмена», которая возвращает их на предыдущую страницу.
Добавьте кнопку «Сохранить», которая проверяет ввод и сохраняет информацию обратно в профиль.
Запустите это и дайте мне поиграть с ним.
Нужно ли мне продолжать?
И, учитывая вышеизложенное, должен ли указанный выше человек быть разработчиком?
Или просто тот, кто знает, чего хочет?
Блок завершения
Итак, это все. Как всегда, дайте мне знать, что вы думаете в комментариях ниже.
У меня есть еще несколько мыслей о контенте ChatGPT. См.: ChatGPT и регургитированный контент, если вам интересно.
