Любая система моделирования (обьектов или процессов) в первую очередь базируется на математическое аппарате для конкретного типа задач в своей предметной области. В принципе НЕ может бы универсальной системы моделирования или, как вы её называете, одного языка моделирования "на все случаи жизни". В противном случае, говоря упрощенно, не было бы тогда и механиков, электриков, гидравликов и прочих других тех.специальностей. Другое дело, что может иметь место применение какие-то общих математические методов которые подходят к разным техническим системам и обьектам. Тогда соответственно и системы моделирования специализируется на этих математических методах. Например, одна из старейших систем имитационное моделирования GPSS для систем массового обслуживания или системы моделирования с помощью метода конечных элементов типа ANSYS. Везде свой математический аппарат, если уж так хотите, свой язык моделирования имеющие мало чего общего с универсальными языками для программирования ЭВМ.
В принципе, такие "прибамбасы" типа "помощника" AI квалифицированному пользователю (и не только Excel) и "на хрен" не нужны, своей головы хватит. Только для тех которые не хотят учиться и, главное, самостоятельно думать.
Большая работа. Необычным выглядит чёрный фон форм пользовательского интерфейса, что наводит на воспоминания славных времен работы в командной строке MS DOS. Обычно утилита резервного копирования и восстановления БД "по определению" является необходимым атрибутом администрирование самой СУБД, как например в MS SQL это делают функции BackUp и Restore, в том числе и по расписанию. Не работал и не знаю самой PostgreSQL, но, видимо, автора статьи подвинули какие-то серьёзные причины (кроме как формата Open Source, удобства UGI, функций оповещения и др. которые в общем-то и не так критичны), чтобы заняться таким серьёзным проектом в свободное от основной работы время.
Языки моделирования содержат средства описания объектов в терминах предметных систем, их связи, а также и возможное взаимодействие во времени. Корректнее говорить именно как о таковых системах моделирования (СМ), а не языках, так как первое более широкое понятие чем второе. Как языков программирования, не существует универсальной СМ "на все случаи жизни", все определяет конкретная задача и область моделирования. Понятия, структура и описание обьектов относящихся к СМ в принципе ни коим образом НЕ соотносятся и НЕ пересекаются с понятиями и объектами в универсальных языков програмирования, как упорно пытается сделать автор статьи. Это совершенно разные по своей сути и назначению инструментальные средства.
В "таких материях" только "субъективка", кому как, но Maccimo от меня +. Мой принцип похожий: "если работает, простое и надёжное, не требует лишних затрат, то пусть и работает". Относится не только к обычному колесу, но и к ПО тоже.
Все верно, только забыли добавить, что с такой "логикой" и колесу в автомобиле comerc'а уже давненько "пора на покой", не как ему бедному аж 2.5 тыс.лет.
Сначала важно отметить, работает ли трудяга в одиночку над всем проектом "От и До" или он в коллективе, где чёткое разделение обязанностей и специализация между исполнителями и все под единым управлением. В этих вариантах принципиально важное отличие и свои метрики. Если же говорить в общем, то Время Кодирования (непосредственная разработка кода) может соизмеряться с Этапом проектирования (который более важен и первичен) всей программной архитектуры или даже быть значительно меньше его, если детализация проектирования будет спущена на уровень отдельных процедур языка программирования. Здесь кодирование, конечно же, включает и процесс локальной отладки своей части работы. А тестирование на уровне под-систем и в целом системы все цело зависят от качества исполнения предшествующих этапов. Соизмеримое со всеми предыдущим этапами займёт и время разработки подробной (детальной) рабочей документации и документации для пользователей программного продукта.
Конкретный пример проектирования реляционной схемы БД с помощью AI от начального формулирования требований (постановки задачи) и с дальнейшей детализацией всех шагов до получения конечного результата. Можно взять пример с небольшой БД в которой ~3-5 таблиц и с отношениями "один ко многим" и "многие ко многим". Потом мы его с Вами и обсудим.
Сравнивать вещи (в широком смысле) созданные в разное время просто не корректно. Автомобили не пробовали сравнивать? Все хорошо относительно к своему времени. Но это не значит, что все старое вдруг стало плохим и от него нужно срочно отказываться. Если работает, надёжно и простое, удовлетворяет необходимым потребностям, так пусть и работает. Так и со средствами разработки ПО: если с помощью известного программисту языка можно успешно и удобно разрабатывать софт, то для этого вовсе не обязательно искать какие-то новые инструменты. В "природе на все случаи жизни" одного языка программирования просто не существует, а главное и не нужно. Все определяет поставленная задача и для её решения сформулированные требования. Сегодня стал популярным Python, a завтра, будьте уверены, Alligator.
VB и VBA создавались Microsoft как относительно простые инструменты для разработки приложений под Windows и MS Office. Исключительно только для этих целей и не более. По сути VB (последняя версия VB6) и VBA это один мощный язык программирования, который впитал в себя все лучшее как из истории BASIC'а (во всяком случае его реализаций самой Microsoft), так и других языков с читабельным синтаксисом, наполнился концептуальностью (прежде всего за счёт ActiveX и СОМ технологий) для разработки приложений в Windows и в среде объектных COM-моделей приложений входящих в MS Office для их прикладного функционального расширения. Саму задумку и реализацию всего этого проекта под названием "VB и VBA" с полным правом можно считать гениальным решением Microsoft (а может и самого Б. Гейтса). Дальнейшее расширение и развитие проекта не имело смысла, так как "все было сказано и сделано", а компании надо идти ("ехать") дальше ("продолжать крутить велосипед"), чтобы "кормить" своих разработчиков и получать прибыль на новых технологиях и продуктах. Разработчики под Windows могут и сейчас с успехом использовать эти инструменты хотя поддержка среды разработки VB6 к большому сожалению давно прекращена, но библиотека исполнения его откомпилированного кода продолжает поддерживаться и последними версиями Windows.
Вы применяете ИТ-мерки конца четверти XXI-ого века к 70-ым годам XX-ого века (т. е. 50-ти летнему прошлому выч.техники), когда микро - ЭВМ были всего с 4Кб (в лучшем случае 8Кб) оперативной памяти без внешней и ввод программы и данных на перфоленте. Поэтому, что возможно было делать на этих ресурсах, то делали. В данном случае и интерпретатор для простенького BASIC'a. Никогда и "никаким боком" реализации BASIC'а не соотносились тогда (а сейчас и тем более) с Fortran'ом - мощным компилируемым языком программирования ориентированным на компьютеризацию в первую очередь математических и инженерно-технических задач и успешно выполняющим свою миссию и в XXI-о веке. Что ж, приходится делать ликбез, хотя по Вашему возрасту это должны помнить.
Принцип "что работало, работает и может работать дальше, а главное надежное и простое, то путь и работает" верен не только для обычного колеса, но и для всего остального, включая софт.
Любая система моделирования (обьектов или процессов) в первую очередь базируется на математическое аппарате для конкретного типа задач в своей предметной области. В принципе НЕ может бы универсальной системы моделирования или, как вы её называете, одного языка моделирования "на все случаи жизни". В противном случае, говоря упрощенно, не было бы тогда и механиков, электриков, гидравликов и прочих других тех.специальностей. Другое дело, что может иметь место применение какие-то общих математические методов которые подходят к разным техническим системам и обьектам. Тогда соответственно и системы моделирования специализируется на этих математических методах. Например, одна из старейших систем имитационное моделирования GPSS для систем массового обслуживания или системы моделирования с помощью метода конечных элементов типа ANSYS. Везде свой математический аппарат, если уж так хотите, свой язык моделирования имеющие мало чего общего с универсальными языками для программирования ЭВМ.
В принципе, такие "прибамбасы" типа "помощника" AI квалифицированному пользователю (и не только Excel) и "на хрен" не нужны, своей головы хватит. Только для тех которые не хотят учиться и, главное, самостоятельно думать.
Большая работа. Необычным выглядит чёрный фон форм пользовательского интерфейса, что наводит на воспоминания славных времен работы в командной строке MS DOS. Обычно утилита резервного копирования и восстановления БД "по определению" является необходимым атрибутом администрирование самой СУБД, как например в MS SQL это делают функции BackUp и Restore, в том числе и по расписанию. Не работал и не знаю самой PostgreSQL, но, видимо, автора статьи подвинули какие-то серьёзные причины (кроме как формата Open Source, удобства UGI, функций оповещения и др. которые в общем-то и не так критичны), чтобы заняться таким серьёзным проектом в свободное от основной работы время.
И, главное, на это "ведутся и клюют".
Пока законодательно не зафиксировано (хотя давно пора), но, как говорится, "поживём-увидим" на это действо.
Остаётся открытым самый главный вопрос: кто будет нести ответственность за принимаемые ИИ решения и действия.
Языки моделирования содержат средства описания объектов в терминах предметных систем, их связи, а также и возможное взаимодействие во времени. Корректнее говорить именно как о таковых системах моделирования (СМ), а не языках, так как первое более широкое понятие чем второе. Как языков программирования, не существует универсальной СМ "на все случаи жизни", все определяет конкретная задача и область моделирования. Понятия, структура и описание обьектов относящихся к СМ в принципе ни коим образом НЕ соотносятся и НЕ пересекаются с понятиями и объектами в универсальных языков програмирования, как упорно пытается сделать автор статьи. Это совершенно разные по своей сути и назначению инструментальные средства.
В "таких материях" только "субъективка", кому как, но Maccimo от меня +. Мой принцип похожий: "если работает, простое и надёжное, не требует лишних затрат, то пусть и работает". Относится не только к обычному колесу, но и к ПО тоже.
Все верно, только забыли добавить, что с такой "логикой" и колесу в автомобиле comerc'а уже давненько "пора на покой", не как ему бедному аж 2.5 тыс.лет.
Скорее, XRust, от слова "хруст".
Так это же будет Xrust !
Сначала важно отметить, работает ли трудяга в одиночку над всем проектом "От и До" или он в коллективе, где чёткое разделение обязанностей и специализация между исполнителями и все под единым управлением. В этих вариантах принципиально важное отличие и свои метрики. Если же говорить в общем, то Время Кодирования (непосредственная разработка кода) может соизмеряться с Этапом проектирования (который более важен и первичен) всей программной архитектуры или даже быть значительно меньше его, если детализация проектирования будет спущена на уровень отдельных процедур языка программирования. Здесь кодирование, конечно же, включает и процесс локальной отладки своей части работы. А тестирование на уровне под-систем и в целом системы все цело зависят от качества исполнения предшествующих этапов. Соизмеримое со всеми предыдущим этапами займёт и время разработки подробной (детальной) рабочей документации и документации для пользователей программного продукта.
Будем ждать.
Конкретный пример проектирования реляционной схемы БД с помощью AI от начального формулирования требований (постановки задачи) и с дальнейшей детализацией всех шагов до получения конечного результата. Можно взять пример с небольшой БД в которой ~3-5 таблиц и с отношениями "один ко многим" и "многие ко многим". Потом мы его с Вами и обсудим.
Rikkster, давайте по шагам полный пример "в студию", а там конкретно и поговорим!
Языки программирования "умирать" могут в головах только у некоторых людей, а на самом деле они живут и прекрасно себя чувствуют.
Сравнивать вещи (в широком смысле) созданные в разное время просто не корректно. Автомобили не пробовали сравнивать? Все хорошо относительно к своему времени. Но это не значит, что все старое вдруг стало плохим и от него нужно срочно отказываться. Если работает, надёжно и простое, удовлетворяет необходимым потребностям, так пусть и работает. Так и со средствами разработки ПО: если с помощью известного программисту языка можно успешно и удобно разрабатывать софт, то для этого вовсе не обязательно искать какие-то новые инструменты. В "природе на все случаи жизни" одного языка программирования просто не существует, а главное и не нужно. Все определяет поставленная задача и для её решения сформулированные требования. Сегодня стал популярным Python, a завтра, будьте уверены, Alligator.
Продолжение ликбеза.
VB и VBA создавались Microsoft как относительно простые инструменты для разработки приложений под Windows и MS Office. Исключительно только для этих целей и не более. По сути VB (последняя версия VB6) и VBA это один мощный язык программирования, который впитал в себя все лучшее как из истории BASIC'а (во всяком случае его реализаций самой Microsoft), так и других языков с читабельным синтаксисом, наполнился концептуальностью (прежде всего за счёт ActiveX и СОМ технологий) для разработки приложений в Windows и в среде объектных COM-моделей приложений входящих в MS Office для их прикладного функционального расширения. Саму задумку и реализацию всего этого проекта под названием "VB и VBA" с полным правом можно считать гениальным решением Microsoft (а может и самого Б. Гейтса). Дальнейшее расширение и развитие проекта не имело смысла, так как "все было сказано и сделано", а компании надо идти ("ехать") дальше ("продолжать крутить велосипед"), чтобы "кормить" своих разработчиков и получать прибыль на новых технологиях и продуктах. Разработчики под Windows могут и сейчас с успехом использовать эти инструменты хотя поддержка среды разработки VB6 к большому сожалению давно прекращена, но библиотека исполнения его откомпилированного кода продолжает поддерживаться и последними версиями Windows.
Вы применяете ИТ-мерки конца четверти XXI-ого века к 70-ым годам XX-ого века (т. е. 50-ти летнему прошлому выч.техники), когда микро - ЭВМ были всего с 4Кб (в лучшем случае 8Кб) оперативной памяти без внешней и ввод программы и данных на перфоленте. Поэтому, что возможно было делать на этих ресурсах, то делали. В данном случае и интерпретатор для простенького BASIC'a. Никогда и "никаким боком" реализации BASIC'а не соотносились тогда (а сейчас и тем более) с Fortran'ом - мощным компилируемым языком программирования ориентированным на компьютеризацию в первую очередь математических и инженерно-технических задач и успешно выполняющим свою миссию и в XXI-о веке. Что ж, приходится делать ликбез, хотя по Вашему возрасту это должны помнить.
Принцип "что работало, работает и может работать дальше, а главное надежное и простое, то путь и работает" верен не только для обычного колеса, но и для всего остального, включая софт.