Hype technology detector. Як визначити, чи буде нова технологія успішною

Мені як підприємцю та інженерові завжди було цікаво, чому одні технології вистрілюють та стають проривними, а інші, незважаючи на всі обіцяні переваги, так і залишаються хайпом, про який забувають через декілька років. Цей феномен ми з бізнес-партнерами спостерігали особисто, коли 2017 року заснували компанію, яка займалася розробкою чат-ботів для месенджерів після того, як Facebook активного просував чат-боти 2016 року. У 2020 році, попри нішеве застосування чат-ботів та їхню підтримку в усіх месенджерах, стало зрозуміло, що хайп закінчився і технологія не виправдала маркетингових очікувань, покладених на неї — це спонукало нас перепрофілювати бізнес.

Проблемне питання про те, що є хайпом, а що ні, я обрав темою дослідження для своєї дисертації, яка мала на меті розробити підхід до оцінки шансів на успіх для технологій, які щойно з’являються на ринку. У цій статті я запрошую до цікавого світу технологічного розвитку та сподіваюсь, що деякі ідеї та думки будуть корисними для читачів.

Опис алгоритму

Отже, після того як був зазначений контекст, у якому проведено дослідження та дано визначення основним термінам, можемо перейти до опису самого алгоритму:

Нульовий крок: перед початком аналізу майбутнього технології важливо пересвідчитись, що ми маємо справу дійсно з технологією, а не сферою знань чи іншою сутністю. Навіть Gartner Hype Cycle інколи включає в свою аналітику щось, що не є технологіями, наприклад: терагерцові хвилі (це фізичний феномен, а не технологія), економіка, data science (це галузі знань, а не технології).

Перший крок: успіх технології залежить від того, яким чином аналізована технологія є кращою від поточного стану справ. Тобто на першому етапі необхідно виявити та визначити технологію конкурента.

У деяких випадках це зробити достатньо просто, наприклад, інтернет-телебачення приходить на зміну кабельному. А бувають випадки, коли все не так просто: з чим порівнювати Image content recognition? Адже попередня технологія, яка б виконувала щось подібне відсутня. І тут важливо трохи пояснити: мова йде не тільки і не скільки про конкурента, а саме про поточний спосіб задовільнити потребу. Якось людство дає собі раду з поточною ситуацією, але важливо чітко зазначити, яким саме чином це відбувається. У випадку з Image Content recognition необхідно порівнювати з аналізом людини змісту зображень.

Другий крок: після наявності чіткої основи є можливість перейти до профайлінгу технології. Спочатку потрібно чітко визначити функціональне значення (functional value) технології. Може трапитись так, що у технології відсутня функціональна цінність, це відповідний червоний прапорець, який потребує дослідження наявності в технології унікальної нефункціональної переваги.

Цей випадок можна проілюструвати на прикладі 2 технологій, які трохи далекі від світу інформаційних технологій: це 4D-друк та надзвукові домашні прилади для чищення. В обох випадках у технологій відсутня функціональна цінність, але у випадку 4D-друку технологія має унікальну властивість — самостійно змінювати з часом властивості фізичного об’єкта, у той самий час все, що виконують ультразвукові прилади для чищення, можуть виконати й інші звичайні пристрої. І саме наявність цієї унікальної властивості і є чинником, який робить 4D потенційно успішною технологією.

Для визначення успіху технології нас цікавить не саме значення функціональної цінності, а те, як воно співвідноситься зі значенням, яке є в конкурента. Тобто ми маємо оцінити, у скільки разів функціональні значення відрізняються одне від одного. Аналогічна історія з іншим параметром — відносними витратами на одиницю функціонального значення (це значення з довгою назвою показує, наскільки витрати для досягнення однієї одиниці функціонального значення вищі / нижчі, ніж у технології конкурента).

Найімовірніше, ці параметри не буде змоги вирахувати точно з багатьох причин (відсутність чіткої інформації, велика кількість модифікацій технології тощо), але для передбачення майбутнього технології достатньо оцінити, в який із проміжків ці відносні параметри попадають. Тут важливо зазначити, що саме перехід до відносних цінностей та витрат дав можливість порівнювати технології з різних доменів та узагальнювати висновки.

