Я лишь говорил о розетке - которую можно было бы унифицировать условно "электрически", поставив преобразователь микросхему.
Ещё хочу всё-таки уточнить свою мысль - что для серверного оборудования менять SFP на USB-C сейчас пока действительно не лучшая затея - говоря выше об унификации сетевых портов я всё-таки имел в виду переход на новый универсальный порт - уже наверняка оптический (и не сейчас - а в будущем), когда медных коммуникативных возможностей будет не достаточно не только серверам, но уже и клиентам. И я говорил о модели расширяемого порта - построенного по единым правилам, но имеющего конструктивные возможности разной реализации (при, в целом, общей совместимости) иметь разную пропускную способность (за разную стоимость) - главное, чтобы порты, кабели и контроллеры это поддерживали - а при недостаточной поддержке - чтобы всё тоже работало, но уже, естественно, медленнее - получаем гибкость масштабирования.
Но для клиентского оборудования - думаю уже лет через 10-20 вполне можно было бы отказаться от RJ45 в пользу USB розетки (сохраняя витую пару как способ связи розеток между собой), и клиентское сетевое оборудование тогда модно на USB-C переводить. Заодно и PoE в стандарт сразу добавить (для USB-C это уже будет Power Delivery). Ну а потом, потихоньку заменять витую пару на оптику - при сохранении стандарта на сами розетки - USB-C формата - что упростит переход на оптические линии - ведь возможности медной витой пары уже на пределе - сейчас это 10GB - ну, вероятно, 100GB ещё выжмут (на расстояниях до 25-50 метров) - а дальше уже слишком большие наводки и затухания сигнала - но не думаю что 100GB медные сети вообще придут в сектор SOHO - так что лет через 30 чаще всего (где нужны высокие скорости, даже в домах) начнут уже тянуть оптику.
Такая унификация очень благотворно скажется на упрощении подключении устройств для передачи информации. Это удобно и для обычного пользовательского оборудования, и для серверного и для сетей IoT устройств.
Правда тут ещё будет расти конкуренция с беспроводными технологиями. Power Delivery по кабелю, большая секюрность и более высокая стабильность проводного канала - это весомые доводы за кабельные сети.
Дом будущего - где 90% всех розеток унифицированные (пусть условно UBS-C хотя это может быть и новый формат) как и 98% всех портов для передачи данных между устройствами тоже унифицированы - это очень красивая идея! Но пока это лишь мечта, такой тренда ещё не начался
Это была шутка. Я хотел лишь показать, что есть простая физика движения мяча по заданной траектории, по законам Ньютона для идеального точечного тела. Но на практике есть много других факторов, которые напрямую уже не так просто встраиваются в Ньютоновскую механику - закрученный мяч, например - это состояние уже точечной частицы, условно - её спин - и вот в квантовой механике эти свойства точечной частицы уже учитываются более строго - но проблема в том, что там это уже не детерминированная модель - и никогда нет чёткого 100% ответа о состоянии системы в следующий момент времени - есть только вероятности этого состояния - они описываются формулами и подтверждаются экспериментами (сериями экспериментов, ведь в теории вероятности один эксперимент ничего не значит)
Во-первых - я говорил о наличии не нулевой вероятности прохода сквозь стенку условного бильярдного шара.
Во-вторых, электроны как раз плохо подчиняются законам Ньютона - электрон будет двигаться иначе, чем в простых уравнения Ньютона
Плохо потому, что реально ньютоновская механика, построенная на силе тяготения конечно работает, но в квантовом мире она это делает с большим числом ошибок, потому что её эффект тут играет уже незначительную роль, куда сильнее на электрон будут влиять законы электромагнетизма - но и они не дадут 100% описание поведения - поэтому и есть законы квантовой механики - вот они близки к 100% но и они пока не могут всё описать с максимальной точностью, хотя в целом вероятностная картина получается верная, но в том то и дело, что она вероятностная - нет уже чёткого определения скоростей и положений - поэтому и возникли всякие ещё более глубокие теории - типа теории струн или M-теории - в попытке дать математическое объяснения почему электрон будет вести себя именно с такими вероятностями, которые определяет квантовая физика. Возможно дальнейшее изучение законов субквантового мира позволят вообще избавиться от вероятностей - и мы придём к полностью детерминированной модели , но тогда, вероятно мир окажется дискретным. Но это уже только гипотезы - дальше расплывчатых (но работающих) законов квантовой теории наука пока не продвинулась так чтобы теория 100% согласовывалась с экспериментами (которые на таком уровне пока и проводить то почти невозможно - не достаточный уровень технологий)
Но для замены скажем RJ-45 с сохранением надёжности и возможности простой обжимки коннекторов придётся хорошенько потрудиться
Что Вы там обжимать собрались? Тут просто дело в розетках - вывести такие розетки , где на входе обжимается витая пара, а на выходе (после микросхемы преобразователя) идёт уже USB-C. Ну и коммуникационное оборудование просто на USB протокол и порт переводить потихоньку
Оконечивать оптику без изрядно подешевевшей но всё ещё дорогой техники можно только мечтать
Ну, говорят, дешеветь будет (технологии производства не стоят на месте), а спрос на оптику будет расти всё больше и больше - тут всё зависит насколько ещё хватит меди для обеспечения возрастающего спроса на скорости
Ей бы ещё научиться запитывать непосредственно лазером хотя бы малопотребляющие устройства — PoO.
С этим пока всё сложнее. Но может быть, может быть!
Шары не электроны - чем крупнее объект тем меньше он подвержен квантовым законам (как объект в целом). В принципе согласно квантовой теории шары тоже могут разлететься в разные стороны - а один или оба ещё и сквозь стенку пройти после столкновения - просто чем крупнее объект - тем ниже вероятность этого события - для электронов это высокая вероятность, но их размер ничтожно мал, по сравнению, скажем, биллиардным шаром - в котором этих электронов тьма тьмущая (и не только электронов) - и чтобы шары повели себя по законам квантовой механике (а не по Ньютоновским) нужно чтобы условно каждая частица атома вероятностно повела себя согласовано с другими частями для движения в ином направлении - вот (условно говоря) перемножив такие вероятности каждой частицы - получим вероятность такого события для шаров - она будет ничтожно мала, но не исключена.
Вон в футболе голы Роберта Карлоса, особенно гол по спирали в ворота Франции в 1997 году, легко так "нарушают" все мыслимые обывательские законы физики
Куда Вы там втыкать type C вилку решили я так и не понял.
Конечно проблема электророзеток она больше свойственна для мира в целом, чем для Европы. А Британия - ну она уже не в Евросоюзе и всем там на Англию уже пофиг!
С другой стороны - сейчас потихоньку уже началась мода создания USB розеток без адаптера. Сначала появились БП на компьютерах с такими портами. Потом появились электроудлинители где были как электророзетки так и USB (тогда ещё USB-A, сейчас уж есть и с USB-C) - потом и стеноразмещаемые розетки стали появляться с портами USB-C (и USB-A). Про автомобили понятно что там уже тоже давно размещают такие розетки.
Вон уже в метро и прочем общественном транспорте, включая остановки UBS розетки есть - сначала появились USB-A, потом добавили и USB-C
Но я пока не понимаю этого тренда (ну кроме транспорта) - сейчас электроадаптеры развиваются очень быстро - мощности растут - телефоны стремятся заряжаться меньше чем за полчаса 0% до 100% - поэтому всё время появляются новые адаптеры - и стандарты зарядки. Но сменить устаревший адаптер наверное проще - чем менять устаревшую USB розетку - хотя может я просто мыслю не современно. Но навряд ли сейчас в таких USB розетках вообще есть поддержка современных скоростных стандартов зарядки - максимум - стандарт зарядки повышенным током до 3А
Но.... идея унифицировать почти все электророзетки на USB-C большой мощности конечно занятная - вот только цена таких розеток будет очень высокая, а срок службы на порядки меньший! Ну и техника должна будет перейти с переменного тока на постоянный - впрочем для большинства современной домашне-офисной техники это как раз во благо. Но есть исключения- для такой техники как раз можно оставить несколько классических розеток.
Не стоит сбрасывать и желание инженеров (и потребителей) перейти в будущем на беспроводную доставку электроэнергии (во славу Николы Тесла) - но пока это лишь "условно" беспроводные зарядки для гаджетов и мечты о будущих возможностях безопасной передачи электроэнергии достаточной мощности хотя бы на расстояния в несколько метров
Ну а в будущем того глядишь и электрокары начнут оснащать унифицированным портом зарядки как на прочей домашней технике. Или они тоже перейдут на беспроводную зарядку - а такие технологии для автомобилей уже есть (выпускаются), как и есть технологии беспроводной зарядки в движении (пока ещё дорабатывается в лабораториях)
Даже если бы сделала его полностью свободным - это вряд ли. Сейчас почти весь мир делает ставку на USB-C. Поздно уже колёса менять, когда с горки "летишь".
Но UBS-C вряд ли будет последним физическим стандартом. Наверняка и устройства будут становиться ещё компактнее (что для них порт USB-C станет великоват). И новые требования к физическим каналам появятся (как для коммуникации, так и для подачи ещё большей мощности), в т.ч. для роста скорости. Д
Да и на унификации портов соединения гаджетов замена Lighting на USB-С - это не конец противостояния. Есть ещё другие порты, и не только видео и аудио, которые обособленно стоят в стороне. Как всё ещё и полно устройств с подключением питания не по USB-C (и даже не по USB прошлых поколений) - например те же ноутбуки, мониторы и прочие компьютеры с выносным БП (но они как раз будут следующими на очереди на унификацию зарядки).
При продолжении процесса унификации будут все шансы сменить и порт USB-C на более современный - более мощный и более компактный. Может тогда компания Эпл войдёт в общий мировой консорциум по разработке такого порта (вместе со своими патентами в этой области) - и тогда создадут более совершенный продукт. Например для более тонких устройств явно лучше не вставлять штекер внутрь, о обжимать им порт с внешней стороны, заодно, при такой схеме, проще сделать его присоединение и отсоединение с магнитным замком. И пыли некуда будет набиваться. И ломаться практически нечему. И ремонтопригодность будет даже выше чем сейчас (невзирая на более компактные корпуса устройств).
Не стоит и забывать тот факт, что сейчас активно развиваются и беспроводные способы как передачи данных так и зарядки. Пока они уступают проводным по скорости - но что будет лет через 30? Впрочем через 30 лет связь скорее всего уйдёт либо в беспроводную либо в оптическую стезю - смотря где удастся достичь больших скоростей при минимуме ошибок передачи пакетов, и пиковых задержек; и обеспечить подходящую схему электропитания (ведь с ним пока сложнее всего). Но, всё-таки думаю, ещё как минимум один этап унификации механических портов с появлением абсолютно нового порта нас ещё ждёт. Но, вряд ли ранее середины этого века. Хотя USB-C, DP, HDMI, S/PDIF и т.п. цифровые порты уже пришла пора унифицировать, как, впрочем думаю, и Ethernet порты как RJ45, SFP (со всеми разновидностями) - введя единый формат порта для высокоскоростной передачи данных (можно сразу спроектировать его универсальным и расширяемым с переменным числом активных линий-каналов - как это сделано сейчас например для PCI-Express слотов плат расширения) - не все устройства и не все кабели обязаны поддерживать все линии, но физически порты должны быть совместимы. При указанной мной выше схеме подключения чкерез внешне неваемый на порт зажим можно легко делать ширину такого порта и кабеля варьируемой - почти не создавая проблем подключением портов и штекеров кабелей разной ширины для разных устройств (но 100% проблемы не исключены - но будут сведены к минимуму - когда нет возможности например физически подсоединить широкий штекер к узкому порту в силу его специфически плотного расположения относительно других портов на устройстве - например на телевизоре - хотя там как раз места хоть отбавляй - но меру тоже знать надо)
P.S. А Эпл конечно лохонулась со своим проприетарным портом Lighting - когда весь миру уже начал стандартизацию - и они как никто другой нуждался в новом подключении - они решили выпендриться - и другим не дали сделать лучше и сами в пролёте - не так уж долго Lighting порт был (и видимо ещё будет) на рынке. Да и кроме как физически конструктивно в нём нет каких-то особых преимуществ - в остальном возможности расширения USB-C его полностью обходят. В первую очередь по электропитанию
Проблема в том, что настраивать алгоритмы надо через веб, а в виде кода это делать сложно. Также визуальное отражение важно, т.к. человек более 80% информации получает через зрение, и подготовка информации (структурно и в цвете) позволит ему делать это более быстро и более информативно.
WEB - не более чем средство передачи информации (и в меньшей степени визуализации - но это не принципиально)
Как я уже написал - против конструкторов и всяких мастеров, и схематичного преставления и редактирования ничего против не имею. Когда есть возможность текстового представления. Оба подхода имеют свои плюсы и минусы. Но на мой взгляд, именно текстовое представление даёт больше возможностей, и, чаще всего, удобства - но соглашусь, что работа секстовым представление требует больше навыков и привыкания. Но в конечном итоге - это будет куда более быстрый и эффективный путь. Особенно, когда работе с текстом будет активно помогать IDE, включая продвинутых AI-Ассистентов.
Текстовый подход - уже давно активно развивает свою как юзабилити, так свои возможности, как в глубину, так и в ширину - тут многое уже эффективно придумано, и многое ещё будет придумано. Тут много общих, условно, стандартизированных подходов. И очень просто делать новые инструменты, анализаторы, препроцессоры, генераторы и т.п. - что снижает нагрузку на человека и повышает эффективность работы. Не нужно изобретать эффективные средства редактирования - огромная база уже есть, но её можно и нужно ещё расширять, но не как что-то проприетарное - как что-то общее - со временем понятное и доступное многим, вне зависимости от их языков программирования и платформ.
И сейчас, благодаря продвинутым IDE, текстовый подход уже не так сильно уступает по визуализации графическим схемам и конструкторам, как, скажем лет 20-40 назад. И тут много чего ещё можно сделать. И зрение при работе с текстом сейчас очень даже задействовано.
Трудности с текстами могут быть только у тех, у кого просто психологически индивидуально плохое восприятие текста - как при чтении, так и при вводе (в т.ч. проблемы с моторикой пальцев). В большинстве случаев - это преодолимо. Но, соглашусь, заставить это преодолевать может быть не очень просто.
Поэтому, иметь возможность иного визуального представления я не отменяю - но только как дополнение.
Для того, чтобы писать на языках программирования, нужно хорошо знать синтаксис, а многие аналитики к этому не приучены. Тот же язык SQL понятен техническим специалистам и полностью не понятен обычным опытным пользователям прикладной сферы. Также он сильно далек от практической области. Он абстрактен (это его и преимущество, и слабость).
Я хорошего ЯП недалёкого будущего синтаксис не должен быть сложным, и должен легко усваиваться за пару вечеров (накрайняк - нескольких недель). При вводе алгоритма так же активно должна помогать IDE, со встроенной быстрой справкой по синтаксису.
Визуальный ввод тоже нужно изучать - и, на мой взгляд, это требует куда больше усилий.
Не согласен, что sQL хорошо понятен только техническим специалистам. На практике встречал людей (не программистов) - которые сами готовили себе отчёты на SQL-подобном языке запросов (после небольшого обучения и подготовленной инструкции). Да - это были несложные отчёты - но их это вполне устраивало, и разгружало работу программистов.
Согласен, что декларативные языки (как SQL) - достаточно высокоабстрактны - и я за повышение этого уровня абстракции. Это их сила и их же слабость. Но, лично я за такой подход, как минимум, в прикладном программировании. И да - ЯП SQL уже давно устарел, ему на смену должны прийти более мощные ЯП (как более сложные синтаксически, так и наоборот - более "человеколюбивые" с более ярко выражено близким к письменной человеческой речи синтаксисом).
Но из моей практики, как раз наоборот - проще программиста затащить в предметную область, чем из пользователя делать программиста.
Другое дело - нужно ли так поступать? Об этом ниже.
Для AI нужны алгоритмы и, если просто абстрактно, то язык не важен, а если конкретная область, то нужны термины для описания социально-экономических систем и конструкции, алгоритмы для них. Тогда вырабатывается более специализированный механизм, который собирает в себе инструменты в структуру. Он получил название "Структура бизнеса" (немного устаревшее, возможно требующее расширения)...
Вот именно такой подход я и пропагандирую. Я называют это "Бизнес сущностями" - блоки конструктора модульного подхода, определяющие топологию данных, взаимодействий, интерактивной работы и различных форматов ввода/вывода. Из таких "Бизнес сущностей" в итоге складывается единое приложение (или распределённая система). "Бизнес сущности" комбинируются и интегрируются друг с друг с другом - подвергаясь мусингу, расширению и полиморфизму. Вернее не сами сущности - а их содержимое, ведь они - лишь унифицированные контейнеры.
Настройку взаимодействия "Бизнес сущностей" (Business Entity) я пока представляю (вопреки сказанному выше) в виде визуального редактора, в виде схем, таблиц, опций. Но текстовое представление схемы тоже должно быть - скорее в виде сериализации - хотя бы чтобы эффективно работать с GIt
Но как только дело доходит до более глубоких алгоритмов обработки данных - там уже первенствует текст и какой-то ЯП (его синтаксис я пока прорабатываю).
Над "Бизнес сущностями" (помимо модулей и пакетов) - находится процесс "Сборка" - он отвечает за сборку из "Бизнес сущностей" итогового приложения или модуля/библиотеки. Главное его действие - это объединение по заданным правилам содержимого "Бизнес сущностей" в единые прикладные объекты (до этого момента один и тот же объект может быть сильно размазан по разным "Бизнес сущностям", как размазаны могут быть и отдельные части алгоритмов). Так же "Сборка" финального приложения может раскрывать большую часть абстракций (уже оперируя готовыми структурами данных), проводить кодогенерацию и все возможные статические подстановки; прогонять тесты. Более того, получать доступ к данным и статистики использования этого приложения (предыдущих сборок) и на её основе осуществлять ещё и глубокую оптимизацию, включающую AI-анализ и обращение к базам знаний готовых паттернов алгоритмов.
Считаю, что такой подход в прикладном программировании доступен уже сейчас - а AI возможности будут его расширять с каждым годом и уже во второй половине XXI века это будет наиболее востребовано и популярно.
Не стоит жить прошлым - нужно смотреть в будущее - тогда будет успех!
Хотелось бы, чтобы в нашем обществе людей со знаниями программирования было больше, но увы, мой опыт показывает, что их намного меньше, а хороших, понимающих предметную область, - еще меньше
Мне кажется - во второй половине XXI века ситуация вкорне изменится. Аналитиков будет мало (вернее, их то будет много - а вот спрос на них будет невелик). Аналитическую работу в основном будут выполнять системы Искусственного Интеллекта. Вероятно даже научаться формулировать вполне сносные ТЗ в бизнес-терминах. И это всё будет уже направлено не на человеческое юзабилити, а на машинную обработку - поэтому аналитики-люди уже будут не удел. Да и аналитика будет уже строиться на машинном обучение.
И вот тут как раз будет уже большой спрос на программистов.
Тогда может не нужно тащить аналитиков в программисты (ну разве что для переквалификации, на ущербном рынке труда по профессии аналитика). Как и наоборот, но в меньшей степени, может и не надо будет глубоко погружать программистов (в общей массе) в предметную область - ему на помощь придут AI-аналитики.
Да и программистов тоже всё больше будут подменять на AI-программистов. А им (и AI-аналитикам) как раз работать с текстовой информацией в виде, инструкций и команд, будет куда сподручнее, чем с графической, и в виде схем.
Эти тенденции уже начались - и уже скоро (лете через 10-20-30) будут весьма заметны.
Многолетние усилия и практическая апробация, теоретическое обобщение показывают, что "Будущее намного ближе".
О чём я и говорю. Пора перестраиваться. Не живите в прошлом - где во главе угла стоят не особо интеллектуально одарённые топ-менеджеры. Ориентируетесь на будущее - где во главе угла стоят AI системы обработки и генерации информации. И программисты - которые их настраивают и поддерживают. И им всем тексты куда важнее, чем визуальное представление - оно так о останется в прошлом. Придут новые ЯП 5-го поколения, и они не будут визуально-ориентированными, как это предполагалось в ЯП 4-го поколения. Этой революции не случилось - и вряд ли уже случится.
А если и случится в будущем - то совсем в другом виде - когда в обиход придёт глубокий VR, AR и голосовое взаимодействие - и, возможно, изменится сам подход к интерактивному взаимодействию человека и компьютера. Но это уже не ранее конца XXI - я так считаю, до середина века эти технологии буду ещё буксовать - их время пока не пришло, но обязательно придёт в будущем. А 50 лет - это не так уж и много для человеческого общества. Но за 50 лет всё то, что актуально сейчас - 100% уйдёт в небытие - или как минимум сильно видоизменится. Сейчас можно только предполагать как пойдёт развитие.... или же - начать потихоньку его направлять - в новое русло - главное не обшиться с вектором приложения усилий, чтобы они не были напрасны (против течения). Но даже если они будут ошибочны - это тоже может пойти на пользу развития - негативный опыт - тоже опыт, вот только успеха тем, кто его придерживался, это вряд ли принесёт (если у них не будет и другой альтернативы). Движение, условно, во всех направления - это ключевой закон эволюции - и эта техника весьма эффективна - в т.ч. в IT индустрии (и даже применяется на практике - просто об этом мало кто знает)
«алгоритмического программирования» (проектирования), когда создание функциональности делается аналитиками, формирующими бизнес правила (алгоритмы), создавая их в отдельности, но в целом – формируют «сеть»
Как можно заметить в конце моего первого комментария я склоняюсь к такому же будущему развития ЯП. За исключением того - что я против визуального и схематичного кодирования настройки правил. А придерживаюсь мнения о более традиционном подходе к текстовому описанию правил, больше - что-то среднее между абстрактным высокоуровневым кодированием - условно сленговом немного ограниченном строгой терминологией описательным повествованием условно на литературном языке (но не разговорном) - то к чему стремилась например компания SAP. Близким простым примером такового описания можно назвать семейство языков SQL.
То есть в текстовом виде (который снимает кучу описанных мною в первом посте проблем и дающий такую же кучу традиционных для современных ЯП возможностей) + с интеллектуальной поддержкой со стороны IDE (построенной с применением AI) - надо описывать исходные данные, действия и цели - обработки тех или иных данных или выполнения операций вне контура данных. Действия как раз и должны описывать в простых, понятных, но в то е время гибких терминах , напоминающих литературный текст, но в то же время близких именно к указанию выполнению необходимых команд над сущностями (как встроенных, так и библиотечных, кастомных, полиморфных) - где от редактора скрыты детали реализации (которые в итоге могут вести к более низкоуровневой реализации).
AI должен это всё анализировать как декларируемую схему - и встроить по ней план исполнения а затем и компилировать в промежуточный код (который далее уже компилируется более традиционно, например в режиме JIT, во время использования). По сути, получается чуть более сложная и интеллектуально гибкая схема как в используется в ряде классических СУБД.
При этом, никто не отменяет и визуального схематичного подхода - такие тексты могут быть сгенерированы конструкторами/мастерами-визадрдами/конвертерами из других представлений. Так и наоборот - на основе таких текстов можно строить схемы и визуализацию в нужном формате (AI ассистенты в IDE позволят провести оптимизацию конечного представления). Главное тут то - что описания алгоритмов должны быть относительно просты (все сложности скрыты с глаз долой в действиях, которые в схемах не раскрываются без должной на то необходимости).
т. е. 5 аналитиков на 1 программиста. Что в свою очередь позволяет сильно приблизить «алгоритмическое программирование» к бизнес заказчику и прикладной сфере
Мне не нравится такое соотношение. Это как Карлсон которому не понравился один торт со свечкой а "лучше восемь пирогов и одна свечка!". Личное моё мнение - программистов всегда должно значительно быть больше чем "бездельников" аналитиков. Создавать бизнес-схемы большого труа не составляет - а вот развивать возможности конструктора бизнес-схем - вот тут пока ещё нужно прикладывать много усилий. Но, возможно, лет через 50 Вы будете правы - и программистов будет нужно меньше - так как их процесс кодинга будет более продуктивным. Но... даже тогда я думаю что и число аналитиков сократится - их подвытеснят те же AI-аналитики (а такие системы сейчас развиваются куда быстрее чем AI-кодогенераторы).
Говоря о повторном использовании кода и его переносимости я в первую очерель говорил именно об описании аналитики, а не о деталях её реализации - поэтому я сугубо за текстовую базу такого описания.
Вопрос же обучения сам по себе очень обширен. В вкратце соглашусь - что прививать возможности low code решения задач лучше уже в школе - более того - с этого надо начинать знакомство с IT - прям с ранних классов - и такие визуальные системы программирования для детей уже есть. В средней школе - можно перейти к более интересным задачам для данного возраста школьников - программирования внутриигровых механик и скриптов с применением комбинации как визуальных конструкторов так и текстовых скриптов. Ну а позже всё-таки лучше перейти к изучению более традиционных современных ЯП. Вернуться с к схематичному аналитическому программированию можно на старших курсах ВУЗов - разбирая уже конкретные практические системы и платформы
Лично мне это решение нравится больше, чем из статьи (синтаксически не нравится только скобочная вложенность). Можно четко проверять иерархию типов - и как следствие поддерживаемую совместимость.
Но пример с композицией тоже хороший для ряда случаев.
Но в примере из статьи, почему-то только не показали возможности разворачивания структурных типов - когда часть мемберов можно поместить в другой структурный тип и переносить все скопом конструкцией {...Waterable}.
И не практически осталась не раскрыта тема, когда нужна будет проверка иерархии типов предков
Я пока скептически отношусь к Low-code - считаю, что в глобальном контексте время таких систем не пришло. Возможно в виде визуального программирования (когда-то преподносимого как 4-ое покидание языков программирования) в глобальном контексте это время никогда не настанет (будет вытеснено другими средствами Low-code - на основе отдаваемых команд (например голосовых) искусственному интеллекту - но это пока не скоро.
Но для ряда задач (отчасти показанных здесь) Low-code может быть вполне жизнеспособен уже сейчас, в частности:
Аналитические выборки, да и, вообще, любые выборки данных - конструировать их без ручного написания запросов к СУБД или к объектной модели вполне годная задача для Low-code
Визуализация данных, будь то формы взаимодействия с пользователем или выходные форумы - печатные формы, отчёты - тоже вполне можно решать в формате Low-code
Описание схем данных, в т.ч. со встройкой готовых адаптивных компонент работы с этими данными и их чтения/записи/сериализации/транспортировки/визуализации - тоже вполне можно решать на уровне Low-code уже сейчас (и в некоторых средах так и делается уже давно)
Описание схем бизнес-процессов, в т.ч. с последующей автогенерацией программного кода исполнения этих бизнес-процессов - тоже вполне посильная задача для Low-code подхода
Описание схем настройки и калибровки систем обработки данных с привлечение ML и AI - это тоже вполне может быть Low-code, как и задачи программирования AI и баз знаний
Построение алгоритмов специфической обработки данных - ну... отчасти Low-code тут тоже может быть очень полезен, особенно когда нужно создавать асинхронные, параллельные и распределённые системы обработки данных. Но тут пока ещё не всё так гладко как хотелось бы - но в будущем наверняка доля Low-code схем будет быстро расти
Конструирование алгоритмов отражения данных в учёте, да хоть просто для сохранения в СУБД, или задачи конвертации данных - это очень даже Lowe-code задачи - главное, чтобы была продвинутая система консолидации и оптимизации этих схем - чтобы их итоговое исполнение имело как можно меньше повторных обращений к данным и тем де исходным данным или многократным поискам.
Low-code решение задач неплохо помогает когда сразу нужно "убить двух-трёх... зайцев" - и структуры данных обозначить, и методы работы с ними, и интерфейсные элементы задать, и контроль доступа обеспечить и т.д. и т.п.
Задачи построения автотестов и отладки - тоже Low-code freinldy-задачи
Задачи построения автодокументации - тоже Low-code freinldy-задачи
А ещё Low-code - это очень хорошее решение для достижения кросс-платформенности и оптимизации приложений (не ручного тюнинга, когда нужно выжимать максимум, конечно, а возможности без больших усилий создавать вполне оптимальные и кросс-платформенные приложения для широкого круга потребления)
И последнее - Low-code схемы могут быть очень удобны в задачах, требующих сравнение и сопоставление схем (читай - задачи мерджа гит)
Вот такой вот я скептик - набросал кучу вариантов, где считаю Low-code вполне применимым. Но есть большая ложка дёгтя в этой бочке low-code-мёда. А именно:
Средства его формирования. Как выше написал - визуальные средства программирования так и не стали 4-ым поколением языков программирования - вообще не стали популярны, и заняли весьма унитарные и разрозненные ниши. А всё почему? А потому что:
Не так уж быстро с помощью них создаётся готовое решение (простое быстро - посложнее - уже скорость быстро падает)
Есть проблемы с переносимостью такого кода - решения разрозненны и для каждой целевой платформы (исполнения верхнего уровня) создаются отдельно - даже в рамках одной целевой платформы перенос готовых блоково очень ограничен
Проблемы повторного использования кода тоже очень существенны - библиотеки и шаблоны в таких системах редкость, наследование, миксины, интерфейсы, функциональный подход - ещё большая редкость , макросы - почти отсутствуют вовсе везде (я не про макросы - аналоги горячих клавиш и запись действий пользователя - хотя и с ними всё тоже туго; я про макросы повышения уровня абстракции и автогенерации Low-code конструкций)
Актуальны и проблемы адаптивности и повышения уровня абстракции - ни дженериков, ни виртуализации, даже шаблонная подстановка редка
Проблемы анализа готовых схем - их зачастую анализировать (изучать и дорабатывать) бывает куда сложнее, чем просто готовый текст. Печатать их тоже весьма проблемно
Проблема обучаемости - может надуманная - но если для изучения ЯП полно курсов, литературы и сайтов. То для Low-code такой базы нет - все они проприетарный - каждую систему придётся изучать индивидуально на основе той документации, что авторы предложили. В лучше случае будет одна книжка. Но это не сравнится с тем многообразием источников информации, что есть по традиционным популярным ЯП
Возможно есть и другие проблемы - просто навскидку не назову.
Вот поэтому я скептически отношусь к Low-code - да - это здорово - да это может быть полезно- да это может реально ускорять процесс разработки и расширять сферу итогового результата и его качество - но только если это будет идти как довесок к классическому текстовому программированию и текстовому преставлению схем.
И в будущем, как мне кажется, куда эффективнее будет модель именно текстового абстрактного программирования скорее ближе к декларативному - к процессу описания сущностей и отдачи команд - а уже AI cсистемы будут это всё анализировать и генерировать уже готовый традиционный кросс-платформенный программный код - который затем уже будет компилироваться под целевую платформу исполнения. При наборе такого текста AI-ассистент в IDE тоже будет активно помогать. Ну и отчасти можно будет пользоваться готовыми Low-code конструкторами, сниппетами и прочими адаптивными абстрактными шаблонами. Ручной набор программного кода существенно сократится - но ещё очень не скоро сойдёт на нет
СУБД Tarantool и есть Lua - так же как СУБД Oracle Database есть Java, а MS SQL Server как .NET (там вот реально можно на любом языке писать, который компилируется в CLR .NET; ещё есть поддержка языка R). И, например, если не ошибаюсь, СУБД SAP HANA есть поддержка JavaScript подпрограмм (наверянка можно привести и другие примеры СУБД - но я просто про них не знаю). То есть на этих языковых платформах внутри этих СУБД можно создавать то, что некоторые называют костюмными микросервисами - выполняющими гибкую обработку данных на алгоритмах внутри контекста кластера серверов данных СУБД, близко к данным. Тем самым могут брать часть задач сервера приложений. Вот только гибкость прямого взаимодействия через HTTP-сервисы может быть разной.
Это можно использовать, можно не использовать. Можно, как и в данной статье, просто подключаться к этим СУБД через коннектор (например native-клиент), и работать через него, не задействую внутренние микросервисы в СУБД на костюмных "скриптах", и не знаю о том как оно там вообще выполняется, и на чём там оно пишется.
Альтернативой native-микросервисам во многих СУБД всегда были серверные процедуры, обычно создаваемые на расширенном SQL - например T-SQL, PL/SQL. Там есть свои плюсы, минусы и ограничения использования. Но в Tarantool таких процедур нет (если не ошибаюсь).
Активно использовать большие подпрограммы на Lua в Tarantool я бы не стал советовать - т.к. данная СУБД однопоточная - и этот подход будет её замедлять очень сильно. В отличии от названных мной выше других СУБД (и вообще других, не только реляционных, но многопоточных). То есть как сервер приложений Tarantool - это плохая идея - поэтому особо заворачиваться на подпрограммах Lua внутри Tarantool смысла нет - нужна эффективная сложная бакэнд-обработка данных - пишите свой сервер приложений, и работайте из него с Tarantool по принципу, показанному в данной статье. Но какой бы многозадачный сервер приложений Вы не сделали в однопоточность сервера Tarantool всё-равно рано или поздно упрётесь
Самая простая аналогия с проницаемостью первого этапа (380К лет от БВ) - это представить комнату наполненную паром, условно освещаемую со всех сторон (как просто некий куб сектора пространства - а освещение - со всех сторон это просто входящий поток фотонов с соседних секторов). Буде ярко. Смотреть можно. Но ни черта не видно. Проницаемость около нуля. Далее будем откачивать пар - т.е. уменьшать его плотность (или расширят комнату) - видимость будет расти - появится проницаемость.
А если точнее - то вместо пара можно взять скажем инертный газ (к примеру НЕОН) и в той же комнате облучать его со всех сторон электронами - поместить в электромагнитное поле - тоже будет ярко - в этот раз видимые фотоны света будет испускать газ - но так же ничерта не будет видно.
Второй этап (50ML-500ML лет от БВ - когда зажглись первые звёзды) - ставим ультрафиолетовый источник света в центр комнаты - это звезда а вокруг очень плотно напускам неон - будет поначалу очень темно - но со временем комната наполнится источником света - но тут уже сложнее - так как по хорошему нужно удерживать неон вокруг центра света - чтобы не сдерживать его границами помещения - так как реально на этом этапе эта условность уже отсутствует. Но, можно удержать газ электромагнитным полем из центра источника света
Со временем вся эта инфраструктура просто может стать сама кроссплатформенной - к этому должны стремиться разработчики непопулярных хардварных архитектур. То есть самим создавать и продвигать низкоуровневые библиотеки для своей архитектуры - приводя их внешний API к общему знаменателю.
За рамками этого API все тонкости архитектур уже должны быть не значительны - и ЯП более высокого уровня должны иметь поддержку работы с разными архитектурами - когда нужно будет спускаться до этого более низкого уровня в очень редких случаях - а методология разработки должна так и преподаваться/изучаться - что нельзя затачивать тиражируемый алгоритм лишь под одну архитектуру - когда это имеет значение. И новые языки программирования 5-го поколения должны активно это продвигать - стараясь "брать огонь на себя" - самостоятельно (с привлечением AI технологий) решать задачи адаптации особых частей программы сразу под все (настроенные) конечные архитектуры и софтверные платформы среды выполнения - не позволяя скомпилировать программу в промежуточный код - если будут нужны соответствующие уточнения у программиста. Ну а из промежуточного кода под конечную платформу и архитектуру уже будут компилировать специально настроенные бэкэенд-компиляторы, дополнительно проводя тонкую оптимизацию уже под конкретную архитектуру.
И это я ещё не говорил об обязательном фидбэке ЯП 5-го поколения - когда с работающих программ собирается обязательная статистка обработки тех или иных данных и условий эксплуатации - AI-анализатор это всё обрабатывает, накапливает базу знаний (в т.ч. на постоянных тестах DevOps как проводимых самостоятельно самим AI, так людьми) - и затем могут вырабатываться новые более эффективные решения для алгоритмов - после чего они исправляются и пересоздаются новые версии (в т.ч. несколько вариаций под разные условия эксплуатации и разные конечные архитектуры).
Таково моё виденье будущего программирования - кроссплатформенность как и кроссархитектурность будет данностью, а не исключением! Как и многопоточность! Как ориентированность на облачность!
Будущее железа всегда определяется софтом. А коли софту будет не так важно на каком оно железе - то и у железа будет больше вариативности архитектуры. Я это имел в виду - что в будущем даже не популярные хардварные архитектуры могут получить новый толчок развития - когда на них можно будет запускать привычный софт, который ранее привыкли использовать на другой архитектуре.
То есть - развитие софтверной кроссплатформенности подстегнёт развитие разнообразия самих платформ и хардварных архитектур. Того глядишь - настанут временна, когда под разные задачи будут подбирать разные архитектуры (в кластерах серверов) - а облачные ОС будут спроектированы так - чтобы разный софт запускался на разной архитектуре (и даже сразу использовал несколько разных архитектур, доступных в таком облачном кластере). А пользователю а ему вообще в будет это всё незаметно и пофиг на то как этот та всё выполняется (для него это всё будет бесшовной в одном пространстве) - его клиент будет прост - ведь скорее всего он будет просто тонким - и может быть построен на любой архитектуре и использовать любую платформу и ОС.
Многие считали архитектуру x86 непоколебимой (пусть и с кучей проблем и признанием тупиковости развития) - но вот... ещё лет 20 - и этой архитектуре скорее всего настанет хана - её вытеснит ARM (а там того глядишь и другие подтянутся) - Linux уже прекрасно работает, Windows 11 тоже подтягивается, MacOS уже тоже там (не говоря уже о почти всех мобильных устройствах, большей части современного теле-видео-аудио оборудования) - а это не мало - лет через 20 это будет почти весь рынок невоенного потребления (с военным судить не буду, но думаю и там ARM будет в фаворе). Но спустя ещё лет 20 его наверняка начну теснить новых архитекторы - так что это не конец противостояния - оно продолжится и в XXII веке. Но конечному потребителю это всё будет как-то не особо важно - он будет использовать софт на разной архитектуре не замечая этого.
И это означает то - что можно разрабатывать и новые архитектуры , и популяризировать имеющиеся не популярные - главное - чтобы ОС подтягивались и софт был кроссплатформенным! Такой подход изменит будущее - и повлияет на прогнозы автора статьи
Хм.... всё не то - я то думал в статье будет написано как создавать высокопроизводительный код, выполняемый на стороне сервера 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 станет больше - а там и потребители разных платформ расширятся. Но это пока лишь моё мнение. Как он будет на самом деле не знаю - до этих времён ещё пройдёт полвека!
Я лишь говорил о розетке - которую можно было бы унифицировать условно "электрически", поставив преобразователь микросхему.
Ещё хочу всё-таки уточнить свою мысль - что для серверного оборудования менять SFP на USB-C сейчас пока действительно не лучшая затея - говоря выше об унификации сетевых портов я всё-таки имел в виду переход на новый универсальный порт - уже наверняка оптический (и не сейчас - а в будущем), когда медных коммуникативных возможностей будет не достаточно не только серверам, но уже и клиентам. И я говорил о модели расширяемого порта - построенного по единым правилам, но имеющего конструктивные возможности разной реализации (при, в целом, общей совместимости) иметь разную пропускную способность (за разную стоимость) - главное, чтобы порты, кабели и контроллеры это поддерживали - а при недостаточной поддержке - чтобы всё тоже работало, но уже, естественно, медленнее - получаем гибкость масштабирования.
Но для клиентского оборудования - думаю уже лет через 10-20 вполне можно было бы отказаться от RJ45 в пользу USB розетки (сохраняя витую пару как способ связи розеток между собой), и клиентское сетевое оборудование тогда модно на USB-C переводить. Заодно и PoE в стандарт сразу добавить (для USB-C это уже будет Power Delivery). Ну а потом, потихоньку заменять витую пару на оптику - при сохранении стандарта на сами розетки - USB-C формата - что упростит переход на оптические линии - ведь возможности медной витой пары уже на пределе - сейчас это 10GB - ну, вероятно, 100GB ещё выжмут (на расстояниях до 25-50 метров) - а дальше уже слишком большие наводки и затухания сигнала - но не думаю что 100GB медные сети вообще придут в сектор SOHO - так что лет через 30 чаще всего (где нужны высокие скорости, даже в домах) начнут уже тянуть оптику.
Такая унификация очень благотворно скажется на упрощении подключении устройств для передачи информации. Это удобно и для обычного пользовательского оборудования, и для серверного и для сетей IoT устройств.
Правда тут ещё будет расти конкуренция с беспроводными технологиями. Power Delivery по кабелю, большая секюрность и более высокая стабильность проводного канала - это весомые доводы за кабельные сети.
Дом будущего - где 90% всех розеток унифицированные (пусть условно UBS-C хотя это может быть и новый формат) как и 98% всех портов для передачи данных между устройствами тоже унифицированы - это очень красивая идея! Но пока это лишь мечта, такой тренда ещё не начался
Вся вселенная действительно может находиться в состоянии суперпозиции - но это ещё не доказано и не опровергнуто
Это была шутка. Я хотел лишь показать, что есть простая физика движения мяча по заданной траектории, по законам Ньютона для идеального точечного тела. Но на практике есть много других факторов, которые напрямую уже не так просто встраиваются в Ньютоновскую механику - закрученный мяч, например - это состояние уже точечной частицы, условно - её спин - и вот в квантовой механике эти свойства точечной частицы уже учитываются более строго - но проблема в том, что там это уже не детерминированная модель - и никогда нет чёткого 100% ответа о состоянии системы в следующий момент времени - есть только вероятности этого состояния - они описываются формулами и подтверждаются экспериментами (сериями экспериментов, ведь в теории вероятности один эксперимент ничего не значит)
Во-первых - я говорил о наличии не нулевой вероятности прохода сквозь стенку условного бильярдного шара.
Во-вторых, электроны как раз плохо подчиняются законам Ньютона - электрон будет двигаться иначе, чем в простых уравнения Ньютона
Плохо потому, что реально ньютоновская механика, построенная на силе тяготения конечно работает, но в квантовом мире она это делает с большим числом ошибок, потому что её эффект тут играет уже незначительную роль, куда сильнее на электрон будут влиять законы электромагнетизма - но и они не дадут 100% описание поведения - поэтому и есть законы квантовой механики - вот они близки к 100% но и они пока не могут всё описать с максимальной точностью, хотя в целом вероятностная картина получается верная, но в том то и дело, что она вероятностная - нет уже чёткого определения скоростей и положений - поэтому и возникли всякие ещё более глубокие теории - типа теории струн или M-теории - в попытке дать математическое объяснения почему электрон будет вести себя именно с такими вероятностями, которые определяет квантовая физика. Возможно дальнейшее изучение законов субквантового мира позволят вообще избавиться от вероятностей - и мы придём к полностью детерминированной модели , но тогда, вероятно мир окажется дискретным. Но это уже только гипотезы - дальше расплывчатых (но работающих) законов квантовой теории наука пока не продвинулась так чтобы теория 100% согласовывалась с экспериментами (которые на таком уровне пока и проводить то почти невозможно - не достаточный уровень технологий)
Ну да, SATA - он он уже почти не жилец.
Что Вы там обжимать собрались? Тут просто дело в розетках - вывести такие розетки , где на входе обжимается витая пара, а на выходе (после микросхемы преобразователя) идёт уже USB-C. Ну и коммуникационное оборудование просто на USB протокол и порт переводить потихоньку
Ну, говорят, дешеветь будет (технологии производства не стоят на месте), а спрос на оптику будет расти всё больше и больше - тут всё зависит насколько ещё хватит меди для обеспечения возрастающего спроса на скорости
С этим пока всё сложнее. Но может быть, может быть!
Шары не электроны - чем крупнее объект тем меньше он подвержен квантовым законам (как объект в целом). В принципе согласно квантовой теории шары тоже могут разлететься в разные стороны - а один или оба ещё и сквозь стенку пройти после столкновения - просто чем крупнее объект - тем ниже вероятность этого события - для электронов это высокая вероятность, но их размер ничтожно мал, по сравнению, скажем, биллиардным шаром - в котором этих электронов тьма тьмущая (и не только электронов) - и чтобы шары повели себя по законам квантовой механике (а не по Ньютоновским) нужно чтобы условно каждая частица атома вероятностно повела себя согласовано с другими частями для движения в ином направлении - вот (условно говоря) перемножив такие вероятности каждой частицы - получим вероятность такого события для шаров - она будет ничтожно мала, но не исключена.
Вон в футболе голы Роберта Карлоса, особенно гол по спирали в ворота Франции в 1997 году, легко так "нарушают" все мыслимые обывательские законы физики
Остальные 3 они запретят - ради этого и стараются
Куда Вы там втыкать type C вилку решили я так и не понял.
Конечно проблема электророзеток она больше свойственна для мира в целом, чем для Европы. А Британия - ну она уже не в Евросоюзе и всем там на Англию уже пофиг!
С другой стороны - сейчас потихоньку уже началась мода создания USB розеток без адаптера. Сначала появились БП на компьютерах с такими портами. Потом появились электроудлинители где были как электророзетки так и USB (тогда ещё USB-A, сейчас уж есть и с USB-C) - потом и стеноразмещаемые розетки стали появляться с портами USB-C (и USB-A). Про автомобили понятно что там уже тоже давно размещают такие розетки.
Вон уже в метро и прочем общественном транспорте, включая остановки UBS розетки есть - сначала появились USB-A, потом добавили и USB-C
Но я пока не понимаю этого тренда (ну кроме транспорта) - сейчас электроадаптеры развиваются очень быстро - мощности растут - телефоны стремятся заряжаться меньше чем за полчаса 0% до 100% - поэтому всё время появляются новые адаптеры - и стандарты зарядки. Но сменить устаревший адаптер наверное проще - чем менять устаревшую USB розетку - хотя может я просто мыслю не современно. Но навряд ли сейчас в таких USB розетках вообще есть поддержка современных скоростных стандартов зарядки - максимум - стандарт зарядки повышенным током до 3А
Но.... идея унифицировать почти все электророзетки на USB-C большой мощности конечно занятная - вот только цена таких розеток будет очень высокая, а срок службы на порядки меньший! Ну и техника должна будет перейти с переменного тока на постоянный - впрочем для большинства современной домашне-офисной техники это как раз во благо. Но есть исключения- для такой техники как раз можно оставить несколько классических розеток.
Не стоит сбрасывать и желание инженеров (и потребителей) перейти в будущем на беспроводную доставку электроэнергии (во славу Николы Тесла) - но пока это лишь "условно" беспроводные зарядки для гаджетов и мечты о будущих возможностях безопасной передачи электроэнергии достаточной мощности хотя бы на расстояния в несколько метров
Ну а в будущем того глядишь и электрокары начнут оснащать унифицированным портом зарядки как на прочей домашней технике. Или они тоже перейдут на беспроводную зарядку - а такие технологии для автомобилей уже есть (выпускаются), как и есть технологии беспроводной зарядки в движении (пока ещё дорабатывается в лабораториях)
Даже если бы сделала его полностью свободным - это вряд ли. Сейчас почти весь мир делает ставку на USB-C. Поздно уже колёса менять, когда с горки "летишь".
Но UBS-C вряд ли будет последним физическим стандартом. Наверняка и устройства будут становиться ещё компактнее (что для них порт USB-C станет великоват). И новые требования к физическим каналам появятся (как для коммуникации, так и для подачи ещё большей мощности), в т.ч. для роста скорости. Д
Да и на унификации портов соединения гаджетов замена Lighting на USB-С - это не конец противостояния. Есть ещё другие порты, и не только видео и аудио, которые обособленно стоят в стороне. Как всё ещё и полно устройств с подключением питания не по USB-C (и даже не по USB прошлых поколений) - например те же ноутбуки, мониторы и прочие компьютеры с выносным БП (но они как раз будут следующими на очереди на унификацию зарядки).
При продолжении процесса унификации будут все шансы сменить и порт USB-C на более современный - более мощный и более компактный. Может тогда компания Эпл войдёт в общий мировой консорциум по разработке такого порта (вместе со своими патентами в этой области) - и тогда создадут более совершенный продукт. Например для более тонких устройств явно лучше не вставлять штекер внутрь, о обжимать им порт с внешней стороны, заодно, при такой схеме, проще сделать его присоединение и отсоединение с магнитным замком. И пыли некуда будет набиваться. И ломаться практически нечему. И ремонтопригодность будет даже выше чем сейчас (невзирая на более компактные корпуса устройств).
Не стоит и забывать тот факт, что сейчас активно развиваются и беспроводные способы как передачи данных так и зарядки. Пока они уступают проводным по скорости - но что будет лет через 30? Впрочем через 30 лет связь скорее всего уйдёт либо в беспроводную либо в оптическую стезю - смотря где удастся достичь больших скоростей при минимуме ошибок передачи пакетов, и пиковых задержек; и обеспечить подходящую схему электропитания (ведь с ним пока сложнее всего). Но, всё-таки думаю, ещё как минимум один этап унификации механических портов с появлением абсолютно нового порта нас ещё ждёт. Но, вряд ли ранее середины этого века. Хотя USB-C, DP, HDMI, S/PDIF и т.п. цифровые порты уже пришла пора унифицировать, как, впрочем думаю, и Ethernet порты как RJ45, SFP (со всеми разновидностями) - введя единый формат порта для высокоскоростной передачи данных (можно сразу спроектировать его универсальным и расширяемым с переменным числом активных линий-каналов - как это сделано сейчас например для PCI-Express слотов плат расширения) - не все устройства и не все кабели обязаны поддерживать все линии, но физически порты должны быть совместимы. При указанной мной выше схеме подключения чкерез внешне неваемый на порт зажим можно легко делать ширину такого порта и кабеля варьируемой - почти не создавая проблем подключением портов и штекеров кабелей разной ширины для разных устройств (но 100% проблемы не исключены - но будут сведены к минимуму - когда нет возможности например физически подсоединить широкий штекер к узкому порту в силу его специфически плотного расположения относительно других портов на устройстве - например на телевизоре - хотя там как раз места хоть отбавляй - но меру тоже знать надо)
P.S. А Эпл конечно лохонулась со своим проприетарным портом Lighting - когда весь миру уже начал стандартизацию - и они как никто другой нуждался в новом подключении - они решили выпендриться - и другим не дали сделать лучше и сами в пролёте - не так уж долго Lighting порт был (и видимо ещё будет) на рынке. Да и кроме как физически конструктивно в нём нет каких-то особых преимуществ - в остальном возможности расширения USB-C его полностью обходят. В первую очередь по электропитанию
Зарядки буду единые. А розетки так и останутся - разные - в итоге - без переходников в путешествиях никак не обойтись
WEB - не более чем средство передачи информации (и в меньшей степени визуализации - но это не принципиально)
Как я уже написал - против конструкторов и всяких мастеров, и схематичного преставления и редактирования ничего против не имею. Когда есть возможность текстового представления. Оба подхода имеют свои плюсы и минусы. Но на мой взгляд, именно текстовое представление даёт больше возможностей, и, чаще всего, удобства - но соглашусь, что работа секстовым представление требует больше навыков и привыкания. Но в конечном итоге - это будет куда более быстрый и эффективный путь. Особенно, когда работе с текстом будет активно помогать IDE, включая продвинутых AI-Ассистентов.
Текстовый подход - уже давно активно развивает свою как юзабилити, так свои возможности, как в глубину, так и в ширину - тут многое уже эффективно придумано, и многое ещё будет придумано. Тут много общих, условно, стандартизированных подходов. И очень просто делать новые инструменты, анализаторы, препроцессоры, генераторы и т.п. - что снижает нагрузку на человека и повышает эффективность работы. Не нужно изобретать эффективные средства редактирования - огромная база уже есть, но её можно и нужно ещё расширять, но не как что-то проприетарное - как что-то общее - со временем понятное и доступное многим, вне зависимости от их языков программирования и платформ.
И сейчас, благодаря продвинутым IDE, текстовый подход уже не так сильно уступает по визуализации графическим схемам и конструкторам, как, скажем лет 20-40 назад. И тут много чего ещё можно сделать. И зрение при работе с текстом сейчас очень даже задействовано.
Трудности с текстами могут быть только у тех, у кого просто психологически индивидуально плохое восприятие текста - как при чтении, так и при вводе (в т.ч. проблемы с моторикой пальцев). В большинстве случаев - это преодолимо. Но, соглашусь, заставить это преодолевать может быть не очень просто.
Поэтому, иметь возможность иного визуального представления я не отменяю - но только как дополнение.
Я хорошего ЯП недалёкого будущего синтаксис не должен быть сложным, и должен легко усваиваться за пару вечеров (накрайняк - нескольких недель). При вводе алгоритма так же активно должна помогать IDE, со встроенной быстрой справкой по синтаксису.
Визуальный ввод тоже нужно изучать - и, на мой взгляд, это требует куда больше усилий.
Не согласен, что sQL хорошо понятен только техническим специалистам. На практике встречал людей (не программистов) - которые сами готовили себе отчёты на SQL-подобном языке запросов (после небольшого обучения и подготовленной инструкции). Да - это были несложные отчёты - но их это вполне устраивало, и разгружало работу программистов.
Согласен, что декларативные языки (как SQL) - достаточно высокоабстрактны - и я за повышение этого уровня абстракции. Это их сила и их же слабость. Но, лично я за такой подход, как минимум, в прикладном программировании. И да - ЯП SQL уже давно устарел, ему на смену должны прийти более мощные ЯП (как более сложные синтаксически, так и наоборот - более "человеколюбивые" с более ярко выражено близким к письменной человеческой речи синтаксисом).
Но из моей практики, как раз наоборот - проще программиста затащить в предметную область, чем из пользователя делать программиста.
Другое дело - нужно ли так поступать? Об этом ниже.
Вот именно такой подход я и пропагандирую. Я называют это "Бизнес сущностями" - блоки конструктора модульного подхода, определяющие топологию данных, взаимодействий, интерактивной работы и различных форматов ввода/вывода. Из таких "Бизнес сущностей" в итоге складывается единое приложение (или распределённая система). "Бизнес сущности" комбинируются и интегрируются друг с друг с другом - подвергаясь мусингу, расширению и полиморфизму. Вернее не сами сущности - а их содержимое, ведь они - лишь унифицированные контейнеры.
Настройку взаимодействия "Бизнес сущностей" (Business Entity) я пока представляю (вопреки сказанному выше) в виде визуального редактора, в виде схем, таблиц, опций. Но текстовое представление схемы тоже должно быть - скорее в виде сериализации - хотя бы чтобы эффективно работать с GIt
Но как только дело доходит до более глубоких алгоритмов обработки данных - там уже первенствует текст и какой-то ЯП (его синтаксис я пока прорабатываю).
Над "Бизнес сущностями" (помимо модулей и пакетов) - находится процесс "Сборка" - он отвечает за сборку из "Бизнес сущностей" итогового приложения или модуля/библиотеки. Главное его действие - это объединение по заданным правилам содержимого "Бизнес сущностей" в единые прикладные объекты (до этого момента один и тот же объект может быть сильно размазан по разным "Бизнес сущностям", как размазаны могут быть и отдельные части алгоритмов). Так же "Сборка" финального приложения может раскрывать большую часть абстракций (уже оперируя готовыми структурами данных), проводить кодогенерацию и все возможные статические подстановки; прогонять тесты. Более того, получать доступ к данным и статистики использования этого приложения (предыдущих сборок) и на её основе осуществлять ещё и глубокую оптимизацию, включающую AI-анализ и обращение к базам знаний готовых паттернов алгоритмов.
Считаю, что такой подход в прикладном программировании доступен уже сейчас - а AI возможности будут его расширять с каждым годом и уже во второй половине XXI века это будет наиболее востребовано и популярно.
Не стоит жить прошлым - нужно смотреть в будущее - тогда будет успех!
Мне кажется - во второй половине XXI века ситуация вкорне изменится. Аналитиков будет мало (вернее, их то будет много - а вот спрос на них будет невелик). Аналитическую работу в основном будут выполнять системы Искусственного Интеллекта. Вероятно даже научаться формулировать вполне сносные ТЗ в бизнес-терминах. И это всё будет уже направлено не на человеческое юзабилити, а на машинную обработку - поэтому аналитики-люди уже будут не удел. Да и аналитика будет уже строиться на машинном обучение.
И вот тут как раз будет уже большой спрос на программистов.
Тогда может не нужно тащить аналитиков в программисты (ну разве что для переквалификации, на ущербном рынке труда по профессии аналитика). Как и наоборот, но в меньшей степени, может и не надо будет глубоко погружать программистов (в общей массе) в предметную область - ему на помощь придут AI-аналитики.
Да и программистов тоже всё больше будут подменять на AI-программистов. А им (и AI-аналитикам) как раз работать с текстовой информацией в виде, инструкций и команд, будет куда сподручнее, чем с графической, и в виде схем.
Эти тенденции уже начались - и уже скоро (лете через 10-20-30) будут весьма заметны.
О чём я и говорю. Пора перестраиваться. Не живите в прошлом - где во главе угла стоят не особо интеллектуально одарённые топ-менеджеры. Ориентируетесь на будущее - где во главе угла стоят AI системы обработки и генерации информации. И программисты - которые их настраивают и поддерживают. И им всем тексты куда важнее, чем визуальное представление - оно так о останется в прошлом. Придут новые ЯП 5-го поколения, и они не будут визуально-ориентированными, как это предполагалось в ЯП 4-го поколения. Этой революции не случилось - и вряд ли уже случится.
А если и случится в будущем - то совсем в другом виде - когда в обиход придёт глубокий VR, AR и голосовое взаимодействие - и, возможно, изменится сам подход к интерактивному взаимодействию человека и компьютера. Но это уже не ранее конца XXI - я так считаю, до середина века эти технологии буду ещё буксовать - их время пока не пришло, но обязательно придёт в будущем. А 50 лет - это не так уж и много для человеческого общества. Но за 50 лет всё то, что актуально сейчас - 100% уйдёт в небытие - или как минимум сильно видоизменится. Сейчас можно только предполагать как пойдёт развитие.... или же - начать потихоньку его направлять - в новое русло - главное не обшиться с вектором приложения усилий, чтобы они не были напрасны (против течения). Но даже если они будут ошибочны - это тоже может пойти на пользу развития - негативный опыт - тоже опыт, вот только успеха тем, кто его придерживался, это вряд ли принесёт (если у них не будет и другой альтернативы). Движение, условно, во всех направления - это ключевой закон эволюции - и эта техника весьма эффективна - в т.ч. в IT индустрии (и даже применяется на практике - просто об этом мало кто знает)
Как можно заметить в конце моего первого комментария я склоняюсь к такому же будущему развития ЯП. За исключением того - что я против визуального и схематичного
кодированиянастройки правил. А придерживаюсь мнения о более традиционном подходе к текстовому описанию правил, больше - что-то среднее между абстрактным высокоуровневым кодированием - условно сленговом немного ограниченном строгой терминологией описательным повествованием условно на литературном языке (но не разговорном) - то к чему стремилась например компания SAP. Близким простым примером такового описания можно назвать семейство языков SQL.То есть в текстовом виде (который снимает кучу описанных мною в первом посте проблем и дающий такую же кучу традиционных для современных ЯП возможностей) + с интеллектуальной поддержкой со стороны IDE (построенной с применением AI) - надо описывать исходные данные, действия и цели - обработки тех или иных данных или выполнения операций вне контура данных. Действия как раз и должны описывать в простых, понятных, но в то е время гибких терминах , напоминающих литературный текст, но в то же время близких именно к указанию выполнению необходимых команд над сущностями (как встроенных, так и библиотечных, кастомных, полиморфных) - где от редактора скрыты детали реализации (которые в итоге могут вести к более низкоуровневой реализации).
AI должен это всё анализировать как декларируемую схему - и встроить по ней план исполнения а затем и компилировать в промежуточный код (который далее уже компилируется более традиционно, например в режиме JIT, во время использования). По сути, получается чуть более сложная и интеллектуально гибкая схема как в используется в ряде классических СУБД.
При этом, никто не отменяет и визуального схематичного подхода - такие тексты могут быть сгенерированы конструкторами/мастерами-визадрдами/конвертерами из других представлений. Так и наоборот - на основе таких текстов можно строить схемы и визуализацию в нужном формате (AI ассистенты в IDE позволят провести оптимизацию конечного представления). Главное тут то - что описания алгоритмов должны быть относительно просты (все сложности скрыты с глаз долой в действиях, которые в схемах не раскрываются без должной на то необходимости).
Мне не нравится такое соотношение. Это как Карлсон которому не понравился один торт со свечкой а "лучше восемь пирогов и одна свечка!". Личное моё мнение - программистов всегда должно значительно быть больше чем "бездельников" аналитиков. Создавать бизнес-схемы большого труа не составляет - а вот развивать возможности конструктора бизнес-схем - вот тут пока ещё нужно прикладывать много усилий. Но, возможно, лет через 50 Вы будете правы - и программистов будет нужно меньше - так как их процесс кодинга будет более продуктивным. Но... даже тогда я думаю что и число аналитиков сократится - их подвытеснят те же AI-аналитики (а такие системы сейчас развиваются куда быстрее чем AI-кодогенераторы).
Говоря о повторном использовании кода и его переносимости я в первую очерель говорил именно об описании аналитики, а не о деталях её реализации - поэтому я сугубо за текстовую базу такого описания.
Вопрос же обучения сам по себе очень обширен. В вкратце соглашусь - что прививать возможности low code решения задач лучше уже в школе - более того - с этого надо начинать знакомство с IT - прям с ранних классов - и такие визуальные системы программирования для детей уже есть. В средней школе - можно перейти к более интересным задачам для данного возраста школьников - программирования внутриигровых механик и скриптов с применением комбинации как визуальных конструкторов так и текстовых скриптов. Ну а позже всё-таки лучше перейти к изучению более традиционных современных ЯП. Вернуться с к схематичному аналитическому программированию можно на старших курсах ВУЗов - разбирая уже конкретные практические системы и платформы
Лично мне это решение нравится больше, чем из статьи (синтаксически не нравится только скобочная вложенность). Можно четко проверять иерархию типов - и как следствие поддерживаемую совместимость.
Но пример с композицией тоже хороший для ряда случаев.
Но в примере из статьи, почему-то только не показали возможности разворачивания структурных типов - когда часть мемберов можно поместить в другой структурный тип и переносить все скопом конструкцией {...Waterable}.
И не практически осталась не раскрыта тема, когда нужна будет проверка иерархии типов предков
Я пока скептически отношусь к Low-code - считаю, что в глобальном контексте время таких систем не пришло. Возможно в виде визуального программирования (когда-то преподносимого как 4-ое покидание языков программирования) в глобальном контексте это время никогда не настанет (будет вытеснено другими средствами Low-code - на основе отдаваемых команд (например голосовых) искусственному интеллекту - но это пока не скоро.
Но для ряда задач (отчасти показанных здесь) Low-code может быть вполне жизнеспособен уже сейчас, в частности:
Аналитические выборки, да и, вообще, любые выборки данных - конструировать их без ручного написания запросов к СУБД или к объектной модели вполне годная задача для Low-code
Визуализация данных, будь то формы взаимодействия с пользователем или выходные форумы - печатные формы, отчёты - тоже вполне можно решать в формате Low-code
Описание схем данных, в т.ч. со встройкой готовых адаптивных компонент работы с этими данными и их чтения/записи/сериализации/транспортировки/визуализации - тоже вполне можно решать на уровне Low-code уже сейчас (и в некоторых средах так и делается уже давно)
Описание схем бизнес-процессов, в т.ч. с последующей автогенерацией программного кода исполнения этих бизнес-процессов - тоже вполне посильная задача для Low-code подхода
Описание схем настройки и калибровки систем обработки данных с привлечение ML и AI - это тоже вполне может быть Low-code, как и задачи программирования AI и баз знаний
Построение алгоритмов специфической обработки данных - ну... отчасти Low-code тут тоже может быть очень полезен, особенно когда нужно создавать асинхронные, параллельные и распределённые системы обработки данных. Но тут пока ещё не всё так гладко как хотелось бы - но в будущем наверняка доля Low-code схем будет быстро расти
Конструирование алгоритмов отражения данных в учёте, да хоть просто для сохранения в СУБД, или задачи конвертации данных - это очень даже Lowe-code задачи - главное, чтобы была продвинутая система консолидации и оптимизации этих схем - чтобы их итоговое исполнение имело как можно меньше повторных обращений к данным и тем де исходным данным или многократным поискам.
Low-code решение задач неплохо помогает когда сразу нужно "убить двух-трёх... зайцев" - и структуры данных обозначить, и методы работы с ними, и интерфейсные элементы задать, и контроль доступа обеспечить и т.д. и т.п.
Задачи построения автотестов и отладки - тоже Low-code freinldy-задачи
Задачи построения автодокументации - тоже Low-code freinldy-задачи
А ещё Low-code - это очень хорошее решение для достижения кросс-платформенности и оптимизации приложений (не ручного тюнинга, когда нужно выжимать максимум, конечно, а возможности без больших усилий создавать вполне оптимальные и кросс-платформенные приложения для широкого круга потребления)
И последнее - Low-code схемы могут быть очень удобны в задачах, требующих сравнение и сопоставление схем (читай - задачи мерджа гит)
Вот такой вот я скептик - набросал кучу вариантов, где считаю Low-code вполне применимым. Но есть большая ложка дёгтя в этой бочке low-code-мёда. А именно:
Средства его формирования. Как выше написал - визуальные средства программирования так и не стали 4-ым поколением языков программирования - вообще не стали популярны, и заняли весьма унитарные и разрозненные ниши. А всё почему? А потому что:
Не так уж быстро с помощью них создаётся готовое решение (простое быстро - посложнее - уже скорость быстро падает)
Есть проблемы с переносимостью такого кода - решения разрозненны и для каждой целевой платформы (исполнения верхнего уровня) создаются отдельно - даже в рамках одной целевой платформы перенос готовых блоково очень ограничен
Проблемы повторного использования кода тоже очень существенны - библиотеки и шаблоны в таких системах редкость, наследование, миксины, интерфейсы, функциональный подход - ещё большая редкость , макросы - почти отсутствуют вовсе везде (я не про макросы - аналоги горячих клавиш и запись действий пользователя - хотя и с ними всё тоже туго; я про макросы повышения уровня абстракции и автогенерации Low-code конструкций)
Актуальны и проблемы адаптивности и повышения уровня абстракции - ни дженериков, ни виртуализации, даже шаблонная подстановка редка
Проблемы анализа готовых схем - их зачастую анализировать (изучать и дорабатывать) бывает куда сложнее, чем просто готовый текст. Печатать их тоже весьма проблемно
Проблема обучаемости - может надуманная - но если для изучения ЯП полно курсов, литературы и сайтов. То для Low-code такой базы нет - все они проприетарный - каждую систему придётся изучать индивидуально на основе той документации, что авторы предложили. В лучше случае будет одна книжка. Но это не сравнится с тем многообразием источников информации, что есть по традиционным популярным ЯП
Возможно есть и другие проблемы - просто навскидку не назову.
Вот поэтому я скептически отношусь к Low-code - да - это здорово - да это может быть полезно- да это может реально ускорять процесс разработки и расширять сферу итогового результата и его качество - но только если это будет идти как довесок к классическому текстовому программированию и текстовому преставлению схем.
И в будущем, как мне кажется, куда эффективнее будет модель именно текстового абстрактного программирования скорее ближе к декларативному - к процессу описания сущностей и отдачи команд - а уже AI cсистемы будут это всё анализировать и генерировать уже готовый традиционный кросс-платформенный программный код - который затем уже будет компилироваться под целевую платформу исполнения. При наборе такого текста AI-ассистент в IDE тоже будет активно помогать. Ну и отчасти можно будет пользоваться готовыми Low-code конструкторами, сниппетами и прочими адаптивными абстрактными шаблонами. Ручной набор программного кода существенно сократится - но ещё очень не скоро сойдёт на нет
СУБД Tarantool и есть Lua - так же как СУБД Oracle Database есть Java, а MS SQL Server как .NET (там вот реально можно на любом языке писать, который компилируется в CLR .NET; ещё есть поддержка языка R). И, например, если не ошибаюсь, СУБД SAP HANA есть поддержка JavaScript подпрограмм (наверянка можно привести и другие примеры СУБД - но я просто про них не знаю). То есть на этих языковых платформах внутри этих СУБД можно создавать то, что некоторые называют костюмными микросервисами - выполняющими гибкую обработку данных на алгоритмах внутри контекста кластера серверов данных СУБД, близко к данным. Тем самым могут брать часть задач сервера приложений. Вот только гибкость прямого взаимодействия через HTTP-сервисы может быть разной.
Это можно использовать, можно не использовать. Можно, как и в данной статье, просто подключаться к этим СУБД через коннектор (например native-клиент), и работать через него, не задействую внутренние микросервисы в СУБД на костюмных "скриптах", и не знаю о том как оно там вообще выполняется, и на чём там оно пишется.
Альтернативой native-микросервисам во многих СУБД всегда были серверные процедуры, обычно создаваемые на расширенном SQL - например T-SQL, PL/SQL. Там есть свои плюсы, минусы и ограничения использования. Но в Tarantool таких процедур нет (если не ошибаюсь).
Активно использовать большие подпрограммы на Lua в Tarantool я бы не стал советовать - т.к. данная СУБД однопоточная - и этот подход будет её замедлять очень сильно. В отличии от названных мной выше других СУБД (и вообще других, не только реляционных, но многопоточных). То есть как сервер приложений Tarantool - это плохая идея - поэтому особо заворачиваться на подпрограммах Lua внутри Tarantool смысла нет - нужна эффективная сложная бакэнд-обработка данных - пишите свой сервер приложений, и работайте из него с Tarantool по принципу, показанному в данной статье. Но какой бы многозадачный сервер приложений Вы не сделали в однопоточность сервера Tarantool всё-равно рано или поздно упрётесь
Самая простая аналогия с проницаемостью первого этапа (380К лет от БВ) - это представить комнату наполненную паром, условно освещаемую со всех сторон (как просто некий куб сектора пространства - а освещение - со всех сторон это просто входящий поток фотонов с соседних секторов). Буде ярко. Смотреть можно. Но ни черта не видно. Проницаемость около нуля. Далее будем откачивать пар - т.е. уменьшать его плотность (или расширят комнату) - видимость будет расти - появится проницаемость.
А если точнее - то вместо пара можно взять скажем инертный газ (к примеру НЕОН) и в той же комнате облучать его со всех сторон электронами - поместить в электромагнитное поле - тоже будет ярко - в этот раз видимые фотоны света будет испускать газ - но так же ничерта не будет видно.
Второй этап (50ML-500ML лет от БВ - когда зажглись первые звёзды) - ставим ультрафиолетовый источник света в центр комнаты - это звезда а вокруг очень плотно напускам неон - будет поначалу очень темно - но со временем комната наполнится источником света - но тут уже сложнее - так как по хорошему нужно удерживать неон вокруг центра света - чтобы не сдерживать его границами помещения - так как реально на этом этапе эта условность уже отсутствует. Но, можно удержать газ электромагнитным полем из центра источника света
Со временем вся эта инфраструктура просто может стать сама кроссплатформенной - к этому должны стремиться разработчики непопулярных хардварных архитектур. То есть самим создавать и продвигать низкоуровневые библиотеки для своей архитектуры - приводя их внешний API к общему знаменателю.
За рамками этого API все тонкости архитектур уже должны быть не значительны - и ЯП более высокого уровня должны иметь поддержку работы с разными архитектурами - когда нужно будет спускаться до этого более низкого уровня в очень редких случаях - а методология разработки должна так и преподаваться/изучаться - что нельзя затачивать тиражируемый алгоритм лишь под одну архитектуру - когда это имеет значение. И новые языки программирования 5-го поколения должны активно это продвигать - стараясь "брать огонь на себя" - самостоятельно (с привлечением AI технологий) решать задачи адаптации особых частей программы сразу под все (настроенные) конечные архитектуры и софтверные платформы среды выполнения - не позволяя скомпилировать программу в промежуточный код - если будут нужны соответствующие уточнения у программиста. Ну а из промежуточного кода под конечную платформу и архитектуру уже будут компилировать специально настроенные бэкэенд-компиляторы, дополнительно проводя тонкую оптимизацию уже под конкретную архитектуру.
И это я ещё не говорил об обязательном фидбэке ЯП 5-го поколения - когда с работающих программ собирается обязательная статистка обработки тех или иных данных и условий эксплуатации - AI-анализатор это всё обрабатывает, накапливает базу знаний (в т.ч. на постоянных тестах DevOps как проводимых самостоятельно самим AI, так людьми) - и затем могут вырабатываться новые более эффективные решения для алгоритмов - после чего они исправляются и пересоздаются новые версии (в т.ч. несколько вариаций под разные условия эксплуатации и разные конечные архитектуры).
Таково моё виденье будущего программирования - кроссплатформенность как и кроссархитектурность будет данностью, а не исключением! Как и многопоточность! Как ориентированность на облачность!
Будущее железа всегда определяется софтом. А коли софту будет не так важно на каком оно железе - то и у железа будет больше вариативности архитектуры. Я это имел в виду - что в будущем даже не популярные хардварные архитектуры могут получить новый толчок развития - когда на них можно будет запускать привычный софт, который ранее привыкли использовать на другой архитектуре.
То есть - развитие софтверной кроссплатформенности подстегнёт развитие разнообразия самих платформ и хардварных архитектур. Того глядишь - настанут временна, когда под разные задачи будут подбирать разные архитектуры (в кластерах серверов) - а облачные ОС будут спроектированы так - чтобы разный софт запускался на разной архитектуре (и даже сразу использовал несколько разных архитектур, доступных в таком облачном кластере). А пользователю а ему вообще в будет это всё незаметно и пофиг на то как этот та всё выполняется (для него это всё будет бесшовной в одном пространстве) - его клиент будет прост - ведь скорее всего он будет просто тонким - и может быть построен на любой архитектуре и использовать любую платформу и ОС.
Многие считали архитектуру x86 непоколебимой (пусть и с кучей проблем и признанием тупиковости развития) - но вот... ещё лет 20 - и этой архитектуре скорее всего настанет хана - её вытеснит ARM (а там того глядишь и другие подтянутся) - Linux уже прекрасно работает, Windows 11 тоже подтягивается, MacOS уже тоже там (не говоря уже о почти всех мобильных устройствах, большей части современного теле-видео-аудио оборудования) - а это не мало - лет через 20 это будет почти весь рынок невоенного потребления (с военным судить не буду, но думаю и там ARM будет в фаворе). Но спустя ещё лет 20 его наверняка начну теснить новых архитекторы - так что это не конец противостояния - оно продолжится и в XXII веке. Но конечному потребителю это всё будет как-то не особо важно - он будет использовать софт на разной архитектуре не замечая этого.
И это означает то - что можно разрабатывать и новые архитектуры , и популяризировать имеющиеся не популярные - главное - чтобы ОС подтягивались и софт был кроссплатформенным! Такой подход изменит будущее - и повлияет на прогнозы автора статьи
Хм.... всё не то - я то думал в статье будет написано как создавать высокопроизводительный код, выполняемый на стороне сервера 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 станет больше - а там и потребители разных платформ расширятся. Но это пока лишь моё мнение. Как он будет на самом деле не знаю - до этих времён ещё пройдёт полвека!