По идее, для облегчения прикладной разработки, такие сложные процессы как асинхронность и многопоточность должны обеспечиваться и моделироваться инструментальными средствами более высокого уровня чем на уровне этих же корутин в Kotlin'e. То есть, по большому счету, такие высокоуровневые средства (в разной форме, вплоть до мастеров и шаблонов и ещё чего нибудь) должны поставляться к (с) конкретной операционной системой для облегчения разработки в ней приложений, чтобы разработчик мог максимально сфокусироваться на его прикладной части, а не углубляться в сложные и мелкие деталях реализации многопоточности и асинхронности. Для желающих же строить все "своими кирпичами" - пожалуйста используйте свои средства, в данном случае имеющиеся в языке программирования Kotlin.
Начинать надо с того, что программирование для ЭВМ и связанная с ним дисциплина проектирование (разработка) структуры базы данных, в силу своей особенной специфики, не всем студентам, в силу личных особенностей человека, доступно. Например, я знал хороших математиков, но которые так и не научились хорошо программировать, а тем более проектировать базы данных. Короче, не всем это подходит, так как требует навыки логического и аналитического мышления и которые не всем людям подвластны. Основной моделью данных, в которой представляется структура базы данных, вот уже более 50-ти лет, остаётся реляционная модель и, соответственно, под нее разработаны и реляционные СУБД. Поэтому, изучение надо начинать с этой модели, какие отношения между данными ей присущи (один ко многим, многие ко многим, один ко одному), понятие нормализации структуры БД, их формы. Лучше всего это последовательно демонстрировать на простом примере содержащем в конечном виде не более 8-10 таблиц. Но повторяю, что такой курс для не специализированных по ИТ учебных заведений должен быть факультативным (добровольным). Другое дело, это учить умению пользоваться базами данных и работать с ними. Аналог для сравнения: учить как проектировать и изготавливать автомобиль и учить как им управлять и ездить. В этом и есть принципиальная разница.
Ваши оценки приемлимы для сложившегося ИТ-специалиста с опытом, а НЕ для по сути ещё ребенка, начинающего только осваивать сложные технологии разработки компиляторов и нуждающегося в оценке проделанной для его возраста работе и получении разумных советов, а не огульной критики. В учителя, "рефридгератор", явно не годитесь.
Очевидно, что подобные модели, генерирующие вполне добротный и корректный текст, в своей внутренней механике оперируют словами, наборами слов (фразами), их связями и корреляциями установленными и зафиксированными при обучении. Интеллект же человека строит понятийные рассуждения оперируя предметными объектами, их свойствами, связями и отношениями с другими объектами из своей памяти и на основании этого анализа делает выводы и принимает решение выражая его на языке или в форме последующего физического или интеллектуального действия. То есть применительно к обсуждаемому, сначала предметно-понятийный анализ, а уже затем формирование выходного результата в форме текста на своем родном или другом языке. Поэтому возникает резонный вопрос: понимают ли подобные генеративные модели, как человек, смысл обрабатываемой информации и сформированного на выходе текста.
///Veo это системный (НА ЕГО ВЗГЛЯД) язык программирования. Я хочу использовать его для написания своих (ЕГО) программ в будущем. А ещё я разрабатываю его потому что мне (ЕМУ) интересны комплияторы и потому что мне нечего делать.///
Вроде все понятно.
Таких молодых конструкторов (не только в деле разработки софта) нужно НЕ поучать, а всячески поощрять и поддерживать. Вы сам в малом детстве небось собирали кубики и наверняка НЕ слышали нравоучений что это бесполезное занятие которым занимаются "миллион на каждую букву алфавита".
А я и не отвергаю, а только уточняю Ваши тезисы, которые, как и оценки каким-то изменениям, исключительно субъективны. Вы смотрите "со своей колокольни", а другие со своих. И, главное, если какое-то изменение 99 из 100 считают по своему положительным, то это вовсе не означает что оно является действительно таковым. Помнится, где-то в середине 10-ых годах, проводился экспресс-опрос "что вращается вокруг другого: земля или солнце ? Так 35 % респондентов посчитали что солнце вокруг земли. Везде нужна конкретика, а не абстрактные рассуждения и, тем более, обобщения.
Колесо, уважаемый, на Вашем автомобиле, небось, давно натурально умерло от старости несколько раз ? Никак бедному 2,5тыс.лет и, по вашей логике, давно ему бедному на покой и вперёд на автодроны. А если по серьезному, то принцип "что надёжно работает, то пусть и работает" верен не только для этого самого колеса, но и для всего остального, включая и программное обеспечение. К надёжному, функционально удовлетворяющему ПО термин "устаревает" не подходит в принципе. Об его устаревании могут рассуждать только люди называющими себя кодерами (не путать с разработчиками серьезного ПО !), либо дилетанты. На счёт COBOL'а, в частности, замечу, что один мой дальний знакомый и по сей день успешно на нем работает в Канаде на минитюаризированном мэйнфрайме IBM 370, который перемалывает софт разработанный как в 80'х, так и новый на "устаревших" COBOL'е, PL/I и Fortran'е.
Этакая компакт-ретроспектива программирования получилась. Правда автор забыл упомянуть известный Algol, который появился чуть попозднее Fortran'а, но шел с ним бок в бок все 60-ые.
Что касается ///ИИ способен быстро написать реализацию///, то для профессионалов данное утверждение сомнительное, если не сказать ложное. Ещё больше времени потребуется, чтобы разобраться в этой "писанине", доработать ее на надёжность, принятые стандарты разработки и документировать для дальнейшей техподдержки. Разработка серьезного ПО является инженерной работой, 1в1 повторяющий процесс и жизненный цикл сложного технического изделия со всеми вытекающими отсюда выводами. Разработка (не писание !) программного кода один из важных этапов этого процесса, но не главный. Было бы значительно лучше, если бы генеративный ИИ умел анализировать уже разработанный кем-то программный код на предмет его корректности и надёжности. В конечном же итоге, качество и надёжность программного обеспечения всегда будут зависеть от профессионализма разработчиков, а не от какого нибудь ИИ.
Необходимость широкого применения предложенной технологии распознавания текста на перегнутых (смятых, нечетких) листах вряд ли. Скорее для спец применения, например, в цифровизации старых архивных документов или в криминалистике.
"Ей нужна была система, которая свяжет весь этот разнородный материал воедино и позволит с ним работать, а не просто складывать." - абстрактная формулировка требований.
Напрашивающийся вопросы:
Как и кем систематизирован материал, многоуровневая ли его классификация, как и где она физически зафиксирована ?
Учитывая, как сказано, сотни разнообразных статей и прочих данных, кто и каким способом связывал их с классификатором и наполнял базу ?
С помощью какого ПО и как клиентке стало удобно работать с отсистематизированной информацией ?
Сколько на такую сложную и объёмную работу затрачено времени (человеко/месяцев) ?
Если "могут лишь угадывать следующий ... и этого вполне достаточно чтобы ..." тогда возникает резонный вопрос "а понимают ли они смысл того чем оперируют и что делают ?". Пусть, даже это и не угадывание, а верное и вполне правильное формирование выходного контента основанного на сформированных при обучении связях между отдельными элементами (словами, фразами, токенами, как хотите) или ссылках откуда что взять. Но если такой информации в модели нет (не достаточно) или она не корректная, то может возникнуть парадоксальная ситуация: модель отвечает правильно на сложные запросы, но не может ответить на простенький вопрос из этой же темы или выдает туфту. Таких примеров хоть сколько. Как говорится, не дообучили. А сама "догадаться" уже не в состоянии, так как для этого потребуется немного напрячься чтобы провести самостоятельный понятийный анализ исходных данных, выполнить рассуждения и сделать НОВЫЕ для себя логические выводы на которые способен настоящий интеллект. Вот тут и есть НЕ схожесть !
Это к тому, а можно ли на все 100 доверять таким моделям, особенно когда цена ошибки велика ? Правда многие цыганам тоже доверяют.
Верно в конце замечено об "отмывании знаний". Важным и содержащим ответ на вопрос "сама ли модель ИИ нашла новое решение или использовала уже где-то найденный и зафиксированный в процессе своего обучения готовый результат ?" является экспертный анализ подробной трассировки всей внутренней алгоритмики формирования моделью содержания своего ответа (решения). Принципиальным является выяснение того чем модель оперирует в алгоритме при формировании своего контента ? Упрощённо говоря, коррелируемыми словами (символами) (за этим словом (набором слов) должно механически следовать следующее такое слово (символ) или такой набор слов (символов)) представляющий утверждение. Или оперирует в целом математическими объектами задачи, выполняет понятийные рассуждения и строит НОВЫЕ логические выводы именно как математик ?
Если 2-ое верно (что как раз экспертно требуется выяснить и доказать), то тогда можно утверждать, что машинный интеллект (ИИ, AI) при решении этой задачи превзошел человеческий и по сути сделал новое открытие.
На примере создания больших (серьезных) программных комплексов очевидно, что существуют этапы и разделение труда разработчиков. Но и при создании небольших приложений вы неявно сам в той же последовательности выполняете все те же этапы разработки. Согласитесь, что термин "написание", как-то не вяжется с этим сложным процессом и внешне его попросту упрощает. В этом и цель моего комментария.
По идее, для облегчения прикладной разработки, такие сложные процессы как асинхронность и многопоточность должны обеспечиваться и моделироваться инструментальными средствами более высокого уровня чем на уровне этих же корутин в Kotlin'e. То есть, по большому счету, такие высокоуровневые средства (в разной форме, вплоть до мастеров и шаблонов и ещё чего нибудь) должны поставляться к (с) конкретной операционной системой для облегчения разработки в ней приложений, чтобы разработчик мог максимально сфокусироваться на его прикладной части, а не углубляться в сложные и мелкие деталях реализации многопоточности и асинхронности. Для желающих же строить все "своими кирпичами" - пожалуйста используйте свои средства, в данном случае имеющиеся в языке программирования Kotlin.
Начинать надо с того, что программирование для ЭВМ и связанная с ним дисциплина проектирование (разработка) структуры базы данных, в силу своей особенной специфики, не всем студентам, в силу личных особенностей человека, доступно. Например, я знал хороших математиков, но которые так и не научились хорошо программировать, а тем более проектировать базы данных. Короче, не всем это подходит, так как требует навыки логического и аналитического мышления и которые не всем людям подвластны. Основной моделью данных, в которой представляется структура базы данных, вот уже более 50-ти лет, остаётся реляционная модель и, соответственно, под нее разработаны и реляционные СУБД. Поэтому, изучение надо начинать с этой модели, какие отношения между данными ей присущи (один ко многим, многие ко многим, один ко одному), понятие нормализации структуры БД, их формы. Лучше всего это последовательно демонстрировать на простом примере содержащем в конечном виде не более 8-10 таблиц. Но повторяю, что такой курс для не специализированных по ИТ учебных заведений должен быть факультативным (добровольным). Другое дело, это учить умению пользоваться базами данных и работать с ними. Аналог для сравнения: учить как проектировать и изготавливать автомобиль и учить как им управлять и ездить. В этом и есть принципиальная разница.
Самопиар и хвастовство.
Ваши оценки приемлимы для сложившегося ИТ-специалиста с опытом, а НЕ для по сути ещё ребенка, начинающего только осваивать сложные технологии разработки компиляторов и нуждающегося в оценке проделанной для его возраста работе и получении разумных советов, а не огульной критики. В учителя, "рефридгератор", явно не годитесь.
Очевидно, что подобные модели, генерирующие вполне добротный и корректный текст, в своей внутренней механике оперируют словами, наборами слов (фразами), их связями и корреляциями установленными и зафиксированными при обучении. Интеллект же человека строит понятийные рассуждения оперируя предметными объектами, их свойствами, связями и отношениями с другими объектами из своей памяти и на основании этого анализа делает выводы и принимает решение выражая его на языке или в форме последующего физического или интеллектуального действия. То есть применительно к обсуждаемому, сначала предметно-понятийный анализ, а уже затем формирование выходного результата в форме текста на своем родном или другом языке. Поэтому возникает резонный вопрос: понимают ли подобные генеративные модели, как человек, смысл обрабатываемой информации и сформированного на выходе текста.
В самом начале автор сказал же:
///Veo это системный (НА ЕГО ВЗГЛЯД) язык программирования. Я хочу использовать его для написания своих (ЕГО) программ в будущем. А ещё я разрабатываю его потому что мне (ЕМУ) интересны комплияторы и потому что мне нечего делать.///
Вроде все понятно.
Таких молодых конструкторов (не только в деле разработки софта) нужно НЕ поучать, а всячески поощрять и поддерживать. Вы сам в малом детстве небось собирали кубики и наверняка НЕ слышали нравоучений что это бесполезное занятие которым занимаются "миллион на каждую букву алфавита".
А я и не отвергаю, а только уточняю Ваши тезисы, которые, как и оценки каким-то изменениям, исключительно субъективны. Вы смотрите "со своей колокольни", а другие со своих. И, главное, если какое-то изменение 99 из 100 считают по своему положительным, то это вовсе не означает что оно является действительно таковым. Помнится, где-то в середине 10-ых годах, проводился экспресс-опрос "что вращается вокруг другого: земля или солнце ? Так 35 % респондентов посчитали что солнце вокруг земли. Везде нужна конкретика, а не абстрактные рассуждения и, тем более, обобщения.
Шутка.
Такого же содержания мысли приходилось выслушивать от футурологов ИИ (AI) по теме "программирование для ЭВМ и ИИ" 40 и даже 50 лет назад.
Приблизительно такого же содержания мысли приходилось выслушивать от футурологов ИИ (AI) по теме "программирование и ИИ" 40 и даже 50 лет назад.
Колесо, уважаемый, на Вашем автомобиле, небось, давно натурально умерло от старости несколько раз ? Никак бедному 2,5тыс.лет и, по вашей логике, давно ему бедному на покой и вперёд на автодроны. А если по серьезному, то принцип "что надёжно работает, то пусть и работает" верен не только для этого самого колеса, но и для всего остального, включая и программное обеспечение. К надёжному, функционально удовлетворяющему ПО термин "устаревает" не подходит в принципе. Об его устаревании могут рассуждать только люди называющими себя кодерами (не путать с разработчиками серьезного ПО !), либо дилетанты. На счёт COBOL'а, в частности, замечу, что один мой дальний знакомый и по сей день успешно на нем работает в Канаде на минитюаризированном мэйнфрайме IBM 370, который перемалывает софт разработанный как в 80'х, так и новый на "устаревших" COBOL'е, PL/I и Fortran'е.
Сопротивление изменениям — естественная реакция здравомыслящих на попытку перестройки в худшую сторону.
Автору невдомек, что изменения (реформы, перестройки) бывают не только положительными.
Этакая компакт-ретроспектива программирования получилась. Правда автор забыл упомянуть известный Algol, который появился чуть попозднее Fortran'а, но шел с ним бок в бок все 60-ые.
Что касается ///ИИ способен быстро написать реализацию///, то для профессионалов данное утверждение сомнительное, если не сказать ложное. Ещё больше времени потребуется, чтобы разобраться в этой "писанине", доработать ее на надёжность, принятые стандарты разработки и документировать для дальнейшей техподдержки. Разработка серьезного ПО является инженерной работой, 1в1 повторяющий процесс и жизненный цикл сложного технического изделия со всеми вытекающими отсюда выводами. Разработка (не писание !) программного кода один из важных этапов этого процесса, но не главный. Было бы значительно лучше, если бы генеративный ИИ умел анализировать уже разработанный кем-то программный код на предмет его корректности и надёжности. В конечном же итоге, качество и надёжность программного обеспечения всегда будут зависеть от профессионализма разработчиков, а не от какого нибудь ИИ.
Мало верится.
Необходимость широкого применения предложенной технологии распознавания текста на перегнутых (смятых, нечетких) листах вряд ли. Скорее для спец применения, например, в цифровизации старых архивных документов или в криминалистике.
"Ей нужна была система, которая свяжет весь этот разнородный материал воедино и позволит с ним работать, а не просто складывать." - абстрактная формулировка требований.
Напрашивающийся вопросы:
Как и кем систематизирован материал, многоуровневая ли его классификация, как и где она физически зафиксирована ?
Учитывая, как сказано, сотни разнообразных статей и прочих данных, кто и каким способом связывал их с классификатором и наполнял базу ?
С помощью какого ПО и как клиентке стало удобно работать с отсистематизированной информацией ?
Сколько на такую сложную и объёмную работу затрачено времени (человеко/месяцев) ?
Если "могут лишь угадывать следующий ... и этого вполне достаточно чтобы ..." тогда возникает резонный вопрос "а понимают ли они смысл того чем оперируют и что делают ?". Пусть, даже это и не угадывание, а верное и вполне правильное формирование выходного контента основанного на сформированных при обучении связях между отдельными элементами (словами, фразами, токенами, как хотите) или ссылках откуда что взять. Но если такой информации в модели нет (не достаточно) или она не корректная, то может возникнуть парадоксальная ситуация: модель отвечает правильно на сложные запросы, но не может ответить на простенький вопрос из этой же темы или выдает туфту. Таких примеров хоть сколько. Как говорится, не дообучили. А сама "догадаться" уже не в состоянии, так как для этого потребуется немного напрячься чтобы провести самостоятельный понятийный анализ исходных данных, выполнить рассуждения и сделать НОВЫЕ для себя логические выводы на которые способен настоящий интеллект. Вот тут и есть НЕ схожесть !
Это к тому, а можно ли на все 100 доверять таким моделям, особенно когда цена ошибки велика ? Правда многие цыганам тоже доверяют.
Ваше сомнение я обосновал ниже в своем комментарии.
Верно в конце замечено об "отмывании знаний". Важным и содержащим ответ на вопрос "сама ли модель ИИ нашла новое решение или использовала уже где-то найденный и зафиксированный в процессе своего обучения готовый результат ?" является экспертный анализ подробной трассировки всей внутренней алгоритмики формирования моделью содержания своего ответа (решения). Принципиальным является выяснение того чем модель оперирует в алгоритме при формировании своего контента ? Упрощённо говоря, коррелируемыми словами (символами) (за этим словом (набором слов) должно механически следовать следующее такое слово (символ) или такой набор слов (символов)) представляющий утверждение. Или оперирует в целом математическими объектами задачи, выполняет понятийные рассуждения и строит НОВЫЕ логические выводы именно как математик ?
Если 2-ое верно (что как раз экспертно требуется выяснить и доказать), то тогда можно утверждать, что машинный интеллект (ИИ, AI) при решении этой задачи превзошел человеческий и по сути сделал новое открытие.
На примере создания больших (серьезных) программных комплексов очевидно, что существуют этапы и разделение труда разработчиков. Но и при создании небольших приложений вы неявно сам в той же последовательности выполняете все те же этапы разработки. Согласитесь, что термин "написание", как-то не вяжется с этим сложным процессом и внешне его попросту упрощает. В этом и цель моего комментария.