Третій крок: всю важку роботу виконано і зараз ми можемо оцінити майбутнє технології за достатньо простими правилами — технологія успішна, якщо:

  • вона має унікальну, а не функціональну перевагу;
  • різниця між відносною функціональною цінністю та витратами перевищує 2 пункти за шкалою, зазначеною в дослідженні.

В усіх інших випадках технологія має не великі шанси на успіх і тим самим є більше хайпом ніж технологією яка принесе реальну користь.

Приклад застосування алгоритму оцінки технології

Для того щоб зробити підхід більш зрозумілим дозвольте розібрати його на прикладі оцінки технології яка згідно дослідженню Gartner набирає популярності та обертів — WebAssembly (Wasm). Якщо дуже стисло то це і віртуальна машина і бінарний формат розроблений для пришвидшення роботи веб додатків.

Нульовий крок — пересвідчуємось що маємо справу з технологією. Так Wasm, є технологією оскільки процес розроблений з використанням наукових та інженерних знань. Значить ми можемо переходити до детального аналізу самої технології

Перший крок — визначаємо технологію конкурента. Wasm є технологією яка забезпечує виконання клієнтського коду в браузері. В цьому випадку JavaScript Engine може бути зараховано як технологія конкурент, так як JavaScript Engine функціонально вирішує туж саму проблему що і Wasm

Другий крок — розрахунок необхідних параметрів для технології. У випадку Wasm визначити функціональне значення достатньо просто — воно відображено навіть в описі самої технології — це швидкість виконання клієнтського коду. Не зважаючи на те що функціональне значення добро визначено, досі не існує єдиної думки на Wasm більш продуктивний ніж JavaScript Engine. Battagline 2021. У свої роботі The Art of WebAssembly: Build Secure, Portable, High-Performance Applications з посиланням на Mozilla foundation зазначив що Wasm показує результати на 10-800% краще ніж еквівалентний код Java Script. В свою чергу De Macedo, Abreu, Pereira, and Saraiva в своєму дослідженні стверджують про 30% покращення порівняно з JS. Консервативно можливо казати про те що так у всіх випадках Wasm покращує швидкість виконання клієнтського коду.

Щодо відносної вартості — основна витратна частина на впровадження технології лягає на розробників браузерів. В свою чергу розробники як мали розробляти клієнтську логіку додатка, так і мають її розробити, тоб то Wasm лишає витрати на одиницю швидкості такими ж самими як і попередня технологія.

Третій крок — виконуємо розрахунки з метою оцінити майбутнє технології. Для зручності заніс всю інформацію про Wasm у таблицю:


Технологія конкурент


JavaScript Engine


Функціональне значення технології


Швидкість виконання клієнського коду


Унікальна не функціональна властивість


Відсутня


Відностна перевага


у 1.5 — 2 рази


Відностна вартість


1 (без додаткових витрат)

Сукупність відносної цінності та відносної вартості (ціннісна перевага є, при однаковій відносній вартості) приводить до заключення що у випадку з Wasm ми маємо справу з перспективною технологією яка займе своє місце на ринку, а не з хайпом

Обмеження та застереження про використання запропонованого підходу

Запропонований підхід, як і будь-яка спроба зробити модель реального світу, має свої обмеження та сфери застосування. Дозвольте поділитися деякими з них.

По-перше, підхід аналізує поточний стан технології. Він не враховує того, що сама технологія може покращитись або можуть з’явитись інші кращі технології. Це буде відповідно впливати на успіх конкретної технології, але цього не можна передбачити (наприклад, 2006 року Gartner пропагував offline Ajax як передову технологію для роботи веб застосунків офлайн, але поява механізмів HTML5, зробила offline Ajax непотрібним).

