/// Если без воды и умных терминов — это интерфейс, позволяющий ИИ-модели обращаться за данными к внешнему ресурсу, а затем отдавать информацию обратно. ///
Пока все рассуждения автора носят общий характер. Чтобы дать оценку, необходимо на каком-то не сложном конкретном примере детально по шагам представить всю технологию обмена данными между ИИ-моделью и внешними источниками данных и информации.
///В значительной степени перед нами стоит основная, фундаментальная проблема — невозможность оставаться в лидерах в ИТ при отсутствии общего технологического развития страны, без высокого внутреннего спроса на ИТ технологии со стороны предприятий других секторов экономики.///
Это, собственно, и есть главный постулат. ИТ-технологии не могут существовать сами по себе в некотором вакууме широкого отсутствия на них спроса. По сути, для дальнейшего ИТ-прогресса, достижения конкурентоспособности и реального суверенитета в отрасли, необходимы системные разработки с новыми идеями на уровне операционных систем, инструментальных средств для создания прикладного ПО, систем управления базами данных и интеллектуальных систем поддержки принятия решений и ИИ. Фактически необходима и разработка своего hardwеre, унифицированного (совместимого) с зарубежными аналогами. Причем все это надо делать в сжатые для XXI-ого века сроки. Остаётся открытым ответ на главный вопрос: достаточности научно-технического и технологического потенциалов, наличие высоко-квалифицированных кадров и организаторов - управленцев для такой прорывной ИТ- миссии.
///Почему я считаю, что именно кардинальная смена стека\парадигмы или ЯП делают значительно мудрее? Каждый язык имеет свою философию и формирует у человека специфичный взгляд на решение технических задач.///
Чисто субъективное мнение, если оно личное автора, а может подаваться им просто "для затравки" обсуждения такого посыла.
Во первых, и главное из чего нужно исходить, так это понимание того, что процесс разработки серьезного программного обеспечения 1в1 повторяет процесс разработки технического изделия: проектирование, изготовление, контроль, тестирование и поддержка. Программист, как один из участников этой цепочки, выполняет функцию технолога (разработка техпроцесса изготовления конкретной детали, то есть алгоритма) и рабочего изготовляющего деталь на станке (кодирование процедуры, модуля на конкретном ЯП). Поэтому, если замыкаться только на функции изготовления детали, то есть только на функции разработки программного кода, то это делает такого программиста-кодировщика более универсальным в смысле знания нескольких ЯП и НЕ более того. Термин "мудрее" тут не уместен. Если со временем и с многолетней практикой, чаще в какой-то одной прикладной предметной области, такой программист-кодировщик освоит и научится выполнять ДРУГИЕ функции разработки - постановщика задачи, архитектора, управленца, разработчика БД, тестировщика и писателя документации - то тогда он действительно расширит свои профессиональные навыки как специалист-разработчик ПО вне зависимости от конкретного ЯП.
Вывод: язык программирования или конкретная СУБД конечно же играют большую роль в разработке ПО, но ОБЩИЕ принципы постановки задачи, проектирование архитектуры и БД для конкретной реализации (веб- приложение или что-то другое), управление разработкой и последующая поддержка программного продукта независимы от языка программирования.
Проблема Windows в ее гипер-сложности. Microsoft с упорством достойного лучшего применения старается "в одном флаконе" совместить потребности совершенно разных пользователей: технологических, офисных, домашних (бытовых). После Win7 компании нужно было оставить Windows как есть не усложняя ее для технологических и офисных пользователей (обычное колесо ведь давно работает !), а для домашних начать разработку принципиально новой ОС с пользовательским интерфейсом и простотой наподобие Android. Гипер-сложность будет требовать все более новых и новых выч.ресурсов, хотя принципиально ничего нового в саму операционную систему не привносится. Вдобавок это рано или поздно объективно будет негативно сказываться и на ее надёжности работы, а в конечном итоге придет в тупик.
По идее, для облегчения прикладной разработки, такие сложные процессы как асинхронность и многопоточность должны обеспечиваться и моделироваться инструментальными средствами более высокого уровня чем на уровне этих же корутин в 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 повторяющий процесс и жизненный цикл сложного технического изделия со всеми вытекающими отсюда выводами. Разработка (не писание !) программного кода один из важных этапов этого процесса, но не главный. Было бы значительно лучше, если бы генеративный ИИ умел анализировать уже разработанный кем-то программный код на предмет его корректности и надёжности. В конечном же итоге, качество и надёжность программного обеспечения всегда будут зависеть от профессионализма разработчиков, а не от какого нибудь ИИ.
Необходимость широкого применения предложенной технологии распознавания текста на перегнутых (смятых, нечетких) листах вряд ли. Скорее для спец применения, например, в цифровизации старых архивных документов или в криминалистике.
"Ей нужна была система, которая свяжет весь этот разнородный материал воедино и позволит с ним работать, а не просто складывать." - абстрактная формулировка требований.
Напрашивающийся вопросы:
Как и кем систематизирован материал, многоуровневая ли его классификация, как и где она физически зафиксирована ?
Учитывая, как сказано, сотни разнообразных статей и прочих данных, кто и каким способом связывал их с классификатором и наполнял базу ?
С помощью какого ПО и как клиентке стало удобно работать с отсистематизированной информацией ?
Сколько на такую сложную и объёмную работу затрачено времени (человеко/месяцев) ?
/// Если без воды и умных терминов — это интерфейс, позволяющий ИИ-модели обращаться за данными к внешнему ресурсу, а затем отдавать информацию обратно. ///
Пока все рассуждения автора носят общий характер. Чтобы дать оценку, необходимо на каком-то не сложном конкретном примере детально по шагам представить всю технологию обмена данными между ИИ-моделью и внешними источниками данных и информации.
///В значительной степени перед нами стоит основная, фундаментальная проблема — невозможность оставаться в лидерах в ИТ при отсутствии общего технологического развития страны, без высокого внутреннего спроса на ИТ технологии со стороны предприятий других секторов экономики.///
Это, собственно, и есть главный постулат. ИТ-технологии не могут существовать сами по себе в некотором вакууме широкого отсутствия на них спроса. По сути, для дальнейшего ИТ-прогресса, достижения конкурентоспособности и реального суверенитета в отрасли, необходимы системные разработки с новыми идеями на уровне операционных систем, инструментальных средств для создания прикладного ПО, систем управления базами данных и интеллектуальных систем поддержки принятия решений и ИИ. Фактически необходима и разработка своего hardwеre, унифицированного (совместимого) с зарубежными аналогами. Причем все это надо делать в сжатые для XXI-ого века сроки. Остаётся открытым ответ на главный вопрос: достаточности научно-технического и технологического потенциалов, наличие высоко-квалифицированных кадров и организаторов - управленцев для такой прорывной ИТ- миссии.
///Почему я считаю, что именно кардинальная смена стека\парадигмы или ЯП делают значительно мудрее? Каждый язык имеет свою философию и формирует у человека специфичный взгляд на решение технических задач.///
Чисто субъективное мнение, если оно личное автора, а может подаваться им просто "для затравки" обсуждения такого посыла.
Во первых, и главное из чего нужно исходить, так это понимание того, что процесс разработки серьезного программного обеспечения 1в1 повторяет процесс разработки технического изделия: проектирование, изготовление, контроль, тестирование и поддержка. Программист, как один из участников этой цепочки, выполняет функцию технолога (разработка техпроцесса изготовления конкретной детали, то есть алгоритма) и рабочего изготовляющего деталь на станке (кодирование процедуры, модуля на конкретном ЯП). Поэтому, если замыкаться только на функции изготовления детали, то есть только на функции разработки программного кода, то это делает такого программиста-кодировщика более универсальным в смысле знания нескольких ЯП и НЕ более того. Термин "мудрее" тут не уместен. Если со временем и с многолетней практикой, чаще в какой-то одной прикладной предметной области, такой программист-кодировщик освоит и научится выполнять ДРУГИЕ функции разработки - постановщика задачи, архитектора, управленца, разработчика БД, тестировщика и писателя документации - то тогда он действительно расширит свои профессиональные навыки как специалист-разработчик ПО вне зависимости от конкретного ЯП.
Вывод: язык программирования или конкретная СУБД конечно же играют большую роль в разработке ПО, но ОБЩИЕ принципы постановки задачи, проектирование архитектуры и БД для конкретной реализации (веб- приложение или что-то другое), управление разработкой и последующая поддержка программного продукта независимы от языка программирования.
Проблема Windows в ее гипер-сложности. Microsoft с упорством достойного лучшего применения старается "в одном флаконе" совместить потребности совершенно разных пользователей: технологических, офисных, домашних (бытовых). После Win7 компании нужно было оставить Windows как есть не усложняя ее для технологических и офисных пользователей (обычное колесо ведь давно работает !), а для домашних начать разработку принципиально новой ОС с пользовательским интерфейсом и простотой наподобие Android. Гипер-сложность будет требовать все более новых и новых выч.ресурсов, хотя принципиально ничего нового в саму операционную систему не привносится. Вдобавок это рано или поздно объективно будет негативно сказываться и на ее надёжности работы, а в конечном итоге придет в тупик.
По идее, для облегчения прикладной разработки, такие сложные процессы как асинхронность и многопоточность должны обеспечиваться и моделироваться инструментальными средствами более высокого уровня чем на уровне этих же корутин в 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 повторяющий процесс и жизненный цикл сложного технического изделия со всеми вытекающими отсюда выводами. Разработка (не писание !) программного кода один из важных этапов этого процесса, но не главный. Было бы значительно лучше, если бы генеративный ИИ умел анализировать уже разработанный кем-то программный код на предмет его корректности и надёжности. В конечном же итоге, качество и надёжность программного обеспечения всегда будут зависеть от профессионализма разработчиков, а не от какого нибудь ИИ.
Мало верится.
Необходимость широкого применения предложенной технологии распознавания текста на перегнутых (смятых, нечетких) листах вряд ли. Скорее для спец применения, например, в цифровизации старых архивных документов или в криминалистике.
"Ей нужна была система, которая свяжет весь этот разнородный материал воедино и позволит с ним работать, а не просто складывать." - абстрактная формулировка требований.
Напрашивающийся вопросы:
Как и кем систематизирован материал, многоуровневая ли его классификация, как и где она физически зафиксирована ?
Учитывая, как сказано, сотни разнообразных статей и прочих данных, кто и каким способом связывал их с классификатором и наполнял базу ?
С помощью какого ПО и как клиентке стало удобно работать с отсистематизированной информацией ?
Сколько на такую сложную и объёмную работу затрачено времени (человеко/месяцев) ?