Не документированные особенности конкретного компилятора (интерпретатора) для любого языка программирования - источник серьезных ошибок, которых вроде как "по умолчанию" и не должно быть. Все зависит от профессионализма разработчика, который вне зависимости от ЯП должен знать и следовать фундаментальным правилам надёжного программирования.
В данном примере функция добавления элемента в массив может выглядеть примерно так:
Function AddItem (byVal Item, byRef kol_items, byRef Arr(), byRef error) as Boolean
/// Функция возвращает True если операция выполнена успешно, False если не выполнена и в еггог возвращается код ошибки. Добавляемый элемент Item объявлен как входной параметр передающийся значением. Остальные параметры объявлены как ссылки (адреса) на переменные обьявленные в вызывающей процедуре: текущее кол-во элементов в массиве, сам массив элементов и код возвращаемой ошибки. Причём текущее значение кол-ва элементов в массиве kol_items является одновременно и входным и выходным параметром передаваемые в функцию по ссылке. ///
AddItem = False
error = 0
If kol_items < 0 then error=1 Exit Function EndIf ///выход при отрицательном kol_items///
kol_items = kol_items + 1
AddDimention Arr, kol_items ///увеличение размерности массива до kol_items
Arr (kol_items) = Item ///непосредственное добавление нового элемента
AddItem = True ///успешно завершение функции
End Function
Здесь AddDimention есть оператор или функция ЯП который(ая) увеличивает текущую размерность массива до заданного значения при сохранении уже имеющихся в нем элементов. Нумерация элементов массива логично начинается с 1. В принципе можно обойтись и БЕЗ error, но в этом случае вызывающая процедура должна сама убедиться в добавлении элемента, сравнив отправленное значение kol_items с полученным. Если оно увеличилось на 1, то добавление прошло успешно. Но для соблюдения стиля надёжного программирования, любая процедура (функция), помимо обязательной проверки значений входных параметров на корректность, должна возвращать код ошибки (лучше вместе с текстом) возникающей при её выполнении.
"суть клиентской ОС запускать приложеньки" - хаха. Вы сидите в одной ОС под названием "Windows" как зашоренный и с нетерпением ждёте выхода ее 20-ой версии. А о таких ОС "бытового" назначения, например как Android, с совершенно другой философией пользовательского интерфейса составляющие её основу и ориентирован ног на массового пользователя как буд-то и не знаете. Да нет сударь, прошло уже без малого 20 лет когда взгляд на пользовательский интерфейс, определяемый ИМЕННО и ТОЛЬКО самой операционной системой, все цело зависит от людей (а правильно категорий пользователей) для которых он предназначен. По вашей логике достаточно иметь один автомобиль, который будет возить и пассажиров и асфальт и продукты и все прочее. Windows это один из выдающихся проектов в истории создания операционных систем для ЭВМ. Но время и прогресс заставляют разработчиков меняться и искать соответствующие им новые идеи. Выпуски Windows, после 7-ой (а может и 8-ой) версии принципиально ничего нового НЕ дали. Это простым языком называется "толочь одну и туже воду в ступе". Кроме внутреннего усложнения, требующего высоких вычислительный ресурсов, и удалённого администрирование системы самой Microsoft.
Как понял, смысл примеров заключается исключительно только в том, чтобы показать локальную возможность реализации алгоритмов вычислительного характера на конкретном диалекте языке SQL, хотя его основное назначение состоит в получении и обработке данных хранящихся в реляционной БД.
После 7-ой, а может и 8-ой версии успешный проект под названием Windows нужно было вовремя закрыть и начать разработки принципиально новых операционных систем, ориентированных на свои категории пользователей. Microsoft с упорством достойного лучшего применения продолжает "накачивать в одном флаконе" потребности совершенно разных категорий пользователей, тем самым все усложняя и усложняя свое детище и нарастающе проигрывая в надёжности. Ясно, что рано или поздно это хорошим для компании не закончится.
Что работает, просто и надёжно, не требует лишних затрат, то пусть и продолжает работать. Этот принцип верен не только для обычного колеса, но и для всего другого, включая программное обеспечение (soft). Компьютерные технологии "устаревают и перестают быть актуальными" в первую очередь только в головах управляющих и менеджеров крупных корпораций, а также тех кто запрограммирован ими. С одной лишь целью - продолжать получать высокую прибыль на монетизации якобы "более совершенных" (а по сути иногда ничего принципиально нового и не несущих (те же последние версии Windows)) программных продуктах.
Многоуровневая структура запроса на SQL (как и в приведенном примере) вещь далеко не тривиальная. Как там будет срабатывать интерпретатор SQL при разборе вложенности и обработке данных зависит от реализации его в конкретной СУБД и качества нормализации БД. Здесь имеется ввиду время выполнения запроса как основной фактор. Обычно сложную вложенность операторов select рекомендуют разбивать на несколько запросов объединяя их в одной транзакции и комбинируя между собой операторы select и insert с использованием рабочих (временных) temp-таблиц. Выше сказанное в данном комментарии относится исключительно к общей теории языка SQL для манипулирования данными в реляционной БД, а НЕ как оценка приведенной в статье реализации на этом языке конкретного вычислительного примера.
Правильное задание точности чисел и знание правил их округления - залог получения верного результата в конкретной прикладной вычислительной задаче. Это основа подготовки профессионального программиста-разработчика. Также как и обязательное знание представления чисел в памяти ЭВМ: целых, дробных (с мантиссой и порядком), 2-ичной и 16-ричой систем исчисления. Без этих фундаментальных знаний на выходе кустарный кодировщик.
Любая система моделирования (обьектов или процессов) в первую очередь базируется на математическое аппарате для конкретного типа задач в своей предметной области. В принципе НЕ может бы универсальной системы моделирования или, как вы её называете, одного языка моделирования "на все случаи жизни". В противном случае, говоря упрощенно, не было бы тогда и механиков, электриков, гидравликов и прочих других тех.специальностей. Другое дело, что может иметь место применение какие-то общих математические методов которые подходят к разным техническим системам и обьектам. Тогда соответственно и системы моделирования специализируется на этих математических методах. Например, одна из старейших систем имитационное моделирования GPSS для систем массового обслуживания или системы моделирования с помощью метода конечных элементов типа ANSYS. Везде свой математический аппарат, если уж так хотите, свой язык моделирования имеющие мало чего общего с универсальными языками для программирования ЭВМ.
В принципе, такие "прибамбасы" типа "помощника" AI квалифицированному пользователю (и не только Excel) и "на хрен" не нужны, своей головы хватит. Только для тех которые не хотят учиться и, главное, самостоятельно думать.
Большая работа. Необычным выглядит чёрный фон форм пользовательского интерфейса, что наводит на воспоминания славных времен работы в командной строке MS DOS. Обычно утилита резервного копирования и восстановления БД "по определению" является необходимым атрибутом администрирование самой СУБД, как например в MS SQL это делают функции BackUp и Restore, в том числе и по расписанию. Не работал и не знаю самой PostgreSQL, но, видимо, автора статьи подвинули какие-то серьёзные причины (кроме как формата Open Source, удобства UGI, функций оповещения и др. которые в общем-то и не так критичны), чтобы заняться таким серьёзным проектом в свободное от основной работы время.
Языки моделирования содержат средства описания объектов в терминах предметных систем, их связи, а также и возможное взаимодействие во времени. Корректнее говорить именно как о таковых системах моделирования (СМ), а не языках, так как первое более широкое понятие чем второе. Как языков программирования, не существует универсальной СМ "на все случаи жизни", все определяет конкретная задача и область моделирования. Понятия, структура и описание обьектов относящихся к СМ в принципе ни коим образом НЕ соотносятся и НЕ пересекаются с понятиями и объектами в универсальных языков програмирования, как упорно пытается сделать автор статьи. Это совершенно разные по своей сути и назначению инструментальные средства.
В "таких материях" только "субъективка", кому как, но Maccimo от меня +. Мой принцип похожий: "если работает, простое и надёжное, не требует лишних затрат, то пусть и работает". Относится не только к обычному колесу, но и к ПО тоже.
Все верно, только забыли добавить, что с такой "логикой" и колесу в автомобиле comerc'а уже давненько "пора на покой", не как ему бедному аж 2.5 тыс.лет.
Не документированные особенности конкретного компилятора (интерпретатора) для любого языка программирования - источник серьезных ошибок, которых вроде как "по умолчанию" и не должно быть. Все зависит от профессионализма разработчика, который вне зависимости от ЯП должен знать и следовать фундаментальным правилам надёжного программирования.
В данном примере функция добавления элемента в массив может выглядеть примерно так:
Function AddItem (byVal Item, byRef kol_items, byRef Arr(), byRef error) as Boolean
/// Функция возвращает True если операция выполнена успешно, False если не выполнена и в еггог возвращается код ошибки. Добавляемый элемент Item объявлен как входной параметр передающийся значением. Остальные параметры объявлены как ссылки (адреса) на переменные обьявленные в вызывающей процедуре: текущее кол-во элементов в массиве, сам массив элементов и код возвращаемой ошибки. Причём текущее значение кол-ва элементов в массиве kol_items является одновременно и входным и выходным параметром передаваемые в функцию по ссылке. ///
AddItem = False
error = 0
If kol_items < 0 then error=1 Exit Function EndIf ///выход при отрицательном kol_items///
kol_items = kol_items + 1
AddDimention Arr, kol_items ///увеличение размерности массива до kol_items
Arr (kol_items) = Item ///непосредственное добавление нового элемента
AddItem = True ///успешно завершение функции
End Function
Здесь AddDimention есть оператор или функция ЯП который(ая) увеличивает текущую размерность массива до заданного значения при сохранении уже имеющихся в нем элементов. Нумерация элементов массива логично начинается с 1. В принципе можно обойтись и БЕЗ error, но в этом случае вызывающая процедура должна сама убедиться в добавлении элемента, сравнив отправленное значение kol_items с полученным. Если оно увеличилось на 1, то добавление прошло успешно. Но для соблюдения стиля надёжного программирования, любая процедура (функция), помимо обязательной проверки значений входных параметров на корректность, должна возвращать код ошибки (лучше вместе с текстом) возникающей при её выполнении.
"понятность" в смысле простоты восприятия алгоритма по самому коду по сравнению с ЯП, например Fortran или Pascal, стоит на абсолютном 0 (нуле).
Фантазеры заказухи "запудривания мозгов" ИИ-том с одной лишь целью - получения максимальной прибыли от монетизации своих программных продуктов.
"суть клиентской ОС запускать приложеньки" - хаха. Вы сидите в одной ОС под названием "Windows" как зашоренный и с нетерпением ждёте выхода ее 20-ой версии. А о таких ОС "бытового" назначения, например как Android, с совершенно другой философией пользовательского интерфейса составляющие её основу и ориентирован ног на массового пользователя как буд-то и не знаете. Да нет сударь, прошло уже без малого 20 лет когда взгляд на пользовательский интерфейс, определяемый ИМЕННО и ТОЛЬКО самой операционной системой, все цело зависит от людей (а правильно категорий пользователей) для которых он предназначен. По вашей логике достаточно иметь один автомобиль, который будет возить и пассажиров и асфальт и продукты и все прочее. Windows это один из выдающихся проектов в истории создания операционных систем для ЭВМ. Но время и прогресс заставляют разработчиков меняться и искать соответствующие им новые идеи. Выпуски Windows, после 7-ой (а может и 8-ой) версии принципиально ничего нового НЕ дали. Это простым языком называется "толочь одну и туже воду в ступе". Кроме внутреннего усложнения, требующего высоких вычислительный ресурсов, и удалённого администрирование системы самой Microsoft.
Как понял, смысл примеров заключается исключительно только в том, чтобы показать локальную возможность реализации алгоритмов вычислительного характера на конкретном диалекте языке SQL, хотя его основное назначение состоит в получении и обработке данных хранящихся в реляционной БД.
После 7-ой, а может и 8-ой версии успешный проект под названием Windows нужно было вовремя закрыть и начать разработки принципиально новых операционных систем, ориентированных на свои категории пользователей. Microsoft с упорством достойного лучшего применения продолжает "накачивать в одном флаконе" потребности совершенно разных категорий пользователей, тем самым все усложняя и усложняя свое детище и нарастающе проигрывая в надёжности. Ясно, что рано или поздно это хорошим для компании не закончится.
Что работает, просто и надёжно, не требует лишних затрат, то пусть и продолжает работать. Этот принцип верен не только для обычного колеса, но и для всего другого, включая программное обеспечение (soft). Компьютерные технологии "устаревают и перестают быть актуальными" в первую очередь только в головах управляющих и менеджеров крупных корпораций, а также тех кто запрограммирован ими. С одной лишь целью - продолжать получать высокую прибыль на монетизации якобы "более совершенных" (а по сути иногда ничего принципиально нового и не несущих (те же последние версии Windows)) программных продуктах.
Многоуровневая структура запроса на SQL (как и в приведенном примере) вещь далеко не тривиальная. Как там будет срабатывать интерпретатор SQL при разборе вложенности и обработке данных зависит от реализации его в конкретной СУБД и качества нормализации БД. Здесь имеется ввиду время выполнения запроса как основной фактор. Обычно сложную вложенность операторов select рекомендуют разбивать на несколько запросов объединяя их в одной транзакции и комбинируя между собой операторы select и insert с использованием рабочих (временных) temp-таблиц. Выше сказанное в данном комментарии относится исключительно к общей теории языка SQL для манипулирования данными в реляционной БД, а НЕ как оценка приведенной в статье реализации на этом языке конкретного вычислительного примера.
Правильное задание точности чисел и знание правил их округления - залог получения верного результата в конкретной прикладной вычислительной задаче. Это основа подготовки профессионального программиста-разработчика. Также как и обязательное знание представления чисел в памяти ЭВМ: целых, дробных (с мантиссой и порядком), 2-ичной и 16-ричой систем исчисления. Без этих фундаментальных знаний на выходе кустарный кодировщик.
Любая система моделирования (обьектов или процессов) в первую очередь базируется на математическое аппарате для конкретного типа задач в своей предметной области. В принципе НЕ может бы универсальной системы моделирования или, как вы её называете, одного языка моделирования "на все случаи жизни". В противном случае, говоря упрощенно, не было бы тогда и механиков, электриков, гидравликов и прочих других тех.специальностей. Другое дело, что может иметь место применение какие-то общих математические методов которые подходят к разным техническим системам и обьектам. Тогда соответственно и системы моделирования специализируется на этих математических методах. Например, одна из старейших систем имитационное моделирования GPSS для систем массового обслуживания или системы моделирования с помощью метода конечных элементов типа ANSYS. Везде свой математический аппарат, если уж так хотите, свой язык моделирования имеющие мало чего общего с универсальными языками для программирования ЭВМ.
В принципе, такие "прибамбасы" типа "помощника" AI квалифицированному пользователю (и не только Excel) и "на хрен" не нужны, своей головы хватит. Только для тех которые не хотят учиться и, главное, самостоятельно думать.
Большая работа. Необычным выглядит чёрный фон форм пользовательского интерфейса, что наводит на воспоминания славных времен работы в командной строке MS DOS. Обычно утилита резервного копирования и восстановления БД "по определению" является необходимым атрибутом администрирование самой СУБД, как например в MS SQL это делают функции BackUp и Restore, в том числе и по расписанию. Не работал и не знаю самой PostgreSQL, но, видимо, автора статьи подвинули какие-то серьёзные причины (кроме как формата Open Source, удобства UGI, функций оповещения и др. которые в общем-то и не так критичны), чтобы заняться таким серьёзным проектом в свободное от основной работы время.
И, главное, на это "ведутся и клюют".
Пока законодательно не зафиксировано (хотя давно пора), но, как говорится, "поживём-увидим" на это действо.
Остаётся открытым самый главный вопрос: кто будет нести ответственность за принимаемые ИИ решения и действия.
Языки моделирования содержат средства описания объектов в терминах предметных систем, их связи, а также и возможное взаимодействие во времени. Корректнее говорить именно как о таковых системах моделирования (СМ), а не языках, так как первое более широкое понятие чем второе. Как языков программирования, не существует универсальной СМ "на все случаи жизни", все определяет конкретная задача и область моделирования. Понятия, структура и описание обьектов относящихся к СМ в принципе ни коим образом НЕ соотносятся и НЕ пересекаются с понятиями и объектами в универсальных языков програмирования, как упорно пытается сделать автор статьи. Это совершенно разные по своей сути и назначению инструментальные средства.
В "таких материях" только "субъективка", кому как, но Maccimo от меня +. Мой принцип похожий: "если работает, простое и надёжное, не требует лишних затрат, то пусть и работает". Относится не только к обычному колесу, но и к ПО тоже.
Все верно, только забыли добавить, что с такой "логикой" и колесу в автомобиле comerc'а уже давненько "пора на покой", не как ему бедному аж 2.5 тыс.лет.
Скорее, XRust, от слова "хруст".
Так это же будет Xrust !