По-друге, підхід ніяким чином не відповідає на запитання, чи можливо реалізувати технологію, чи ні. Ідея термоядерного синтезу існує з 50-х років минулого століття, але її досі не реалізували в промислових масштабах. І відповідно описаний вище підхід може відповісти на запитання, чи буде термоядерний синтез успішною технологією за умови, що ця технологія може бути реалізована.

По-третє, технологія дуже чутлива до оцінок функціональних значень та витрат, виявлення конкурента та ідентифікації унікальної нефункціональної переваги. Цей аспект потребує покращення у бік уніфікації та стандартизації підходів до оцінки, що може бути предметом наступних досліджень.

По-четверте, відкритим є саме питання, чи 115 технологій — це достатня кількість для того, щоб робити висновки про всі технології. Можливо, наступні дослідження розширять перелік проаналізованих технологій, що призведе до уточнення зазначеного підходу.

По-п’яте, підхід не визначає часових меж, тобто він не відповідає на запитання, коли технологія стане успішною і з якою швидкістю вона буде розповсюджуватись серед продуктів, представлених на ринку.

Завершення

Сподіваюсь, що описаний вище підхід дозволить як мінімум замислитися над чинниками, які є передумовою успіху технології, і як максимум покращити якість прийняття рішень про використання новітніх технологій та відповідних інвестицій у розвиток технологій. Буду радий проаналізувати новітні технології, які цікавлять користувачів: для цього достатньо залишити їхній перелік у коментарях.

P.S. Дякую нашим Силам оборони, які дають можливість досліджувати технології та жити у своїй країні.

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

просто, якщо ви, особливо ви, або знайомі, використовуєте щось, то це не хайп, а якщо ви тільки думаєте про, то якій потенціал у цього є, але не знаєте нікого хто б цім користувався, то це скоріш за все не потрібно.

Взяти ШІ, наприклад, в нього є неймовірний потенціал, але я спілкуюсь з чатом от сили пару раз на тиждень коли є настрій і я не купую доступ за гроші, тобто потенціал є, але якій він насправді ми не знаємо.

Треба знайти таке використовування ШІ, щоб одразу можна було сказати, треба.

Саме так! Кейс ускладняється якщо ти не просто людина, а бізнес чи інвестор. І ти маєш приймати рішення про то інвестувати (гроші, сили, час) в щось типу децентралізованих додатків? І тут має бути якийсь підхід який допоможе прийняти рішення.

це як з бізнесом, ви хочете інструкцію як зробити бізнес якій 100% буде працювати,

такого не існує, вам треба мати конкурентні переваги щоб розуміти як оцінити адекватно активи які більше ніхто не бачить.

найкращій спосіб це находитись в такому оточенні яке дозволяє бачити можливості. Аутсайдері завжди програють, бо не шарять за внутрішні процеси.

наприклад, раніше треба було працювати в Bell Labs, Xerox Parc ну і мати купу друзів тут і там щоб зрозуміти як рухатись далі, ну і треба було б щоб інтернет вистрілів

Як зараз я не знаю, але Zeitgeist мені підказує що технології всім набридлі вже, треба щось новеньке і більш цікаве.

але знов ж таки правил не існує, може бути будь що.

ви хочете інструкцію як зробити бізнес якій 100% буде працювати

дуже цікаво як Ви прийшли до цього висновку ?

найкращій спосіб це находитись в такому оточенні яке дозволяє бачити можливості

буває по різному, буває так що і оточення помиляється, і зараз ми в тому світі де оточень багато.

Zeitgeist мені підказує що технології всім набридлі

Дуже цікаво дізнатись звідки таке відчуття, в моїй умовна військовій бульбашці якраз багато дуже багато цікавості. Умовно хлопці які ще декілька років потому щось будували, зараз виготовляють технологічні вироби та пристрої і цікавіть до технологій різна. В цьому випадку я би не робив узагальнення і дуже цікаво почути на чому базується Ваша думка

