Подытожу: для того, чтобы получить и обработать данные курса валют нужно знать синтаксис десятка разнородных программ. А еще делать это нужно в примитивной неудобной командной строке, которая об этих программах и об их типах данных ничего не знает и никак вам не поможет.
Вам не кажется, что индустрия свернула куда-то не туда? Что компьютеры не должны быть настолько сложными? Нет повода гордиться этим лоскутным одеялом, небрежно сшитым на коленке.
Ну я же совсем не об этом. Дерево это прежде всего структура данных. Дерево можно закодировать как строку символов. Как именно вывести дерево в виде строки символов - зависит от ваших стилистических предпочтений. Я предлагаю редактировать части дерева целиком, а не вводить их по буквам. Программы, которыми мы пользуемся тупят в том числе и от того, что программисты вынуждены делать слишком много рутинной работы.
Лучше рисовать картину не пиксель за пикселем, а крупными мазками. У нас на сегодняшний день нет инструментов, которые позволят писать программу "крупными мазками". Хоткеи для создания классов это не то, что нужно.
Выражу свою точку зрения иначе. Представьте, что программа хранится не в виде строки, а сразу в виде синтаксического дерева. Затем представьте, что редактор не разрешает вам писать программу как вы привыкли, буква за буквой. Вместо этого он предлагает вам добавлять элементы сразу в синтаксическое дерево. Дерево выводится на экран в том формате, в каком вы захотите, в зависимости от ваших стилистических предпочтений. Вот это я имею в виду.
Грустно наблюдать, что сейчас, в XXI веке человек всё еще должен заниматься тем, чтобы расставлять ключевые слова в правильном порядке и запятые в нужных местах. Важно ли на самом деле то, что функции будут реализованы в том же порядке, в котором они перечислены в интерфейсе? Если сделать 2 шага назад и посмотреть на проблему шире, то можно заметить, что мы всё еще пишем программы очень примитивным способом: набирая каждую букву и каждое слово вручную. Что мы можем сделать для того, чтобы это исправить? Интереснее думать в этом направлении, чем переживать о зяпятых.
Не совсем согласен с таким подходом. О будущем думать нужно. Пример: в Jira SDK нет нормальной поддержки транзакций, хотя если бы о них подумали заранее, боли было бы гораздо меньше. Вот история вопроса для тех, кому интересно: https://jira.atlassian.com/browse/JRASERVER-25808
Набросал программу: https://github.com/vzhn/z3-inv-matrix. Действительно, матрицы 3x3 считаются достаточно бодро, но для 5x5 я уже не дождался ответа. Скорее всего дело в операции mod, с ней теория арифметики перестает быть линейной, что делает задачу трудной для z3. Есть такой ответ на SO: https://stackoverflow.com/a/66785785.
Задержку по видео измеряем с помощью уже отработанного приёма: снимаем секундомер, фотографируем вместе экран с исходящим видео и экран принимающего клиента, сравниваем.
Поделюсь идеей: если вывести время в виде QR-кода, задержку можно будет измерить программно, без участия человека. Такое решение даже позволит оформить этот эксперимент в виде юнит-теста: эмулятор сервера кодирует время в видеопоток QR-кодов, эмулятор клиента декодирует QR-коды и оценивает задержку.
В java недавно завезли jpackage. С ее помощью можно собрать инсталлятор msi, пакеты rpm, deb и dmg для macOS. Это избавит пользователя вашей программы от необходимости устанавливать java на компьютер.
Проблема с join в том, что их нужно набирать руками. Если база сложная, в ней много таблиц и связей, это сильно замедляет работу. Мотив в том, чтобы свести ручную работу к минимуму: сtrl-v, enter, пара кликов и нужные данные получены.
Подытожу: для того, чтобы получить и обработать данные курса валют нужно знать синтаксис десятка разнородных программ. А еще делать это нужно в примитивной неудобной командной строке, которая об этих программах и об их типах данных ничего не знает и никак вам не поможет.
Вам не кажется, что индустрия свернула куда-то не туда? Что компьютеры не должны быть настолько сложными? Нет повода гордиться этим лоскутным одеялом, небрежно сшитым на коленке.
Внимание, важный вопрос. Как читается название вашего сервиса?
Для интересующихся темой рекурсии советую ещё посмотреть на механизм работы Y-комбинатора из комбина́торной ло́гики.
Насчет oklab: вот есть страничка автора про преимущества oklab над lab и про сравнение разных colorpicker: https://bottosson.github.io/posts/colorpicker/
Ну я же совсем не об этом. Дерево это прежде всего структура данных. Дерево можно закодировать как строку символов. Как именно вывести дерево в виде строки символов - зависит от ваших стилистических предпочтений. Я предлагаю редактировать части дерева целиком, а не вводить их по буквам. Программы, которыми мы пользуемся тупят в том числе и от того, что программисты вынуждены делать слишком много рутинной работы.
Лучше рисовать картину не пиксель за пикселем, а крупными мазками. У нас на сегодняшний день нет инструментов, которые позволят писать программу "крупными мазками". Хоткеи для создания классов это не то, что нужно.
Выражу свою точку зрения иначе. Представьте, что программа хранится не в виде строки, а сразу в виде синтаксического дерева. Затем представьте, что редактор не разрешает вам писать программу как вы привыкли, буква за буквой. Вместо этого он предлагает вам добавлять элементы сразу в синтаксическое дерево. Дерево выводится на экран в том формате, в каком вы захотите, в зависимости от ваших стилистических предпочтений. Вот это я имею в виду.
Грустно наблюдать, что сейчас, в XXI веке человек всё еще должен заниматься тем, чтобы расставлять ключевые слова в правильном порядке и запятые в нужных местах. Важно ли на самом деле то, что функции будут реализованы в том же порядке, в котором они перечислены в интерфейсе? Если сделать 2 шага назад и посмотреть на проблему шире, то можно заметить, что мы всё еще пишем программы очень примитивным способом: набирая каждую букву и каждое слово вручную. Что мы можем сделать для того, чтобы это исправить? Интереснее думать в этом направлении, чем переживать о зяпятых.
Не совсем согласен с таким подходом. О будущем думать нужно. Пример: в Jira SDK нет нормальной поддержки транзакций, хотя если бы о них подумали заранее, боли было бы гораздо меньше. Вот история вопроса для тех, кому интересно: https://jira.atlassian.com/browse/JRASERVER-25808
А я бы попробовал использовать SMT-решатель Z3.
Набросал программу: https://github.com/vzhn/z3-inv-matrix. Действительно, матрицы 3x3 считаются достаточно бодро, но для 5x5 я уже не дождался ответа. Скорее всего дело в операции mod, с ней теория арифметики перестает быть линейной, что делает задачу трудной для z3. Есть такой ответ на SO: https://stackoverflow.com/a/66785785.
Challenge accepted! Попробую инвертировать матрицу над кольцом вычетов, напишу если получится.
Интересно. Можете показать код? Есть ли в ваших формулах кванторы?
К сожалению, ничего не скажу. Начал этот путь недавно.
Оформите решение в системе coq.
Поделюсь идеей: если вывести время в виде QR-кода, задержку можно будет измерить программно, без участия человека. Такое решение даже позволит оформить этот эксперимент в виде юнит-теста: эмулятор сервера кодирует время в видеопоток QR-кодов, эмулятор клиента декодирует QR-коды и оценивает задержку.