Вот, тут я с Вами согласен почти на 100% (замечания будут в конце данного поста) — мне подход структуры кода REACT тоже не понравился — по этой же причине. Но, есть же другие фреймфорки — может там по-другому.
Но тут интересна сама идея — вывести программирование сложной логики как можно более на декларативный уровень. И это можно делать по-разному.
Лично я, вот, считаю, что дизайн-макет сайта всё-таки нужно стараться описывать как можно более целостно — при этом все эти связи стараться описывать в этой структуре. И тут да — дизайнер всё-таки отчасти должен быть программистом — чтобы суметь прямо в макете описывать простые условия и простые обработчики — которые влияют ИМЕННО на дизайн.
При этом вся более сложная логика — и уж тем более связанная с взаимодействием с бизнес-приложением (где должна быть сосредоточена бизнес-логика) — должна быть полностью вынесена из макета — и, желательно, создаваться другими людьми, в т.ч. с активным применением императивного стиля программирования — это уже вне компетенции дизайнера. Он должен только написать либо прямые вызовы этого API, либо подготовить события — на которые сможет подписаться эта внешняя логика уже без его участия (при интеграции).
Естественно, дизайнер может (и должен) опереться на умные дизайн-компоненты, которые он будет размещать в макете — и вот эти компоненты, уже да, могут и свой код финальный HTML генерит, который дизайнеру не будет виден. Вот ту важно делать такую интеграцию наиболее прозрачной — чтобы именно дизайнер мог активно повлиять на нюансы генерации этого код, напрямую связаны с итоговым дизайном. То есть такие компоненты должны быть очень гибко настраиваемыми с одной стороны, а так же, должен быть какой-то отдельный режим просмотра макета — где такие компоненты смогли бы развернуть дизайнеру код, который они генерируют (хотя бы формальный, не рабочий, но отражающий суть внутренней логики, со всеми ветвлениями) — чтобы он смог как раз-таки его проанализировать.
Замечание1: Пример выше на REACT это не совсем ООП подход — (объектов то там практически нет) — это больше шаблонный подход с кодогенерацией. Но при этом с автоматической генерацией событий изменений в данных к их обработчикам — обновляющим эти данные. Такого нет даже в классическом ООП. Даже АОП не обеспечивает такой гибкости (хоть и немного похож на данный стиль). И, кстати, в ООП таких возможностей очень не хватает даже в обычном программировании! Это именно декларативный стиль программирования.
Замечание2: Применение классического подхода с размещением всей логики в JavaScript алгоритмах дизайнерам не поможет тем более — т.к. там может быть спрятано много логики дизайна именно в императивном стиле кода JavaScript — который дизайнерам воспринимать будет очень сложно. Плюс, сейчас JavaScript активно занимается генерацией и модификацией HTML страниц — что совершенно не добавляет прозрачности для анализа HTML макета дизайнеру. Так что REACT (и, надо полагать, другие фреймворки в большей степени) тут наоборот — повышает ясность и прозрачность, а не снижает её. Понятно — что для сайтов с простой логикой применять такие фреймворки нет смысла (ну разве те, которые работают по принципу, что я описал в начале данного поста) — они лишь усложнят сайт. Но если сайту требуется много JavaScript логики — то плюсы фреймворков будут очевидны, по сравнения с кодированием практически всего сайта на JavaScript).
Много слов, но ни о чём. Лично я на 100% поддерживаю идею декларативного программирования и сверхвысокоуровневых языков. Просто HTML (а ещё ранее SQL) очень популяризовали эту парадигму в своё время (хотя тогда ещё люди и не осознали всей мощи в данной парадигме в целом, а не только в кругу её узкого применения в то время). JavaScript эту парадигму, наоборот — подпортил — попытавшись вернуть разработку обратно в лоно императивного программирования.
Я не уменьшаю заслуг JavaScriprt- он в своё время очень много дал (в основном за счёт фреймворков, созданных для него) для области web-разработки, да и вообще — для очень многих областей разработки в целом! Но сейчас пришла пора программистам больше обращаться именно к возможностям декларативного программирования. Опускаясь до императивного только для описания отдельных небольших подзадач, или для разработки «нижней» прослойки фреймворков.
И пусть REACT, на мой взгляд, не шибко хорошо демонстрирует эту идеологию, зато, в своё время, он был одним из первых, кто решил вернуть программистов сайтов с императивного пути массового внедрения JavaScript на путь декларативного программирования — который в своё время заложили стандарт HTML, затем CSS, затем XML и активно развивающиеся, с начала нулевых, движки сайтов.
Суть не в киллерах — суть в наставниках — проповедниках — гидах — которые смогут вывести программирование на качественно новый уровень — когда не нужно будет задумываться над тем как это сделать и не нарушить миллион связей — а нужно будет думать о том, что нужно сделать и какие связи настроить!
Неплохая статья для тех, кто не «в танке». Отличная вводная часть и её продолжение. Но портит впечатление лишь самая ключевая часть перед концовкой — где, собственно, показан пример кода на REACT. Код, который, при первом и даже втором прочтении очень сильно похож на расширенный диалект JavaScript(да по сути больше синтаксически им им и является), который просто возвращает в результате код на HTML. Но прямо перед этим кодом говорится фраза «JSX позволяет использовать похожий на HTML синтаксис для описания структуры интерфейса, а также обычный JavaScript» — которая, в купе с преамбулой, что REACT проповедует декларативный стиль программирования и HTML (в отличии от JavaScript) является декларативным, настраивает на то, что далее будет код, больше похожий на декларативный стиль программирования HTML — чем на JavaScript — и с первых же строчек кода примера мы видим почти чистый JavaScript. Да и даллеее — не сразу поймёшь — что это не JavaScipr — который генгерит и взаразает HTML код по шаблону — а именно декларация такой генерации и изменения по событиям. Отсутствие правильной подсветки синтаксиса (особенно в возвращаемых функциями HTML-подобных структурах) только усугубляет восприятие этого кода не как просто программы на расширенном JavaScript. Вот такое восприятия у меня, как у человека, который видит REACT листинг в первый раз в жизни!
Тут не хватает прослойки — когда Вы говорите о декларировании намерений — типа
Существует список значений true / false, называемый checkboxValues, который показывает, какие поля помечены.
Пример: checkboxValues \u003d [false, false, true, false]
То хорошо было бы ниже это всё продублировать ещё раз (ну или разместить там же) — но уже с демонстрацией того — как это выглядит на REACT (хотя бы в виде частичной записи кусочка, в HTML-подобной структуре — что возвращают функции; ну а части — оставшиеся императивными — так и оставить как они выглядят, в JavaScript-подобной записи кода).
Правильная раскраска синтаксиса для новичков тоже очень важна — понятно, что Habr не поддерживает данный синтаксис. И если нет, возможности показать просто раскрашенный текст — то привели бы хотя бы скриншоты листинга — как делали в начале статьи.
Ну и для полноты — было бы неплохо показать — аналогичное исполнение на других декларативных фреймворках — том же Vue — хотя бы финальный полный пример
4K в относительно компактные (не фаблеты) смартфоны уже пробовали запихнуть — тупиковая идея оказалась. Там и FHD (c его ультраширокофрматными производными) реально нужен только в больших смартфонах (от 6.2'' и выше). Иначе — это просто расточительство по разряду батареи (от чего высокое разрешение на некоторых смартфонах можно отключить)
Нет, это не правда — вот у меня на работе сейчас два FHD монитора — но они по 29'' дюймов — получается (на каждом) охват всего поля зрения обоих глаз (включая боковое зрение — когда я смотрю около места их горизонтальной стыковки).
А дома — уже очень давно использую ультраширокоформатник c разрешением экрана 2560×1080 и размером 29'' — вот там я да немного не хватает высоты (хотя я уже привык, но просто чувствую разницу — когда прихожу с работы домой) — для ультраширокоформатников я бы всё-таки сейчас рекомендовал разрешение 3840×1600 и минимум 34'' (лучше 38'' если зрение не очень хорошее) — охват поля зрения будет ещё лучше чем у FHD — без всяких «щелевых взглядов»
16:9 это никакая не танковая щель — это вполне нормальное соотношение. Вот 21:9 будет танковой щелью на мониторах до 23''. К счастью, таких мониторов уже не производят (хотя, от 22'' с них начиналось шествие ультраширокой диагонали) — тренд для 21:9 это мониторы от 27'' и больше — луче 34'' — площадь экрана будет великолепной и по горизонтали и по вертикали — глазам будет комфортно (расстояние до монитора и масштаб отображения информации на оном регулируется уже индивидуально в очень произвольных значениях, прямо «на лету»).
Я программист. И дома уже около 10 лет назад перешёл на ультраширокроэкранный монитор с разрешение экрана 2560×1080 диагональ 29''. Единственное о чём немного пожалел — нужно было брать диагональ больше — ибо когда экран вытягивается по горизонтали -у него снижается высота. Но для обычных людей — это нормальное разрешение экрана — удобное как для работы с офисными текстами (если нужно видеть несколько страниц перед глазами), а уж про удобство работы с таблицами (хоть в EXCEL хоть в базах данных или учетных системах) я вообще молчу — это сверхудобно, как и при работе с почтовыми клиентами (любыми), как и при работе с графикой и программным кодом — когда нужно размещать сбоку дополнительные панели и окошки или просто же сравнивать несколько документов — размещая их по горизонтали, так и при просмотре кино (которые часто выходит в в цифровом доступе в кинотеатральном формате- который шире чем 16:9 и даже шире 16:10) — правда кино я на мониторе уже не смотрю (но раньше смотрел), т.к. наконец-то повесил себе отдельный телевизор дома. Для игр — такое расширение тоже очень хорошо (даже бывают ещё более вытянутые по горизонтали мониторы — но они все с искривлённым экраном — а это ещё та хрень, и вообще отдельная тема). Для игр разрешение 2560×1080 вообще гораздо лучше подходит чем 4K (главное чтобы игра умела его поддерживать), и не нужно покупать топовые видеоускорители в SLI (но средние тут тоже могут не подойти для высокого FPS — но для игры при 120 герц и минимальных 60 кадров в секунду и так понятно что нужна хорошая видеокарта для высокой детализации, но можно смело взять предтоповую предыдущего года). Так что для большинства — 29'' и соотношение сторон 21:9 — это очень хорошо — единственное, где оно бесполезно — это WEB-страницы — т.к. их попросту не оптимизируют для такого расширения — но всё-равно будет очень комфортно.
Но лично у меня зрение не очень хорошее (как, думаю и больше чем половины давних программистов в мире) — я ставлю шрифт покрупнее и уже мечтаю о мониторе в 34'' или даже 38''. И считаю — что будущее программирования именно за такими мониторами с разрешением 3840×1600 — и по высоте уже не будет слишком узко, и текст с мелкими деталями будет хорошо читаться.
Ну а остальное — индивидуально каждый для себя решает масштабированием — ибо Ctrl+левое колёсико мышки для масштабирования сейчас поддерживают практически все программы — что позволяет на лету менять комфортный размер отображаемой информации. Так что нынче — важнее именно размеры монитора и высокое разрешение — как верхняя граница возможностей детализации — а реально, нужную детализацию именно сейчас, решают масштабированием на лету — теперь уже давно нет нужды менять для этого разрешение экрана.
P.S.
А на работе у меня уже так же давно два монитора 1920x1080 (оба классические широкоформатники) — это тоже даёт определённые преимущества. В основном связанные с возможностью более просто организовывать рабочее пространство — размещая разные окна на разных мониторах, так чтобы они не перекрывали друг друга — но это скорее недостатки ОС — которая пока не оптимизирована для удобного и быстрого размещения нескольких окон на одном рабочем столе одного монитора — окна так и норовят занять площадь больше чем требуется- перекрывая другие.
Дома — правда я иногда использую специальное ПО (от монитора) упрощающее процесс прилипания окон к нужным областям — но у него тоже есть свои недостатки (хочется большей гибкости в настройке).
P.P.S.
Вообще — в идеале — это для разработки и/или дизайна — надо иметь два монитора. Хотя бы один ультраширокофоматник — а второй хотя бы просто широкоформатник. Это позволяет на ултраширокоформатнике размещать основное окно редактора и все самые важные инструментальные панели/окна. А второй монитор использовать только при необходимости размещение доп окон с доп материалами. Да хоть — просто текст ТЗ или окно сервисдеска, или окно браузера — где что-то ищется, читается и т.п. Хотя некоторые окна из основного окна редактора я тоже часто выношу на второй монитор. Обычно когда дело доходит до визуального программирования форм или работы с графикой. Но бывает так нужно и при работе с длинными текстами — я вообще не сторонник писать тексты строго в узкую колоночку — но и длинные строки применяю только по большой необходимости (обычно когда типы имеют длинные пути или много директив, или сбоку написан длинный комментарий — тут ультраширокоформатный монитор очень хорошо помогает, как и продвинутая мышка — с боковым колёсиком для горизонтальной прокрутки — использую её и дома и на работе у меня недавно тоже такая мышка появилась)
Так что жаль — что ни в статье (кроме первой фотографии), ни в голосовании нет ни какого упоминания об ультраширокоформатных мониторах! Как нет и рассуждений о будущем переходе к более высоким разрешениям — 8K и выше — ведь именно такую тенденцию сейчас диктуют производители телевизоров (а некоторые ставят себе вместо мониторов — как раз телевизоры — из-за больших экранов и высоком разрешении). Ну а Apple — вообще (хоть и идёт несколько своим путём по стандартам разрешения экрана — об этом тоже ни слова в статье нет), но тоже сторонница распространения высокого разрешения на своих мониторах
P.P.P.S.
И хотя я считаю что будущее в программировании за разрешение 3840×1600 — оно может и не настать (или быть недолгим). Ибо контр-трендом может стать либо VR (AR) — либо смещение программирования в сторону его упрощения — когда не нужно будет писать длинный программный код и держать кучу открытых окон с инструментами — а лишь давать короткие инструкции для AI ассистента. Впрочем до этого ещё пол века — не меньше. Может и успеет прийти разрешение экрана 3840×1600 в массы хотя бы узких специалистов!
«Первый внос» — конечно сказано по существу — но лучше поправить опечатку
А в остальном — не так уж понятно — в чём тут конкретная польза, по сравнению с другими ипотечными калькуляторами в сети (причём браузерными — что удобно, хотя тут как смотреть — ведь данное решение позволяет легко сохранять расчёты). Так в чём же преимущества (кроме сохранения)
Поточнее учесть страховые взносы — а надо ли? Аппроксимации в 1% +- пару десятых — вполне достаточно — разница уточнения не существенна при принятии решений?
Учесть ремонт и другие фикс платежи — а надо ли — ведь они константы в них нет динамики. Хотите учитывать периодический ремонт… ну это уже экзотика — хотя да, вижу что цель решения — расчёт стоимости владения — но так уж это нужно большинству? Ну понятно — можно же делать и для меньшинства.
Учитывать коммунальные платежи — может и полезно? До сдачи в аренду? А где же тогда учет доходов — от аренды, хотя бы гипотетических?
А где досрочные погашения? Это куда важнее всей мишуры с не ипотечными расходами?
Где оценка инфляции? Ведь это тоже важно?
А почему у графика именно такое представление? Лично мне вот, оно показалось не шибко удобным.
А вообще — если уж делать продвинутый ипотечный калькулятор — то нужно делать интеллектуальный калькулятор — которые не просто по паре (пусть и хитрых) формул посчитает графики, а рассчитает наиболее оптимальные сценарии вложения средств — т.е. вводишь исходные персональные данные как стоимость квартиры, ежемесячный доход (вернее ту часть, что планируется выделять на ипотеку — иначе ещё и семейные расходы нужно будет учитывать), текущие средства, и, при желании, уровень затрат на ремонт (т.е. вводя чисто индивидуальные показатели). А программа (причём на глобально накапливаемой статистики, вероятностного прогнозирования и текущих средних показателей по стоимости тех или иных услуг (тут можно ещё регион указать, может и банк/банки — где планируется брать ипотеку)) — рассчитывает несколько сценариев наиболее эффективного вложения данных средств (в том числе в динамике; да ещё и банк с программой подберёт — если он не был зафиксирован), с расчётом предполагаемой вероятности данного сценария и с возможностью детализировать иные вероятностные исходы, с соответствующими расходами, по каждому сценарию.
Вот это была бы да — революционная вещь! Полезная!
А так — ничего особенного, уж извините…
Даёшь компилятор из LLVM в opCode 1С? Ну, правда LLVM это регистровая машина, а 1С — стековая — но, вроде бы это не помеха, разве что с оптимизацией доступа к памяти будет лажа.
Ну а ещё — прикольно было бы свой компилятор для расширенной версии языка сделать! Чтобы не жаловались те, кто считает 1С не достаточно высоуровневым языком — ведь по сути, большая часть высокоуровневых абстракций современных языков — это лишь обёртки над примитивными структурами данных и процедурным стилем программирования! Ну разве что многопоточность требует поддержки со стороны ядра среды выполнения (стековой машины); ну и некоторые другие низкоуровневые штучки — упирающиеся отсутвие низкуровневого API (хотя в 1С это как раз можно расширить через нативные внешние компоненты, создаваемые на С++ — пусть и с некоторой потерей производительности — на кросс-вызовы). Ну а многопоточность — да — краеугольный камень в 1С (я не о фоновых заданиях — что больше сравнимы с фоново выполняемыми сервисами, причём только в серверном контексте, чем с потоками). Ну если не с многопоточностью, то с асинхронным программированием уж точно можно было бы поэкспериментировать — например как это сделано в Го с горутинами, или в Котлин с корутинами. Да на крайняк — сделать как в C# с задачами и async/await — но без многопоточности — то есть эмулировать асинхронность путём реализации гибкого управления стековым выполнением кода в одном потоке — конечно это идея сложная — и я тут просто так о ней написал — вдруг найдутся страждущие экспериментаторы!
А, вот, иные современные расширения для языка 1С сделать куда проще — хоть инициализаторы коллекций, хоть классы, с интерфейсами, свойствами и наследованием ввести, хоть, делегаты с анонимными функциями, функциями высшего порядка, хоть лямбда функции, и другие элементы функционального программирования. Хоть интегрировать контрактное программирование в платформу с динамической типизацией.
И сделать, наконец, поддержку вложенности модулей, структурные реквизиты, и наследование метаданных — хотя это уже напрямую к языку не относится — хотя вполне реализуем и на текущем движке платформы (правда тут и препроцессинга хватило бы).
Ну про макросы и расширенный препроцессинг — я промолчу уж — это задачи уже не для расширенного компилятора а, тоже, для препроцессора!
Застой в IT случился ещё с 2010 года (аккурат после глобального финансового кризиса — не не знаю, повлияло ли это существенно на сам застой), и этот застой продолжается до сих пор. И, в большой долей вероятности, будет продолжаться ещё и следующее десятилетие. Ни одной действительно прорывной IT технологии за прошедшие 10 лет не произошло (я не о теории, а о реальной инженерной практики, которая не только пришла в массовый сектор но и закрепилась там). В гейменен всё аналогично — со времен появления универсальных шейдерных блоков — идёт тупое линейное наращивание мощностей (причём достаточно медленное, не то что в 80-х и 90-х). Никаких прорывов ни в технической части, ни в части геймдизайна — барахтаемся на уровне первого десятилетия XXI века.
VR — очень перспективен — но не раньше чем через 30 лет — пока технологии не позволяют сделать его качественным — если разрешающую способность экранов для шлема ещё можно за 10 лет довести до париемлемого уровня — то вот с вычислительными мощностями всё туго — а без них, детальную картику просто не потянуть, но главная проблема в другом — в лагах -они чудовищны и это рассинхрон у многих вызывает неприятные ощущения и тошноту. Да и провода шлемов тоже очень сковывают движения — а без них пока нет возможности подать хотя бы питание, а современные батареи — очень слабы — и пока нет коммерсеких наработок на ближайшее десятилетие для исправления этой проблемы — но за 30 лет думаю справятся. VR через линзы и смартфон — это вообще убожество — максимум на что его хватает — это фильм один посмотреть (тут не нужны мощности) — и все смартфон разрядится а глаза и голова устанут.
AR имеет ещё больше проблем (+ все проблемы VR да ещё более более усугублённые) — комфортного проецирования на сетчатку глаз так и не сделали и вряд ли сделают в обозримом будущем. Ну а этические проблемы и законодательные ограничения на съёмку — тут готовы почти похоронить эту технологию (оставив её только специалистам и для домашнего применения). Хотя в виде забавных приложений для смартфонов AR вполне ещё может продолжать развиваться в следующем десятилетии.
3D в целом — оно ушло из TV по причине малой порулярности — ну не смотрится оно дома на небольших экранах, да и технологии развития TV пошли в сторону технических решений, мешающих развивать 3D — так что тут теперь дело только за VR. И да, контент 3D который сейчас снимают — это просто ужас — Аватар был бесподобен — но его отрендерили в true-3D — а что сейчас крутят в кинотеатрах под видом 3D — это просто жесть — компьютерный монтаж и обработка исходных плоских 2D картинок для получения квази-3D эффекта — тошнотворное зрелише не то что дома, даже на большом экране в кинотеатре. А снимать весь фильм в 3D — очень дорого и сложно — увы — но, думаю за 30 лет эта ситуация изменится (но не за 10) — когда кинопродукцию на 90% будут производить как Аватара — т.е. рендерить в true-3D с кинематографическим качеством (чтобы не выглядело мультяшным). Тогда снимать особо и не придётся — актёров будут оцифровывать целиком и создавать 3D модель. AI смарт помошники тут будут в помощь — будут помогать делать высокодетализированный и высокоанимированный рендеринг. Вот эта технология начнёт наберать обороты уже в следующем десятилетии — но всё пик будет только лет через 30. Аналогично AI будет помогать делать игры — выполняя много рутиной работы. Особенно в дизайне 3D и графике. Ну, помогать кодить тоже будет — но развиваться все это будет очень постепенно!
А вот AI в играх может наконец-то получит революционный прорыв, основанный на машинном обучении — но вряд ли в 20-х годах это будет носить массовый эффект.
Управление силой мысли тоже будет развиваться — но вряд ли существенно продвинется за 10 лет — альтернативой обычным механическим манипуляторам не станет (но инвалидам станет помощником). А вот 30 лет уже может и прийти в обиход к обычным людям — но не ручаюсь за это.
Стримминг игрового контента будет развиваться дальше — но вряд ли существенно потеснит другие платформы — скорости интнета пока не достаточны — в первую очередь из-за высоких лагов — можно иметь соединение хоть 1000 гигабит — но если периодически будут лаги на несклько миллисекунд — это наложит полный крест для высокоактивных игры (типа шутеров и симуляторов) — и перспектив к решению этой проблемы пока вообще нет. Так что идея игрового стриминга может вообще оказаться безперспективной. Это вам не кино стримить — где нет интерактивности и пол фильма можно легко просто закешировать у потребителя в периоды между перерывами в связи
Странно, что ни слова в статье нет про то, что комментарии в XXI уже стали умнее чем были (ну по крайней мере в некоторых IDE), хотя бы за счёт поддержки тэгов и некоторых других техних форматирования текста в комментариях для обеспечения:
1. Автогенерации документации
2. Автозаполнения контекстной подсказки описанием функции (объекта...) и формата её API (причём особенно это эффективно в языках, не имеющих никакой статической типизации), причём в некоторых IDE там уже можно и гиеперссылки видеть для перехода к упомянутым типам.
3. А ещё есть специальные комментарии, обслуживаемые IDE — например TODO разделы и не только они, привязка к задачам и проектам
А ещё через тэги к комментариях можно реализовывать расширенния для препрцессоров текста (не комментария а когда, находящегося под декарированием такого комментария) — про это тоже ни слова в статье), а так же применяемые в средах версионирования кода
Я так полагаю, вся конструкция распадается на отдельные мелкие скруглённые детали, которые далее легко выводятся естественным путём, уже нигде застревая. Большая часть из них, скорее всего вообще практически полностью распадается в «песок» или расстворяется. Питание — скорее всего органическое, не таксичное. Оптика — тоже не стеклянная — разлагается.
Но, вообще-то, такие таблеточные эндоскопы должны выводиться целиком — т.к. с них потом получают изображение. Их разложение внтури аргонизма — это скорее решение проблемы когда эндоскоп не вышел сам.
Но вообще такая эндоскопия не надёжна и ограничена — лучше классической «шланговой» процедуры пока не изобрели — только она позврляет провести досмотр максимально тщательно — в т.ч. проверить пищевод
Соглсен, но всё-таки в 2012 это было лишь начало пути.
.NET Foundation стараниями Микрософта так и не стал кросс-платформенным
Поэтому именно со времён анонсирования проекта .NET Core Микрософт стал активно развивать и опенс сорс и кросс (не только в рамках .NET Core, просто видимо в это время топ менеджеры окончательно утвердили данный курс вообще в разных областях)
Ну я бы так не сказал… всё-таки более менее регулярно кросс-платформенные опенсорсные инструменты мелкомягкие стали выпускать всего пару лет назад — ну как началась эпопея с .NET Core и вышла версия 2.0
на record из Pascal совсем не похоже, покрайней мере потому, что record из Pascal — это структура, передаваемая и присваиваемая по значению (кстати в статье про это ни слова, даже когда сравнивали с кортежами). А ещё record из Pascal не генерит никаких доп. членов и вообще поддерживает только поля (хотя вот тут могу ошибаться — может что-то сейчас изменилось в актуальных компиляторах, но классический и всякий турбо/борланд паскали это не поддерживали). А вот Data-классы Kotlin на явовский рекорд очень похожи. А case-классы из Scala так вообще, наверное прародители данной концепции! А ещё в C# 8-ом такие record-классы обещали — но так и не завезли пока — хотят вот тут сходство с Java будет максимальным!
Для разных целей? И тем не менее, СlickHouse часто упоминают в срании с Cassnadra и HBase, и на сайте Яндекса есть «замеры» но вот реальных, независимых тестов нет.
Да, с обновлениями и удалениями записей у ClickHouse не всё радужно (хотя и есть решения) — но эти операции вообще узкое место для колоночных СУБД (и не колоночные СУБД их вообще поддерживают; ClickHouse поддерживаются Join — что для колоночных СУБД так же не частая фишка). Вот поэтому интересно сравнить ClickHouse с колоночными якодзунами — в т.ч. на обновление и удаление (ведь всё-таки оно возможно в ClickHouse — хотя в таких СУБД такие операции используются не часто, зачастую просто заменяясь периодическим перестроением таблицы, с удалением лишнего, и видением версий актуализации).
Было бы интересно сравнить с колоночной СУБД Яндекс ClickHouse — пропаганда утверждает, что, как минимум, в ряде случае ClickHouse уделывает и Cassandra, и HBase, и BigTable… ну, по крайней мере, на не террабайтных таблицах!
Да и попробовать отечественный продукт Яндекс ClickHouse было бы весьма патриотично!
Но тут интересна сама идея — вывести программирование сложной логики как можно более на декларативный уровень. И это можно делать по-разному.
Лично я, вот, считаю, что дизайн-макет сайта всё-таки нужно стараться описывать как можно более целостно — при этом все эти связи стараться описывать в этой структуре. И тут да — дизайнер всё-таки отчасти должен быть программистом — чтобы суметь прямо в макете описывать простые условия и простые обработчики — которые влияют ИМЕННО на дизайн.
При этом вся более сложная логика — и уж тем более связанная с взаимодействием с бизнес-приложением (где должна быть сосредоточена бизнес-логика) — должна быть полностью вынесена из макета — и, желательно, создаваться другими людьми, в т.ч. с активным применением императивного стиля программирования — это уже вне компетенции дизайнера. Он должен только написать либо прямые вызовы этого API, либо подготовить события — на которые сможет подписаться эта внешняя логика уже без его участия (при интеграции).
Естественно, дизайнер может (и должен) опереться на умные дизайн-компоненты, которые он будет размещать в макете — и вот эти компоненты, уже да, могут и свой код финальный HTML генерит, который дизайнеру не будет виден. Вот ту важно делать такую интеграцию наиболее прозрачной — чтобы именно дизайнер мог активно повлиять на нюансы генерации этого код, напрямую связаны с итоговым дизайном. То есть такие компоненты должны быть очень гибко настраиваемыми с одной стороны, а так же, должен быть какой-то отдельный режим просмотра макета — где такие компоненты смогли бы развернуть дизайнеру код, который они генерируют (хотя бы формальный, не рабочий, но отражающий суть внутренней логики, со всеми ветвлениями) — чтобы он смог как раз-таки его проанализировать.
Замечание1: Пример выше на REACT это не совсем ООП подход — (объектов то там практически нет) — это больше шаблонный подход с кодогенерацией. Но при этом с автоматической генерацией событий изменений в данных к их обработчикам — обновляющим эти данные. Такого нет даже в классическом ООП. Даже АОП не обеспечивает такой гибкости (хоть и немного похож на данный стиль). И, кстати, в ООП таких возможностей очень не хватает даже в обычном программировании! Это именно декларативный стиль программирования.
Замечание2: Применение классического подхода с размещением всей логики в JavaScript алгоритмах дизайнерам не поможет тем более — т.к. там может быть спрятано много логики дизайна именно в императивном стиле кода JavaScript — который дизайнерам воспринимать будет очень сложно. Плюс, сейчас JavaScript активно занимается генерацией и модификацией HTML страниц — что совершенно не добавляет прозрачности для анализа HTML макета дизайнеру. Так что REACT (и, надо полагать, другие фреймворки в большей степени) тут наоборот — повышает ясность и прозрачность, а не снижает её. Понятно — что для сайтов с простой логикой применять такие фреймворки нет смысла (ну разве те, которые работают по принципу, что я описал в начале данного поста) — они лишь усложнят сайт. Но если сайту требуется много JavaScript логики — то плюсы фреймворков будут очевидны, по сравнения с кодированием практически всего сайта на JavaScript).
Я не уменьшаю заслуг JavaScriprt- он в своё время очень много дал (в основном за счёт фреймворков, созданных для него) для области web-разработки, да и вообще — для очень многих областей разработки в целом! Но сейчас пришла пора программистам больше обращаться именно к возможностям декларативного программирования. Опускаясь до императивного только для описания отдельных небольших подзадач, или для разработки «нижней» прослойки фреймворков.
И пусть REACT, на мой взгляд, не шибко хорошо демонстрирует эту идеологию, зато, в своё время, он был одним из первых, кто решил вернуть программистов сайтов с императивного пути массового внедрения JavaScript на путь декларативного программирования — который в своё время заложили стандарт HTML, затем CSS, затем XML и активно развивающиеся, с начала нулевых, движки сайтов.
Суть не в киллерах — суть в наставниках — проповедниках — гидах — которые смогут вывести программирование на качественно новый уровень — когда не нужно будет задумываться над тем как это сделать и не нарушить миллион связей — а нужно будет думать о том, что нужно сделать и какие связи настроить!
Тут не хватает прослойки — когда Вы говорите о декларировании намерений — типа
То хорошо было бы ниже это всё продублировать ещё раз (ну или разместить там же) — но уже с демонстрацией того — как это выглядит на REACT (хотя бы в виде частичной записи кусочка, в HTML-подобной структуре — что возвращают функции; ну а части — оставшиеся императивными — так и оставить как они выглядят, в JavaScript-подобной записи кода).
Правильная раскраска синтаксиса для новичков тоже очень важна — понятно, что Habr не поддерживает данный синтаксис. И если нет, возможности показать просто раскрашенный текст — то привели бы хотя бы скриншоты листинга — как делали в начале статьи.
Ну и для полноты — было бы неплохо показать — аналогичное исполнение на других декларативных фреймворках — том же Vue — хотя бы финальный полный пример
А дома — уже очень давно использую ультраширокоформатник c разрешением экрана 2560×1080 и размером 29'' — вот там я да немного не хватает высоты (хотя я уже привык, но просто чувствую разницу — когда прихожу с работы домой) — для ультраширокоформатников я бы всё-таки сейчас рекомендовал разрешение 3840×1600 и минимум 34'' (лучше 38'' если зрение не очень хорошее) — охват поля зрения будет ещё лучше чем у FHD — без всяких «щелевых взглядов»
Но лично у меня зрение не очень хорошее (как, думаю и больше чем половины давних программистов в мире) — я ставлю шрифт покрупнее и уже мечтаю о мониторе в 34'' или даже 38''. И считаю — что будущее программирования именно за такими мониторами с разрешением 3840×1600 — и по высоте уже не будет слишком узко, и текст с мелкими деталями будет хорошо читаться.
Ну а остальное — индивидуально каждый для себя решает масштабированием — ибо Ctrl+левое колёсико мышки для масштабирования сейчас поддерживают практически все программы — что позволяет на лету менять комфортный размер отображаемой информации. Так что нынче — важнее именно размеры монитора и высокое разрешение — как верхняя граница возможностей детализации — а реально, нужную детализацию именно сейчас, решают масштабированием на лету — теперь уже давно нет нужды менять для этого разрешение экрана.
P.S.
А на работе у меня уже так же давно два монитора 1920x1080 (оба классические широкоформатники) — это тоже даёт определённые преимущества. В основном связанные с возможностью более просто организовывать рабочее пространство — размещая разные окна на разных мониторах, так чтобы они не перекрывали друг друга — но это скорее недостатки ОС — которая пока не оптимизирована для удобного и быстрого размещения нескольких окон на одном рабочем столе одного монитора — окна так и норовят занять площадь больше чем требуется- перекрывая другие.
Дома — правда я иногда использую специальное ПО (от монитора) упрощающее процесс прилипания окон к нужным областям — но у него тоже есть свои недостатки (хочется большей гибкости в настройке).
P.P.S.
Вообще — в идеале — это для разработки и/или дизайна — надо иметь два монитора. Хотя бы один ультраширокофоматник — а второй хотя бы просто широкоформатник. Это позволяет на ултраширокоформатнике размещать основное окно редактора и все самые важные инструментальные панели/окна. А второй монитор использовать только при необходимости размещение доп окон с доп материалами. Да хоть — просто текст ТЗ или окно сервисдеска, или окно браузера — где что-то ищется, читается и т.п. Хотя некоторые окна из основного окна редактора я тоже часто выношу на второй монитор. Обычно когда дело доходит до визуального программирования форм или работы с графикой. Но бывает так нужно и при работе с длинными текстами — я вообще не сторонник писать тексты строго в узкую колоночку — но и длинные строки применяю только по большой необходимости (обычно когда типы имеют длинные пути или много директив, или сбоку написан длинный комментарий — тут ультраширокоформатный монитор очень хорошо помогает, как и продвинутая мышка — с боковым колёсиком для горизонтальной прокрутки — использую её и дома и на работе у меня недавно тоже такая мышка появилась)
Так что жаль — что ни в статье (кроме первой фотографии), ни в голосовании нет ни какого упоминания об ультраширокоформатных мониторах! Как нет и рассуждений о будущем переходе к более высоким разрешениям — 8K и выше — ведь именно такую тенденцию сейчас диктуют производители телевизоров (а некоторые ставят себе вместо мониторов — как раз телевизоры — из-за больших экранов и высоком разрешении). Ну а Apple — вообще (хоть и идёт несколько своим путём по стандартам разрешения экрана — об этом тоже ни слова в статье нет), но тоже сторонница распространения высокого разрешения на своих мониторах
P.P.P.S.
И хотя я считаю что будущее в программировании за разрешение 3840×1600 — оно может и не настать (или быть недолгим). Ибо контр-трендом может стать либо VR (AR) — либо смещение программирования в сторону его упрощения — когда не нужно будет писать длинный программный код и держать кучу открытых окон с инструментами — а лишь давать короткие инструкции для AI ассистента. Впрочем до этого ещё пол века — не меньше. Может и успеет прийти разрешение экрана 3840×1600 в массы хотя бы узких специалистов!
А в остальном — не так уж понятно — в чём тут конкретная польза, по сравнению с другими ипотечными калькуляторами в сети (причём браузерными — что удобно, хотя тут как смотреть — ведь данное решение позволяет легко сохранять расчёты). Так в чём же преимущества (кроме сохранения)
Поточнее учесть страховые взносы — а надо ли? Аппроксимации в 1% +- пару десятых — вполне достаточно — разница уточнения не существенна при принятии решений?
Учесть ремонт и другие фикс платежи — а надо ли — ведь они константы в них нет динамики. Хотите учитывать периодический ремонт… ну это уже экзотика — хотя да, вижу что цель решения — расчёт стоимости владения — но так уж это нужно большинству? Ну понятно — можно же делать и для меньшинства.
Учитывать коммунальные платежи — может и полезно? До сдачи в аренду? А где же тогда учет доходов — от аренды, хотя бы гипотетических?
А где досрочные погашения? Это куда важнее всей мишуры с не ипотечными расходами?
Где оценка инфляции? Ведь это тоже важно?
А почему у графика именно такое представление? Лично мне вот, оно показалось не шибко удобным.
А вообще — если уж делать продвинутый ипотечный калькулятор — то нужно делать интеллектуальный калькулятор — которые не просто по паре (пусть и хитрых) формул посчитает графики, а рассчитает наиболее оптимальные сценарии вложения средств — т.е. вводишь исходные персональные данные как стоимость квартиры, ежемесячный доход (вернее ту часть, что планируется выделять на ипотеку — иначе ещё и семейные расходы нужно будет учитывать), текущие средства, и, при желании, уровень затрат на ремонт (т.е. вводя чисто индивидуальные показатели). А программа (причём на глобально накапливаемой статистики, вероятностного прогнозирования и текущих средних показателей по стоимости тех или иных услуг (тут можно ещё регион указать, может и банк/банки — где планируется брать ипотеку)) — рассчитывает несколько сценариев наиболее эффективного вложения данных средств (в том числе в динамике; да ещё и банк с программой подберёт — если он не был зафиксирован), с расчётом предполагаемой вероятности данного сценария и с возможностью детализировать иные вероятностные исходы, с соответствующими расходами, по каждому сценарию.
Вот это была бы да — революционная вещь! Полезная!
А так — ничего особенного, уж извините…
Ну а ещё — прикольно было бы свой компилятор для расширенной версии языка сделать! Чтобы не жаловались те, кто считает 1С не достаточно высоуровневым языком — ведь по сути, большая часть высокоуровневых абстракций современных языков — это лишь обёртки над примитивными структурами данных и процедурным стилем программирования! Ну разве что многопоточность требует поддержки со стороны ядра среды выполнения (стековой машины); ну и некоторые другие низкоуровневые штучки — упирающиеся отсутвие низкуровневого API (хотя в 1С это как раз можно расширить через нативные внешние компоненты, создаваемые на С++ — пусть и с некоторой потерей производительности — на кросс-вызовы). Ну а многопоточность — да — краеугольный камень в 1С (я не о фоновых заданиях — что больше сравнимы с фоново выполняемыми сервисами, причём только в серверном контексте, чем с потоками). Ну если не с многопоточностью, то с асинхронным программированием уж точно можно было бы поэкспериментировать — например как это сделано в Го с горутинами, или в Котлин с корутинами. Да на крайняк — сделать как в C# с задачами и async/await — но без многопоточности — то есть эмулировать асинхронность путём реализации гибкого управления стековым выполнением кода в одном потоке — конечно это идея сложная — и я тут просто так о ней написал — вдруг найдутся страждущие экспериментаторы!
А, вот, иные современные расширения для языка 1С сделать куда проще — хоть инициализаторы коллекций, хоть классы, с интерфейсами, свойствами и наследованием ввести, хоть, делегаты с анонимными функциями, функциями высшего порядка, хоть лямбда функции, и другие элементы функционального программирования. Хоть интегрировать контрактное программирование в платформу с динамической типизацией.
И сделать, наконец, поддержку вложенности модулей, структурные реквизиты, и наследование метаданных — хотя это уже напрямую к языку не относится — хотя вполне реализуем и на текущем движке платформы (правда тут и препроцессинга хватило бы).
Ну про макросы и расширенный препроцессинг — я промолчу уж — это задачи уже не для расширенного компилятора а, тоже, для препроцессора!
VR — очень перспективен — но не раньше чем через 30 лет — пока технологии не позволяют сделать его качественным — если разрешающую способность экранов для шлема ещё можно за 10 лет довести до париемлемого уровня — то вот с вычислительными мощностями всё туго — а без них, детальную картику просто не потянуть, но главная проблема в другом — в лагах -они чудовищны и это рассинхрон у многих вызывает неприятные ощущения и тошноту. Да и провода шлемов тоже очень сковывают движения — а без них пока нет возможности подать хотя бы питание, а современные батареи — очень слабы — и пока нет коммерсеких наработок на ближайшее десятилетие для исправления этой проблемы — но за 30 лет думаю справятся. VR через линзы и смартфон — это вообще убожество — максимум на что его хватает — это фильм один посмотреть (тут не нужны мощности) — и все смартфон разрядится а глаза и голова устанут.
AR имеет ещё больше проблем (+ все проблемы VR да ещё более более усугублённые) — комфортного проецирования на сетчатку глаз так и не сделали и вряд ли сделают в обозримом будущем. Ну а этические проблемы и законодательные ограничения на съёмку — тут готовы почти похоронить эту технологию (оставив её только специалистам и для домашнего применения). Хотя в виде забавных приложений для смартфонов AR вполне ещё может продолжать развиваться в следующем десятилетии.
3D в целом — оно ушло из TV по причине малой порулярности — ну не смотрится оно дома на небольших экранах, да и технологии развития TV пошли в сторону технических решений, мешающих развивать 3D — так что тут теперь дело только за VR. И да, контент 3D который сейчас снимают — это просто ужас — Аватар был бесподобен — но его отрендерили в true-3D — а что сейчас крутят в кинотеатрах под видом 3D — это просто жесть — компьютерный монтаж и обработка исходных плоских 2D картинок для получения квази-3D эффекта — тошнотворное зрелише не то что дома, даже на большом экране в кинотеатре. А снимать весь фильм в 3D — очень дорого и сложно — увы — но, думаю за 30 лет эта ситуация изменится (но не за 10) — когда кинопродукцию на 90% будут производить как Аватара — т.е. рендерить в true-3D с кинематографическим качеством (чтобы не выглядело мультяшным). Тогда снимать особо и не придётся — актёров будут оцифровывать целиком и создавать 3D модель. AI смарт помошники тут будут в помощь — будут помогать делать высокодетализированный и высокоанимированный рендеринг. Вот эта технология начнёт наберать обороты уже в следующем десятилетии — но всё пик будет только лет через 30. Аналогично AI будет помогать делать игры — выполняя много рутиной работы. Особенно в дизайне 3D и графике. Ну, помогать кодить тоже будет — но развиваться все это будет очень постепенно!
А вот AI в играх может наконец-то получит революционный прорыв, основанный на машинном обучении — но вряд ли в 20-х годах это будет носить массовый эффект.
Управление силой мысли тоже будет развиваться — но вряд ли существенно продвинется за 10 лет — альтернативой обычным механическим манипуляторам не станет (но инвалидам станет помощником). А вот 30 лет уже может и прийти в обиход к обычным людям — но не ручаюсь за это.
Стримминг игрового контента будет развиваться дальше — но вряд ли существенно потеснит другие платформы — скорости интнета пока не достаточны — в первую очередь из-за высоких лагов — можно иметь соединение хоть 1000 гигабит — но если периодически будут лаги на несклько миллисекунд — это наложит полный крест для высокоактивных игры (типа шутеров и симуляторов) — и перспектив к решению этой проблемы пока вообще нет. Так что идея игрового стриминга может вообще оказаться безперспективной. Это вам не кино стримить — где нет интерактивности и пол фильма можно легко просто закешировать у потребителя в периоды между перерывами в связи
1. Автогенерации документации
2. Автозаполнения контекстной подсказки описанием функции (объекта...) и формата её API (причём особенно это эффективно в языках, не имеющих никакой статической типизации), причём в некоторых IDE там уже можно и гиеперссылки видеть для перехода к упомянутым типам.
3. А ещё есть специальные комментарии, обслуживаемые IDE — например TODO разделы и не только они, привязка к задачам и проектам
А ещё через тэги к комментариях можно реализовывать расширенния для препрцессоров текста (не комментария а когда, находящегося под декарированием такого комментария) — про это тоже ни слова в статье), а так же применяемые в средах версионирования кода
Но, вообще-то, такие таблеточные эндоскопы должны выводиться целиком — т.к. с них потом получают изображение. Их разложение внтури аргонизма — это скорее решение проблемы когда эндоскоп не вышел сам.
Но вообще такая эндоскопия не надёжна и ограничена — лучше классической «шланговой» процедуры пока не изобрели — только она позврляет провести досмотр максимально тщательно — в т.ч. проверить пищевод
.NET Foundation стараниями Микрософта так и не стал кросс-платформенным
Поэтому именно со времён анонсирования проекта .NET Core Микрософт стал активно развивать и опенс сорс и кросс (не только в рамках .NET Core, просто видимо в это время топ менеджеры окончательно утвердили данный курс вообще в разных областях)
Да, с обновлениями и удалениями записей у ClickHouse не всё радужно (хотя и есть решения) — но эти операции вообще узкое место для колоночных СУБД (и не колоночные СУБД их вообще поддерживают; ClickHouse поддерживаются Join — что для колоночных СУБД так же не частая фишка). Вот поэтому интересно сравнить ClickHouse с колоночными якодзунами — в т.ч. на обновление и удаление (ведь всё-таки оно возможно в ClickHouse — хотя в таких СУБД такие операции используются не часто, зачастую просто заменяясь периодическим перестроением таблицы, с удалением лишнего, и видением версий актуализации).
Да и попробовать отечественный продукт Яндекс ClickHouse было бы весьма патриотично!