Проблема в тому, що такий технічний аналіз, хоча і є корректним, але також неповний. Наприклад він не враховує соціальну складову. Той же вебассемблі — гарна технологія. Але технічно вона так влаштована що весь сорс код вашого просунутого додатку доступний будь-кому. Тобто ви виграєте трохи технічно в перформансі, але програєте бо ваш продукт тупо вкрадуть, ваші ассети з продукту вкрадуть, а розгорнутий продукт зламають. Тому классно звісно що можна в браузері запустити важкий 3Д додаток, але по факту ми бачимо що соціальні проблеми переважили. Ну і навпаки — можна довго робити технічний аналіз продуктів на базі нейронних мереж, але вкладаються в них саме тому що вони дозволяють легально красти чужу інтелектуальну власність і нічого за неї не платити (або копійки в окремих випадках).

Але wasm хоч трошки, але складніше вкрасти ніж звичайний JS. Будь який браузерний код вкрадуть, бо він на клієнті і ніяк не привʼязується до конкретних машин користувачів.

Так, але задачі які ставлять перед вебассемблі трохи інші. А саме запустити наприклад 3Д гру в браузері, або якийсь важкий професійний софт, або якийсь мега навернутий десктопний додаток. (прим. — я тут не в темі сильно, можу помилятись) Тобто додана цінність продукту в цілому переходить з серверної чатини (як у типового веб сервісу), на клієнтську, яка менш захищена. Можна заскрейпити сайт амазон.ком чи ньюйорктаймс.ком, але з цими даними нічого особливо цінного не зробити і конкурента не створити. А якщо хтось опублікує умовно Батлфілд чи Автокад в вебассемблі, то його за годину вже скачають, перезберуть з іншими логотипами і не нудними шпалерами) і викладуть в китайському чебурнеті і не тільки там. А додатково знайдуть вразливості щоб зламати захист оригінальних продуктів і будуть там читерити чи користуватись без ліцензії.

Андрій, дякую що піднімаєш питання соціальної складової. Це дійсно важливо, для мене під час дослідження були велике питання як оцифрувати цю складову і зробити її уніфікованою. Відповідь у дещо спрощеній моделі описаній у пості.
Що до Wasm — JS на стороні кліенту такий же небезпечний як і Wasm, тобто з точкі зору цінності Wasm не втрачає

Дуже цікаво. Мені завжди подобалось розбиратися, чому саме ми використовуємо ті чи інші технології, чому саме зробили так, а не інакше. Тобто історична ретроспектива дуже важлива для розуміння технології і чи стартане вона чи ні.

Моє бачення цього питання — ми дуже давно пройшли «зону початку», коли вибір тієї чи іншої технології відбувається виключно за рахунок її якостей (як то переваги, які вона дає).

Взагалі, в будь-якій новій області (знань, технологій) цей період, «зона початку» — дуже короткий.

Так ось, коли деяка область вже сформувалась, починають бути важливими не тільки і, навіть, не стільки якості самої технології чи продукту, скільки очікування «як воно повинно працювати» та сумісність з вже побудованими системами. Навіть в суміжних та не тільки областях.

Повертаючись до чат-ботів — можна ж зробити свою платформу, орієнтовану на інтерактивну взаємодію. Але навіть при очевидній перевазі в швидкості взаємодії такої платформи (бо її ж можна реалізувати на Rust/С/С++), безпечності, якості UI — скоріше за все вона не стартане просто тому, що ставити ще одну аппку мало хто схоче. В той час як Telegram/FB Messenger вже є. Не дивлячись на питання безпеки (бо дані проходять через сторонні сервери) і на питання обмеження UI бо далеко не все банально підтримується платформою мессенджера.

Те саме можна сказати про будь-яку технологію — розповсюждення літаючих авто стримується, в тому числі, відсутністю інфраструктури. І виключно переваги над попередньою технологією — недостатньо. Бо коли авто замінило коней, все, що було потрібно — замінити дороги (та й то, не відразу) В той час як для авіа транспорту треба буде замінити будівлі для можливості використання даху для посадки (що майже завжди вже неможливо для існуючих будівель) так і щось зробити з ЛЕП та іншою інфраструктурою у повітрі. Щоб поставити авто у конюшню її не треба перебудовувати, в той час як літаюче авто скоріше за все не влізе у гараж чи паркомісце підземного паркінгу.

