Хм.... всё не то - я то думал в статье будет написано как создавать высокопроизводительный код, выполняемый на стороне сервера Tarantool в основном потоке сервера - т.е. рядом с данными. А тут... просто примеры использования готовых сторонних клиентов на двух языках, использующие готовые черные ящики - коннекторы из библиотек, специально созданных для этих языков. Причём такие - что промежуточный сервер им вообще не особо то и нужен - можно было бы прямо из фронт-енда к Taratool'у обращаться (оставим в стороне - что такая работа не совсем кошерно - ведь Tarantool позиционируется и как сервер приложений).
Да и в самом примере работы с Tarantool не показано ничего особенного - с чем бы не менее эффективно не справится любая другая конкурирующая СУБД (а Tarantool конкурирует с разными типами СУБД).
Код на Golang (мне - не сторонниre Golang) кажется уродским чрезмерно перегруженным. Нет никакого синтаксического сахара - поэтому в XXI веке это выглядит печально!
Код на Paython (как по мне - более симпатичном ЯП, чем Golang, но не идеальном языке) выглядит несколько лучше, но в нём потеряна вся примитивная обработка ошибок.
Жаль автор не привёл и native-вариант для Tarantool - созданный на языке Lua - он бы смотрелся куда лучше (мнение матёрого программиста, почти не создававшего скриптов на Lua) - а код на Lua что-то среднее между Golang, Python и JS
Заодно можно было бы показать производительность разных решений, и преимущество размещение таких функций прямо на сервере Tararantool.
Формат обращения к API Tarantool в исполосованных коннекторах мне тоже показался перегруженным и корявым - текстовые строки в ЯП это одновременно и мощь универсальности и головная боль, и снижение читабельности/реиспользования/рефакторинга в больших проектах, не говоря уже о проблемах в наборе - опечатки, отсутствие контроля, проблемы применения всплывающих подсказок! А обилие кавычек всё только усугубляет!
Я не говорил об отделении микроархитектуры от архитектуры. Я говорил о том, что для будущего софта всё это будет не так уж важно как сейчас. Задачи программирования под специфическую архитектуру никуда не денутся - но это не будут мейнстримовые задачи. Большинство разработчиков будут разрабатывать универсальный кроссплатформенный софт. И языки программирования будут развиваться в сторону усиления кроссплатформенности и отстранённости от аппаратных особенностей. В идеале - в сторону логической декларативности, когда нужно 80% думать о логике алгоритма, 10-15% об особенностях его выполнения в тех или иных условиях (не связанных с архитектурой, но связанных с верхней (ближайшей) платформой среды выполнения алгоритма) и обрабатываемых данных, около 2% думать об особенностях параллелизма и согласованности, и лишь менее 2% об особенностях его выполнения на той или иной архитектуре - зачастую сводя это просто к тому, что платформы могут быть разные и нужно применять общую универсальную кроссплатформенную методологию построения алгоритма, которая автоматически учтёт все нюансы. При этом AI-Ассистент разработчика и AI-компилятор/оптимизатор сгладят все нюансы. А финальная компиляция в машинные инструкции будет идти уже под конкретную платформу бэкенд-компилятором (скорее всего в момент инсталляции приложения, или первого запуска на целевом клиенте), или вообще будет более популярна схема выполнения программ на виртуальной машине с JIT компиляцией на лету (либо сразу по потребности исполнения как, например, в .NET либо отложено - по мере потребности в производительности, как, например в Java или в JS).
Важным вопросом останется только поддержка архитектуры средой выполнения. Поэтому сейчас на всех не CISC архитектурах так распространён Linux - его ядро открытое, его "не так уж сложно" перекомпилировать под новую платформу - нужно только создать базовые драйверы и провести некоторую оптимизацию. А вся отельная программная надстройка ОС Linux над ядром Linux обычно не требует сложных доработок (только если что-то поменялось в ядре) - нужно только перекомпилировать под целевую платформу.
Но в мире ещё очень популярны ОС на другом ядре - как Windows и MacOS (и ещё iOS; а Android базируется на ядре Linux; в MacOS же было ядро Unix - но сейчас его уже почти полностью выпилили - можно уже не брать в расчёт; да и Android лет через 10-20 отправят на пенсию - взамен придёт Google Fuchsia - а там уже нет ядра Linux). Пока под разные архитектуры не переведут ОС - писать под них кроссплатформенный софт бессмысленно. Linux то будет. Но - много ли обывателей используют Linux.
Но тут, всё-таки, всё дело в кроссплатформенном софте - когда его в мейнстриме станет больше 60% - то и потребителей ОС Linux станет больше - а там и потребители разных платформ расширятся. Но это пока лишь моё мнение. Как он будет на самом деле не знаю - до этих времён ещё пройдёт полвека!
Выбор архитектуры платформы конечно важен. Но... всё-же тенденция к середине века будет ориентирована на кросплатформенность софта. То есть - ориентированность на архитектуру процессора будет в большей степени важна только разработчикам драйверов и ядра платформ (от ОС до низкоруровневых фреймворков). Всё что выше уровня оборудования, уже почти не должно зависить от архитектуры к середине XXI века (за редким исключением). Даже компиляторы в машинные коды уже принято делить на двухэтапную фронтэнд и бакэнд компиляцию. А при разработке ординарного софта - фреймворки библиотек будут реализовывать поддержку кроссплатформенной разработки под разные платформы - и в редких случаях потребности ориентации на архитектур (и вообще всю платформу экосистемы среды исполнения) программистам не составит большого труда реализовать разные версии алгоритмов, скажем, встраивая разную оптимизацию под разные платформы.
Так что, если этот тренд сохраниться, то к середине XXI века вполне себе могут существовать сразу несколько аппаратных архитектур. А программы буду поддерживать целую кучу софтверных платформ. Да и сами платформы будут стараться поддерживать экосистему разных (в том числе конкурирующих) платформ - как сейчас, например, будет делать Windows 11 c Linux (и отчасти делает Linux c Wine и интеграции в AD).
Но на доведение этой тенденции до ума ещё скорее всего потребуются десятилетия.
А там, того глядишь, изменится и всё прикладное программирование - придут языки программирования 5-го поколения, которые вообще будут индифферентны к платформе, и буду скорее декларативно ориентированными на логику алгоритма, а не на детали его машинного исполнения - будет применяться многоэтапная AI компиляция с оптимизацией - под любую платформу - главное подключить соответствующие модули к компилятору и к библиотеке фреймворка. Даже создание драйверов и ядра платформ может в итоге перейти на эту модель (хотя это, конечно, для них сложнее); но как-минимум применение двухэтапной компиляции и поддержки особых кроссплатформенных фишек (а-ля как развивается, к примеру, Kotlin-Native) для исходного ЯП существенно упростит создание низкоуровневого софта и бакэнд-компиляторов для разных платформ.
Возможно Вы правы. Просто хотелось иметь более короткий и абстрактный термин (читай — универсальный). А ещё отталкивался от слова «done» — как от антонима — команды, зарабатываемой в конце после успешного выполнения блока потоков инструкций (его успешность определяется по-разному, как уже было показано выше — всё зависит от применённых команд при инициализации блока). Но тогда есть ещё такая пара successful / unsuccessful — возможно это оптимальный вариант, но попытка сократить их написание что-то не особенно благозвучная получилась succ / unscucc — хотя тут «cc» на конце, а не «ck» :-|
Придумывая новый высокодекоративный императивно-функциональный язык 5-го поколения, основанный на потоках (связанных цепочках) инструкций, обрабатывающих потоки (последовательности) данных. Я недавно искал альтернативу инструкции else (так как классический блок if else резервировал для непрерывного блока последовательных инструкций) — мне нужно было что-то близкое к блоку «defualt» языковой конструкции близкой к switch в С++ и C# — но ключевое слово defualt не нравилось (хотя по смыслу как раз очень подходило — но так же зарезервировал его для других целей). Вот в Kotlin и в C# (switch как выражение; Nemerle Match, Scala Match) используют "_" как вариант по умолчанию-иначе — мне нравился этот вариант когда-то, а сейчас разонравился (потому что у меня это условно библиотечная Команда, а не оператор или иной предопределённый синтаксический лексем языка)…
пока я остановился на слове «Undone», вот теперь нашёл ещё оду альтернативу «else»- «otherwise» (ключевое слво «if» — у меня заменилося на команду «Filter»:
val res =
(val elm < — Data) -> Multitask ->
| Filter(cond1) -> Proccess1
| Filter(cond2) -> Proccess2
| Otherwise -> ProcessNothing
(да ноги тут отчасти растут из ЯП Ocaml)
Здесь каждая строчка — это отдельный поток инструкций (условно в одной инструкции Process..) обработки данных из потока Data. В ячейку «res» будет помещён результат в приоритете первого потока — если он его вернёт, второго если он его вернёт — или последнего в ином любом случае. По логике это близко к паттерн-метчингу — так как каждый поток начинается с проверки условия — если условие не отработало — то поток ничего не вернёт. А кманда Multitask делает (разрешает но не обязует) обработку поток ещё и асинхронной — поэтому потоки могут выполниться в разное время не в порядке очерёдности написания — но результат будет выбран в порядке очерёдности написания (для другой очерёдности нужно отдельно её задавать специальными командами). И если более ранний поток вернул не пустой результат, отельные не выполняются или приостанавливаются.
А вот если нужен был бы любой — первый кто вернёт результат — то инструкция была бы такой
val res =
(val elm < — Data) -> Multitask -> Any ->
| Filter(cond1) -> Proccess1
| Filter(cond2) -> Proccess2
| Otherwise -> ProcessNothing
Но тут Otherwise — будет осабняком — т.к. любым он быть не может по логике — это результат только если остальные не вернули его.
А если нужно строго последовательное вырполнение всех инструкций то так
val res =
(val elm < — Data) -> Multitask ->
, Filter(cond1) -> Proccess1
, Filter(cond2) -> Proccess2
, Otherwise -> ProcessNothing
И даже тут есть секция иначе — она тоже контролирует результат — например она сработает коллекция Data будет пустой — и ни одна строчка не отработает — или не сработает ни одно условие в строке (а тут оно есть, но его может и не быть).
Вот такая вот у меня логика.
Хотя слово «Undone» тоже хорошее
Data ->
| ProccessElement(it)
| Undone -> ProcessNothing()
Это простой цикл перебора элементов из «Data» с обработкой «ProccessElement» в — но если «Data» будет пустым — то сработает «ProcessNothing».
Конечно тут логичнее применить команду «Empty» (и она должна быть у Потоков данных — в этом прелесть команд на уровне Библиотек — их можно вводить сколько угодно любых и разных в для разных целевых объектов), но по сути она просто ссылается на более универсальную команду «Undone» или «Otherwise» — но… любую из них можно макро-переопределить для другого объекта — не переопределяя их все — и тем самым назначить ей другую логику макро-обработки при компиляции или при исполнении! Хотя так (по рознь), конечно с алиасами команд делать не стоит
Это к подделки не относится — вас просто не пустят и всё. Это как нарисовать на куске пластика изображение карты Тройка — приложить его к турникету в метро и получить отворот-поворот! Но вот продажа такого пластика — это уде тяготеет к мошенничеству — если будете продавать его именно как настоящую карту Тройка. Но как пластик с картинкой — продать можете — это не документ строгой отчётности. То же и с QR кодами — если покупатель знает, что покупает поддельный QR код — то это не мошенничество — и это не документ, а просто ссылка на сайт в Интенете — что хочу, то и покупаю — это с одной стороны. В ресторанах до сих пор нет реальной надёжной проверки QR-кодов — видимо они смотрят на это сквозь пальцы — так как им это нафиг не надо — им нужны клиенты — деньги не пахнут. Вот с поддельными сайтами бороться будут — так как это фишинговая хакерская атака — и владельца сайта можно было бы судить — если определят. Попытка пройти в ресторан по фальшивому QR коду — как уже сказал ресторанам не до поиска таких ловкачей — но на предмет боязни проверки — если выявят, то не пустят и пригрозят вызвать милицию. А вот если милиция сама устроит облаву — то… ну не надо им показывать фальшивый QR-код — проще зайти за не имеющего таковой и сослаться на ресторан — что они мол и так пустили за стол — у тех же нет доказательства — тут даже видеонаблюдение не поможет!
Настоящая наука в России (да и в США, и в Китае) — это побочный продукт науки улучшения циркового — за цирконами находятся и инвесторы и главные заинтересованные лица, дающие учёным поизобретать в нужных направления — авось новая модификация циркона получится.
В других странах настоящей науки (если они не на США работают) — то и нет вовсе. Ну разве что в Японии что-то проскакивает…
Интересно как они проверяют на фальшивы QR коды так чтобы уголовное дело заводить — ресторанам до этого дела нет. Тогда так что-ли — заваливается отряд полиции в ресторан и кричит «QR-контроль! Всем выйти из сумрака и показать свои манту QR коды!» — и бедные чавкающие посетители с полной потерей аппетита выстраиваются в очередь на экспертизу QR кодов!
ВОт вот — туфта это а не QR код.
Вот если бы QR код был настоящим — т.е. как за реально сделанную прививку (где дозу просто слили на сторону по спекулятивной цене), с полным занесением в дело — вот это была вы вещь… вот только на это не многие пойдут — можно нарваться на контрольную закупку — а там уже раскрутят вплоть до медучреждения и медработника, который якобы сделал фиктивную прививку. Хотя… сейчас мест где делают привики «пруд пруди» — затеряться наверное легко!
Я в России живу и в России покупаю. С русской раскладкой — чтобы не заказывать отдельно лазерную гравировку. И на ноутбуке так уже проблему не решить. Да и не столько в размере Enter проблема в клавах — сколько в других обозначенных проблемах расположения и размера других клавиш
Сделайте лучше более корректную работу с окончаниями. Русский язык (как и некоторые ещё) очень зависит от окончаний — их много, а набирать слова зачастую удобнее не до конца, а выбирая готовое слово из быстрого набора — вот только окончания хромают. Хорошо бы иметь как автокоррекцию (по лексическому анализу набранной фразы), так ручной вариант — быстрого выбора нужного окончания — для этого на клавиатуре можно даже отдельную кнопку размесить — для выбора и замены окончания текущего слова.
Этого нет в западных мобильных клавиатурах — так как у них попросту нет там такой проблемы
Не получилось дополнить мой коммент — пишу тут:
Забавно, что с урезанным Enter'ом клава там же стоит всего $58 ebay
А ну да — это же барахолка — там б/у торгуют
Кстати, пишу сейчаса на такой клавиатуре и в принципе доволен — но она не эргономичная, конечно, зато к клавишам почти нет претензий (разве что фунциоанльные клавищи урезаны и слишком близко друг к другу расположены, но разбиты на группы и отделены от горизонтального блока цифр большим расстоянием; ну и мультимедиа блока отдельного нет — но тут не пользуюсь им)
Logitech K280e Фото
Белая тоже бывает Фото
Есть версия и с урезанным Enter'ом — но её не рассматриваю.
Хорошая клава, и стоит копейки — русские буквы бы ещё красными выделить — но это вообще сейчас уже нереально, почему-то стало
Какой-то парад уродцев. Не потому что они эргономичные такие — изогнутые, разделяемые. А потому они как раз неэргономичные — из-за неудобного расположения клавиш друг относительно друга. Enter- урезанный везде. Стрелочки слишком близко к соседним клавишам, функциональные клавиши слишком маленькие и слишком близко к другим клавишам расположены, клавиши Delet, End Home, Insert тоже расположены кое-как. В большинстве случаев цифровой блок просто отсутствует (но это кому как больше нравится, у меня дома выносной и да — почти не использую из-за этого хотя вспоминаю о нём часто — но просто нет места на столе). Мультимедиа клавши тоже неудачные или отсутствуют (хотя вот это тоже кому как больше нравится — у меня дома это отдельный блок совершенной иной формы — очень удобно управлять плеером на компьютере, особенно когда не сидишь за клавиатурой, а просто по быстрому подошёл к столу).
Из представленных клавиатур я бы выдели следующие (в порядке убывания удобства на мой взгляд):
1. Logitech ERGO K860
Но не та, что представлена тут, а другая версия — с полноразмерным Enter'ом
картинка тут
На мой вкус самая сбалансированная эргономика — подкачали только функциональные клавиши, и доп значки, вместо подписей на клавишах. Клавиши стрелочек хотелось бы чуть дальше отодвинуть от соседних по бокам. Мультимедиа клавиши увы не вынесены в отдельный блок.
Замечу, что «Microsoft Surface Ergonomic Keyboard» тоже могла бы быть неплохой клавой, но у неё нет модификации с полноценным Enter'ом — а остальные недостатки такие же как у K860. А, ну и серо белый цвет — это ужасно — читаемость на нём клавиш просто отвратительная — клавиатура явно рассчитана на 100% слепой набор!
2. Microsoft Sculpt
Нравится выносной цифровой блок и полноразмерный Enter, мышка тоже хорошая. Функциональные клавиши пострадали. Стрелочки вплотную к соседним клавишам (вот на ноутбуке у меня так — задолбало — постоянно задеваю соседние клавиши, а использую уже 5 лет). Левый шифт уж очень зажали в размере. Но форма интересная. Но больше всего напрягают именно стрелки
Клавиатура «Microsoft Natural Ergonomic 4000 (B2M-00001)» тоже хорошая клава, если найдёте её с полноразмерной клавишей Enter фото, но такой клавы там нет
А… вот тут есть фото ebay
Надо бы себе такую прибрести ($265) — не нравится только длинный ход клавишь (но это кому как) — я люблю короткий, мягкий и тихий. Но большинству должна понравится именно такая клава — она почти идеальна!
3. Kinesis Advantage2
Самая странная клавиатура. Эргономика так и прёт — не переборщили? Любопытно было бы попробовать. И мне кажется для игр она даже лучше подойдёт, чем для кодинга или набора текста. Но привыкать долго нужно будет, уж очень своеобразная форма и другая расстановка ряда клавиш — поэтому без использования трудно сказать как оно будет. Но клавиши Delete и Enter справа я бы точно поменял местами. И слева Delete мне кажется лишним, а кнопки Home, End я бы перенёс в правую часть (хотя может и так ничего — надо пробовать как оно будет в таких комбинация, например как Ctrl+End, Ctrl+Shift+End, Сtrl+Shift, Alt+Shift, Ctrl+Alt+Delete, Ctrl+Alt+Insert и т.п. (кстати Insert как-то очень странно и неудобно расположен слева), а так же всяких вариаций клавиш управления и функциональных клавиш, как Ctrl+F2, Ctrl+F9 например или Alt+1, Alt+8, Shift+2, Shift+0). Боюсь не очень удобно — странно что разработчики в США полюбили эту клаву. Про русскую раскладку вообще молчу — кажется клава для неё вообще не предназначена (не потому что на ней нет русских букв — это решаемо, а потому что расположение клавиш для них очень специфическое). Мультимедиа клавиш тоже считай почти нет. Цифрового блока нет — если нужен, то необходимо покупать отдельный.
Вообще — я отдаю предпочтения клавиатурам от Logitech — у них полно шлака, но среди него есть очень достойные образцы — жаль, что самые лучшие из них уже не выпускаются :-(
Комменты это хорошо. Но оценку я дал содержанию статьи.
Методы обхода хороши в комплекте — вероятность того или иного уничтожения вотермарка уже с 3-4 эккаунтах + дополнительные инструменты цифровой обработки — почти 100% результат! Дилетанты этим не занимаются — у профессионалов всё есть!
Хм.... всё не то - я то думал в статье будет написано как создавать высокопроизводительный код, выполняемый на стороне сервера Tarantool в основном потоке сервера - т.е. рядом с данными. А тут... просто примеры использования готовых сторонних клиентов на двух языках, использующие готовые черные ящики - коннекторы из библиотек, специально созданных для этих языков. Причём такие - что промежуточный сервер им вообще не особо то и нужен - можно было бы прямо из фронт-енда к Taratool'у обращаться (оставим в стороне - что такая работа не совсем кошерно - ведь Tarantool позиционируется и как сервер приложений).
Да и в самом примере работы с Tarantool не показано ничего особенного - с чем бы не менее эффективно не справится любая другая конкурирующая СУБД (а Tarantool конкурирует с разными типами СУБД).
Код на Golang (мне - не сторонниre Golang) кажется уродским чрезмерно перегруженным. Нет никакого синтаксического сахара - поэтому в XXI веке это выглядит печально!
Код на Paython (как по мне - более симпатичном ЯП, чем Golang, но не идеальном языке) выглядит несколько лучше, но в нём потеряна вся примитивная обработка ошибок.
Жаль автор не привёл и native-вариант для Tarantool - созданный на языке Lua - он бы смотрелся куда лучше (мнение матёрого программиста, почти не создававшего скриптов на Lua) - а код на Lua что-то среднее между Golang, Python и JS
Заодно можно было бы показать производительность разных решений, и преимущество размещение таких функций прямо на сервере Tararantool.
Формат обращения к API Tarantool в исполосованных коннекторах мне тоже показался перегруженным и корявым - текстовые строки в ЯП это одновременно и мощь универсальности и головная боль, и снижение читабельности/реиспользования/рефакторинга в больших проектах, не говоря уже о проблемах в наборе - опечатки, отсутствие контроля, проблемы применения всплывающих подсказок! А обилие кавычек всё только усугубляет!
В общем не впечатлило.
И да ++++++ чтобы Чёрт не спутал моё виденье!
Я не говорил об отделении микроархитектуры от архитектуры. Я говорил о том, что для будущего софта всё это будет не так уж важно как сейчас. Задачи программирования под специфическую архитектуру никуда не денутся - но это не будут мейнстримовые задачи. Большинство разработчиков будут разрабатывать универсальный кроссплатформенный софт. И языки программирования будут развиваться в сторону усиления кроссплатформенности и отстранённости от аппаратных особенностей. В идеале - в сторону логической декларативности, когда нужно 80% думать о логике алгоритма, 10-15% об особенностях его выполнения в тех или иных условиях (не связанных с архитектурой, но связанных с верхней (ближайшей) платформой среды выполнения алгоритма) и обрабатываемых данных, около 2% думать об особенностях параллелизма и согласованности, и лишь менее 2% об особенностях его выполнения на той или иной архитектуре - зачастую сводя это просто к тому, что платформы могут быть разные и нужно применять общую универсальную кроссплатформенную методологию построения алгоритма, которая автоматически учтёт все нюансы. При этом AI-Ассистент разработчика и AI-компилятор/оптимизатор сгладят все нюансы. А финальная компиляция в машинные инструкции будет идти уже под конкретную платформу бэкенд-компилятором (скорее всего в момент инсталляции приложения, или первого запуска на целевом клиенте), или вообще будет более популярна схема выполнения программ на виртуальной машине с JIT компиляцией на лету (либо сразу по потребности исполнения как, например, в .NET либо отложено - по мере потребности в производительности, как, например в Java или в JS).
Важным вопросом останется только поддержка архитектуры средой выполнения. Поэтому сейчас на всех не CISC архитектурах так распространён Linux - его ядро открытое, его "не так уж сложно" перекомпилировать под новую платформу - нужно только создать базовые драйверы и провести некоторую оптимизацию. А вся отельная программная надстройка ОС Linux над ядром Linux обычно не требует сложных доработок (только если что-то поменялось в ядре) - нужно только перекомпилировать под целевую платформу.
Но в мире ещё очень популярны ОС на другом ядре - как Windows и MacOS (и ещё iOS; а Android базируется на ядре Linux; в MacOS же было ядро Unix - но сейчас его уже почти полностью выпилили - можно уже не брать в расчёт; да и Android лет через 10-20 отправят на пенсию - взамен придёт Google Fuchsia - а там уже нет ядра Linux). Пока под разные архитектуры не переведут ОС - писать под них кроссплатформенный софт бессмысленно. Linux то будет. Но - много ли обывателей используют Linux.
Но тут, всё-таки, всё дело в кроссплатформенном софте - когда его в мейнстриме станет больше 60% - то и потребителей ОС Linux станет больше - а там и потребители разных платформ расширятся. Но это пока лишь моё мнение. Как он будет на самом деле не знаю - до этих времён ещё пройдёт полвека!
Выбор архитектуры платформы конечно важен. Но... всё-же тенденция к середине века будет ориентирована на кросплатформенность софта. То есть - ориентированность на архитектуру процессора будет в большей степени важна только разработчикам драйверов и ядра платформ (от ОС до низкоруровневых фреймворков). Всё что выше уровня оборудования, уже почти не должно зависить от архитектуры к середине XXI века (за редким исключением). Даже компиляторы в машинные коды уже принято делить на двухэтапную фронтэнд и бакэнд компиляцию. А при разработке ординарного софта - фреймворки библиотек будут реализовывать поддержку кроссплатформенной разработки под разные платформы - и в редких случаях потребности ориентации на архитектур (и вообще всю платформу экосистемы среды исполнения) программистам не составит большого труда реализовать разные версии алгоритмов, скажем, встраивая разную оптимизацию под разные платформы.
Так что, если этот тренд сохраниться, то к середине XXI века вполне себе могут существовать сразу несколько аппаратных архитектур. А программы буду поддерживать целую кучу софтверных платформ. Да и сами платформы будут стараться поддерживать экосистему разных (в том числе конкурирующих) платформ - как сейчас, например, будет делать Windows 11 c Linux (и отчасти делает Linux c Wine и интеграции в AD).
Но на доведение этой тенденции до ума ещё скорее всего потребуются десятилетия.
А там, того глядишь, изменится и всё прикладное программирование - придут языки программирования 5-го поколения, которые вообще будут индифферентны к платформе, и буду скорее декларативно ориентированными на логику алгоритма, а не на детали его машинного исполнения - будет применяться многоэтапная AI компиляция с оптимизацией - под любую платформу - главное подключить соответствующие модули к компилятору и к библиотеке фреймворка. Даже создание драйверов и ядра платформ может в итоге перейти на эту модель (хотя это, конечно, для них сложнее); но как-минимум применение двухэтапной компиляции и поддержки особых кроссплатформенных фишек (а-ля как развивается, к примеру, Kotlin-Native) для исходного ЯП существенно упростит создание низкоуровневого софта и бакэнд-компиляторов для разных платформ.
Таково моё мнение
пока я остановился на слове «Undone», вот теперь нашёл ещё оду альтернативу «else»- «otherwise» (ключевое слво «if» — у меня заменилося на команду «Filter»:
val res =
(val elm < — Data) -> Multitask ->
| Filter(cond1) -> Proccess1
| Filter(cond2) -> Proccess2
| Otherwise -> ProcessNothing
(да ноги тут отчасти растут из ЯП Ocaml)
Здесь каждая строчка — это отдельный поток инструкций (условно в одной инструкции Process..) обработки данных из потока Data. В ячейку «res» будет помещён результат в приоритете первого потока — если он его вернёт, второго если он его вернёт — или последнего в ином любом случае. По логике это близко к паттерн-метчингу — так как каждый поток начинается с проверки условия — если условие не отработало — то поток ничего не вернёт. А кманда Multitask делает (разрешает но не обязует) обработку поток ещё и асинхронной — поэтому потоки могут выполниться в разное время не в порядке очерёдности написания — но результат будет выбран в порядке очерёдности написания (для другой очерёдности нужно отдельно её задавать специальными командами). И если более ранний поток вернул не пустой результат, отельные не выполняются или приостанавливаются.
А вот если нужен был бы любой — первый кто вернёт результат — то инструкция была бы такой
val res =
(val elm < — Data) -> Multitask -> Any ->
| Filter(cond1) -> Proccess1
| Filter(cond2) -> Proccess2
| Otherwise -> ProcessNothing
Но тут Otherwise — будет осабняком — т.к. любым он быть не может по логике — это результат только если остальные не вернули его.
А если нужно строго последовательное вырполнение всех инструкций то так
val res =
(val elm < — Data) -> Multitask ->
, Filter(cond1) -> Proccess1
, Filter(cond2) -> Proccess2
, Otherwise -> ProcessNothing
И даже тут есть секция иначе — она тоже контролирует результат — например она сработает коллекция Data будет пустой — и ни одна строчка не отработает — или не сработает ни одно условие в строке (а тут оно есть, но его может и не быть).
Вот такая вот у меня логика.
Хотя слово «Undone» тоже хорошее
Data ->
| ProccessElement(it)
| Undone -> ProcessNothing()
Это простой цикл перебора элементов из «Data» с обработкой «ProccessElement» в — но если «Data» будет пустым — то сработает «ProcessNothing».
Конечно тут логичнее применить команду «Empty» (и она должна быть у Потоков данных — в этом прелесть команд на уровне Библиотек — их можно вводить сколько угодно любых и разных в для разных целевых объектов), но по сути она просто ссылается на более универсальную команду «Undone» или «Otherwise» — но… любую из них можно макро-переопределить для другого объекта — не переопределяя их все — и тем самым назначить ей другую логику макро-обработки при компиляции или при исполнении! Хотя так (по рознь), конечно с алиасами команд делать не стоит
В других странах настоящей науки (если они не на США работают) — то и нет вовсе. Ну разве что в Японии что-то проскакивает…
мантуQR коды!» — и бедные чавкающие посетители с полной потерей аппетита выстраиваются в очередь на экспертизу QR кодов!Вот если бы QR код был настоящим — т.е. как за реально сделанную прививку (где дозу просто слили на сторону по спекулятивной цене), с полным занесением в дело — вот это была вы вещь… вот только на это не многие пойдут — можно нарваться на контрольную закупку — а там уже раскрутят вплоть до медучреждения и медработника, который якобы сделал фиктивную прививку. Хотя… сейчас мест где делают привики «пруд пруди» — затеряться наверное легко!
вот тут обзор на хабре
И что за кнопка над кнопкой Del?
Большой Enter как A4tech считаю всё-таки уже перебором
Этого нет в западных мобильных клавиатурах — так как у них попросту нет там такой проблемы
Забавно, что с урезанным Enter'ом клава там же стоит всего $58
ebay
А ну да — это же барахолка — там б/у торгуют
Кстати, пишу сейчаса на такой клавиатуре и в принципе доволен — но она не эргономичная, конечно, зато к клавишам почти нет претензий (разве что фунциоанльные клавищи урезаны и слишком близко друг к другу расположены, но разбиты на группы и отделены от горизонтального блока цифр большим расстоянием; ну и мультимедиа блока отдельного нет — но тут не пользуюсь им)
Logitech K280e
Фото
Белая тоже бывает
Фото
Есть версия и с урезанным Enter'ом — но её не рассматриваю.
Хорошая клава, и стоит копейки — русские буквы бы ещё красными выделить — но это вообще сейчас уже нереально, почему-то стало
Из представленных клавиатур я бы выдели следующие (в порядке убывания удобства на мой взгляд):
1. Logitech ERGO K860
Но не та, что представлена тут, а другая версия — с полноразмерным Enter'ом
картинка тут
На мой вкус самая сбалансированная эргономика — подкачали только функциональные клавиши, и доп значки, вместо подписей на клавишах. Клавиши стрелочек хотелось бы чуть дальше отодвинуть от соседних по бокам. Мультимедиа клавиши увы не вынесены в отдельный блок.
Замечу, что «Microsoft Surface Ergonomic Keyboard» тоже могла бы быть неплохой клавой, но у неё нет модификации с полноценным Enter'ом — а остальные недостатки такие же как у K860. А, ну и серо белый цвет — это ужасно — читаемость на нём клавиш просто отвратительная — клавиатура явно рассчитана на 100% слепой набор!
2. Microsoft Sculpt
Нравится выносной цифровой блок и полноразмерный Enter, мышка тоже хорошая. Функциональные клавиши пострадали. Стрелочки вплотную к соседним клавишам (вот на ноутбуке у меня так — задолбало — постоянно задеваю соседние клавиши, а использую уже 5 лет). Левый шифт уж очень зажали в размере. Но форма интересная. Но больше всего напрягают именно стрелки
Клавиатура «Microsoft Natural Ergonomic 4000 (B2M-00001)» тоже хорошая клава, если найдёте её с полноразмерной клавишей Enter
фото, но такой клавы там нет
А… вот тут есть
фото
ebay
Надо бы себе такую прибрести ($265) — не нравится только длинный ход клавишь (но это кому как) — я люблю короткий, мягкий и тихий. Но большинству должна понравится именно такая клава — она почти идеальна!
3. Kinesis Advantage2
Самая странная клавиатура. Эргономика так и прёт — не переборщили? Любопытно было бы попробовать. И мне кажется для игр она даже лучше подойдёт, чем для кодинга или набора текста. Но привыкать долго нужно будет, уж очень своеобразная форма и другая расстановка ряда клавиш — поэтому без использования трудно сказать как оно будет. Но клавиши Delete и Enter справа я бы точно поменял местами. И слева Delete мне кажется лишним, а кнопки Home, End я бы перенёс в правую часть (хотя может и так ничего — надо пробовать как оно будет в таких комбинация, например как Ctrl+End, Ctrl+Shift+End, Сtrl+Shift, Alt+Shift, Ctrl+Alt+Delete, Ctrl+Alt+Insert и т.п. (кстати Insert как-то очень странно и неудобно расположен слева), а так же всяких вариаций клавиш управления и функциональных клавиш, как Ctrl+F2, Ctrl+F9 например или Alt+1, Alt+8, Shift+2, Shift+0). Боюсь не очень удобно — странно что разработчики в США полюбили эту клаву. Про русскую раскладку вообще молчу — кажется клава для неё вообще не предназначена (не потому что на ней нет русских букв — это решаемо, а потому что расположение клавиш для них очень специфическое). Мультимедиа клавиш тоже считай почти нет. Цифрового блока нет — если нужен, то необходимо покупать отдельный.
Вообще — я отдаю предпочтения клавиатурам от Logitech — у них полно шлака, но среди него есть очень достойные образцы — жаль, что самые лучшие из них уже не выпускаются :-(
Методы обхода хороши в комплекте — вероятность того или иного уничтожения вотермарка уже с 3-4 эккаунтах + дополнительные инструменты цифровой обработки — почти 100% результат! Дилетанты этим не занимаются — у профессионалов всё есть!