Та навіть більше — можливо розроблена з нуля акумуляторна батарея буде менше/легше/дешевше для авто, але її все одно збирають з уже наявних форм-факторів акумуляторів, бо переробляти весь технологічний цикл з нуля майже неможливо.

Те саме з процесорними архітектурами — дешевше купити ліцензію на існуючу і зібрати з існуючих «блоків» ніж розробити з нуля. Навіть Apple, з фінансовими можливостями що більші ніж у більшості країн світу — зробила свої процесори на arm.

Я давно прийняв для себе правило, чи буде якась технологія жити, чи ні — як тільки вона починає використовуватись хоча-б 2-3 великими гравцями — вона вже не помре. Як Cobol, наприклад. Щоб там не казали за «вбивцю C» — куди подіти всю ту купу вже наявного коду?

Тож, треба дивитись не тільки на переваги однієї технології над іншій, але й на те, чи — чи зможе вона вписатися в існуючу інфраструктуру замість неї.

Схоже хтось намагається винайти патентоведення.

успіх технології залежить від того, яким чином аналізована технологія є кращою від поточного стану справ

Все б добре, якби не купа прикладів як гірша технологія займала домінуючі позиції на ринку й «ховала» конкурентів завдяки чому завгодно, але тільки не технічним перевагам. Тобто фундаментально так, щоб мати шанси на успіх потрібно буди в чомусь краще. От тільки це «щось» може бути логістика, потрібні ділові контакти, кращий маркетинг і ще 100500 факторів, деякі з яких неможливо передбачити і можна «побачити» тільки ретроспективно...

Дякую за коментар, в даному контексті важливо розрізняти технологію і продукт який побудований на цій технології. Ділові контакти, логістика, маркетинг це все є властивості продукту або компанії яка цей продукт виробляє/просуває.
Буду вдячний за приклад технології яка була краща та програла своїм конкурентам.

Я не думаю, що завжди можна розділити продукт та технологію. Візьмемо, наприклад, Oracle — це цілком конкретний продукт, але завдяки поширенню він починає диктувати розвиток технології СУБД — бо на нього всі рівняються.

Чи, наприклад, хмари. Сама по собі технологія віртуалізації та програмно-конфігуровані мережі — це технологія, але це ще й продукт — і конкретні реалізації можуть бути доволі різними аж до несумісності (я не про взаємодію між хмарами, а про перенесення застосунків між ними), при деякому розмірі чи складності застосунка його майже неможливо перенести між хмарами (скоріше не в технічному сенсі, а економічному — дешевше і швидше буде переписати з нуля)

Так розрізнити продукти і технології важко — дякую що підмітив цей факт
Про твій приклад з хмарою — один із факторів який я розглядав як той що впливає на успіх технології це витрати на зміну інфраструктури (в широкому сенсі), але виявилось що соst/value ratio має більше велике значення. Можливо так стається бо витрати на зміну інфраструктури не прямим чином «сидять» в костах на використання технології. Це требо додатково досліджувати

Betamax був краще VHS, OS/2 була краще за вінду, Motorola 68000 був краще за 8086. Впевнений що півгодини з гуглом дадуть ще купу прикладів...

Дякую! Якщо не проти я то візьму проаналізувати ці кейси. Невелике питання, коли ти кажешь краще — про яку характеристику ти пишешь ?

те що оплачують те і вистрілює

гроші не просто бомажки, це універсальний засіб обміну користі, в самому широкому сенсі

Якісь специфічні вузькі ознаки не мають сенсу, технічна перевага це тільки один вузький вимір

Якщо хтось платить за пехапе — це успішна технологія, але не тому що він чимось принципово кращий за перл. Написали б вордпрес і фейсбук на перл — був би перл досі успішним.

Тепер питання — от коли в останнє ти щось не замовив, бо сайт працював повільно чи тому що він був не на wasm. І чи вирішить кардинально тут wasm щось?
Питання риторичне, бо по всьому світу все і так працює без wasm. Коли перестане і wasm вирішить якусь глобальну болячку — тоді й вистрілить wasm. А до того це буде нішевий солюшен для нішевих юзкейсів чи для ентузіастів

Собсно гайп чи ні варто відрізняти по проблемі яку вирішує або які саме економічного плану бенефіти технологія створює

те що оплачують те і вистрілює

Згоден що гроші важливі, та є багато прикладів коли добре проплачені речі не вистрілювали, візьми Google Class наприклад.

Написали б вордпрес і фейсбук на перл — був би перл досі успішним

Мабуть причина в швидкості розробки(в даному випадку веб-додатків) ? Мабуть це і є функціональна характеристика для мов програмування ?

Нуууу про гроші тут я абстрактно в широкому сенсі, в тому широкому сенсі що якщо убер возить людей собі у збиток роками, то питання революційності убера тут відкрите. Може це просто пірамідою краще назвати? Бо так будьяка шара з красивим додатком у аппстор буде революцією.

Так і з технологіями. Часом компанії вкладаються у маркетинг технологій, щоб у майбутньму був вихлоп. От і пушать вебасемблі так. Чи виллється цей пуш у щось? Ну коли гугль епл чи майкрософт відкриють тисячі вакансій на вебасемблі — мабуть так, а до того буде просто маркетинг і гарні гасла про швидкі космічні кораблі

Мабуть причина в швидкості розробки(в даному випадку веб-додатків) ? Мабуть це і є функціональна характеристика для мов програмування ?

Це насправді глибоко до лампочки усім крім власне програмістів, просто програмістам це неприємно визнавати :) Має бути outcome поза власне програмуванням

Можна з такого боку ще
от приклад з докер чи к8с — за останні 10 років уже в усіх щєлях
Вебасемблі за останні 7 років отримав 0.0% інтернету, десь вранці шукав статистику сайтів, там щось в районі тисяч серед мільйонів

якщо убер возить людей собі у збиток роками, то питання революційності убера тут відкрите. Може це просто пірамідою краще назвати? Бо так будьяка шара з красивим додатком у аппстор буде революцією

Тут мається на увазі бізнес модель умовного убера? Якщо так то перевага цієї моделі перед бомбілами та грачами достатньо очевидна. І скільки грошей не вкладали би умовне «офлайн таксі Павлограда» це не допоможе виграти конкуренцію у умовних уберів, бо бізнес модель має переваги.

Це насправді глибоко до лампочки усім крім власне програмістів, просто програмістам це неприємно визнавати :) Має бути outcome поза власне програмуванням

Інженери (програмісти в тому числі) одні із зацікавлених сторін які приймають рішення про використання технології (я не тільки про конкретний Wasm). На приклад, користувача додатку не дуже цікавить що там з віртуалізацією на сервері, але для інженера (девопаса) це важливе питання. Так само і тут я би не нехтував тією владою яка є у розробників у виборі технологій

О-о-о, доречі. Вдала бізнес-модель (чи просто вдача стати першим) розповсюдження може майже повністю перекрити технологічні недоліки. Viber, як на мене, значно технологічно і функціонально гірше телеграму — але подавляюча більшість обʼєднань, як то ОСББ, шкільні чати, спортивні секції для дітей і таке інше використовують Viber.

Тобто якщо розглядати виключно технологічні та функціональні якості, інколи достатньо бути «достатньо робочим» — все інше зробить відсутність конкуренції (почав першим) чи вдала бізнес-модель.

Важливо зауважити що Viber це продукт, а не технологія. Технологія це мессендери, які вбили СМС — я би таким чином дивився на речі.

Ти піднімаєш важливе питання про швидкість розповсюдження технологій та їх сталу позицію на ринку. Трохи відповів на це в пості вище

Так а чим месенджери відрізняються від СМС? Там навіть мультімедіа були (ММС) — Я б сказав, що тут більше зіграла роль саме бізнес модель — безкоштовність повідомлень. Бо месенджери посунули СМС ще до поширення десктопних клієнтів до них.

Тобто сама технологія обміну текстовими повідомленнями була задовго до месенджерів. І мені здається що тут визначальна саме бізнес-модель — я чудово памʼятаю як наприкінці 90х і на початку 2000х студенти рахували гроші і коли були «безкоштовні» смс — вони активно використовувались. Їх стримувала саме ціна. Навіть незручна клавіатура не була такою вже перешкодою.

Навіть зараз оператори все ще рахують смс за кількістю. В той час як месенджери — ні.

Відрізняються вартістью на 1 повідомлення для 1 людини. В понеділок дам порівння СМС та мессендерів, якщо цікаво

Та ні, не треба, не витрачай час.

Я ж про це і кажу —

більше зіграла роль саме бізнес модель — безкоштовність повідомлень.

ця бізнес модель стала можливою завдяки технологіям і це дещо змінює кут погляду на наявний феномен

А доречі, точно завдяки технологіям, чи завдяки зміні мислення? Бо бувають ситуації, коли технологія як така вже деякий час є, а інерція мислення не дає почати використовувати її по новому.

Наприклад електрона пошта як така була вже кілька десятиріч, але сприймалася саме як пошта. Ідея, що можна спілкуватись майже інтерактивно, прийшла не відразу. Хоча технічно все для цього було.

Так, я згоден, що час проходження електроного повідомлення може бути і великим, але я чудово пам’ятаю, що наприкінці 90-х у більшості навіть думки не виникало, що в більшості випадків спілкуватися інтерактивно — можливо.

Я, правда вже десь у 2005, налаштовував пересилання електроних листів на мобільний телефон як смс. Була така послуга у мобільних провайдерів. І мені дуже подобалось, що я майже відразу отримував повідомлення про нову пошту на телефон. Тобто надсилання з мого комп’ютера в університеті на адресу мобільного оператора було інтерактивним. І ще кілька моїх знайомих теж цим користувались. І навіть сидячи в різних аудиторіях (за компом) чи в сусідніх корпусах могли домовлятися вийти з універу разом через пошту. І це було як месенджер, інтерактивно — консольний агент mail повідомляв прямо у консоль про нове повідомлення — можна було подивитись його та відповісти. Але це не сприймалося як інтерактивний месенджер. Хоча, фактично, було ним.

Були IRC ...

Дуже влучно про інерцію мислення! вона як раз впливає на швидкість розповсюдження технології. Дядько Roger навіть ввів такий термін як дифузія інновацій і написав відповідну книгу. Там він як раз и досліджує що впливає на швидкість розповсюдження інновацій (тут важливо не плутати нову технологію і інновації)

Ви з хлопцями на фізфаку — дійсно молодці, у нас думки в той час були іншим зайняті

Про Wasm:

Функціональне значення технології

Швидкість виконання клієнського коду

Це в першу чергу платформа для запуску. Тобто ви можете портувати свій код на плюсах чи шарпах.

Відностна вартість

1 (без додаткових витрат)

Без витрат чого? Wasm вам дуже дорого обійдеться в проекті.

Можешь розкрити що підвищує вартість використання Wasm в проекті ? Буду вдячен бо наразі не знайшов відповідної інформації

Мається на увазі вартість спеціалістів, які будуть імплементувати, а потім підтримувати це рішення.
Візьмемо наприклад комбінацію Wasm + Rust. Ви отримуєте як мінімум ускладнення архітектури. Потім будете мати довший і важчий білд.
У вас буде сидіти в команді Rust розробник, який буде просити значно більше і робити значно менше ніж пересічний JS розробник. При чому з роками, коли на ринку буде більше людей з такими скілами, ситуація не зміниться, бо технологія достатньо складна.

Найсмішніше це те, що на Wasm уже намагаються засунути Python. Що з першого погляду немає сенсу, але з іншого підказує нам те, чому саме вигідна ця технологія для бізнеса. Відповідіть — інтероперабельність. Тобто всі хочуть, щоб будь-який код написаний ними міг запустити будь-який інший код, або міг бути запущеним іншим кодом на будь-якій вибраній платформі.

Підписатись на коментарі