Если Вы интересуетесь миром IT технологий, веб-дизайном, разработкой настольных или мобильных приложений, то у Вас, наверняка, возникает желание не только изучать современные языки программирования, но и знать их историю, интересоваться как же зарождались информационные технологии.
Вряд ли эти знания помогут Вам написать более эффективный код, но они точно помогут расширить кругозор и взглянуть на современный мир IT с другой стороны.
Одним из первых известных истории программируемых устройств стал автомат-гуманоид Аль-Джазари (1206 год), алгоритм действий которого задавался с помощью кулачков и зажимов.
Другим широко известным всему миру устройством стала музыкальная шкатулка, позднее — механическое пианино. Она так же является прообразом программируемых устройств и приводилась в действие посредством металлического цилиндра.
Visual studio. Как создать проект. Первая программа. C++ для начинающих. Урок #1.
Еще один яркий пример — Жаккардовый ткацкий станок Жозефа Мари Жаккара, он был разработан в 1804 году и принцип его действия был основан на работе картонных карт (перфокарт).
Прообразом же привычного нам компьютера стала разностная машина английского математика Чарльза Бэббиджа. Работу над ней он начал ещё в 1822 году и надеялся, что однажды она заменит людей, которые нередко допускали ошибки в навигационных, астрономических и математических таблицах.
Ничего не напоминает? Особенно в свете последнего интереса вокруг нейросетей и ИИ. Да-да, человек постоянно склонен ошибаться и постоянно склонен искать пути минимизации ошибок и оптимизации собственной работы и работы себе подобных.
Прототипом Чарльза Бэббиджа в 1840 году заинтересовалась группа профессоров из Турина. Математик был приглашен итальянским правительством на встречу с военным инженером Луиджи Менабреа, который взял у изобретателя интервью касаемо принципиальной схемы разностной машины. Результатом этой встречи стала опубликованная статья на французском языке.
Графиня Ада Лавлейс, дочь лорда Байрона, главным увлечением которой являлись точные науки — математика и механика, поддерживала контакт с Бэббиджем и параллельно переводила статью на английский. Причем перевод был дополнен развернутым комментарием самой графини, описывающим алгоритм определения последовательности Бернулли средствами логарифмической машины.
Она считала, что в будущем такой аппарат сможет не только производить математические преобразования, но и обрабатывать ту информацию, которую в него заложат. В итоге она смогла впервые описать прототип вычислительной машины и даже создать для него программу.
Ее алгоритм вычислял числа Бернулли, то есть последовательность рациональных чисел, которые возведены в одну и ту же степень. А ещё Ада ввела такие понятия, как “цикл” и “ячейка”, без которых уже сложно представить современный лексикон IT специалиста.
Как появился компьютер История развития ЭВМ
Она описала необходимые элементы любой вычислительной машины:
- память для хранения числовых значений
- блок управления, через который пользователь задает машине, какие задачи выполнять
- устройство для кодирования цифровых данных, перфокарты
- блок ответственный за выполнение расчётов
- устройство для просмотра результатов.
Несмотря на такое подробное описание, первые ЭВМ появились лишь спустя 100 лет, так же, как и прототип первого языка программирования высокого уровня.
Как известно, всех поставленных целей Бэббиджу достичь не удалось, прототип так и не был собран, но он сделал главное – указал направление развития компьютерного мира, которое с упоением подхватила Ада Лавлейс, но которое мировое сообщество оценило, к сожалению, далеко не сразу.
Ценность вклада совместной деятельности Лавлейс и Бэббиджа сообщество признало лишь в 20-м веке в ходе активного научно-технического прогресса, которое активно продвигаем и продолжаем и мы с Вами.
#информационныетехнологии #бизнес #it #история
Источник: tenchat.ru
Как была создана первая программа
Будь в курсе последних новостей из мира гаджетов и технологий
iGuides для смартфонов Apple
Как первый в мире чат-бот приобрел черты искусственного интеллекта, и что из этого вышло
Егор Морозов — 24 ноября 2019, 13:35
Между 1964 и 1966 годами Джозеф Вейценбаум, немецко-американский ученый-компьютерщик из лаборатории искусственного интеллекта Массачусетского технологического института, разработал первого в мире чат-бота.
В то время уже существовало несколько элементарных генераторов цифровых языков — программ, которые могли выдавать несколько согласованных строк текста — но детище Вейценбаума было первой программой, специально предназначенной для взаимодействия с людьми. Пользователь мог ввести какое-либо утверждение или набор утверждений на своем обычном языке, нажать клавишу ввода и получить ответ от машины. Как объяснил Вейценбаум, его программа сделала «возможными разговоры на естественном языке между человеком и компьютером».
Он назвал программу Элиза в честь Элизы Дулиттл, героини пьесы «Пигмалион» Бернарда Шоу, простой женщины из рабочего класса, которую обучали языку высшего сословия. Элиза была написана для 36-битного IBM 7094, раннего транзисторного мэйнфрейма, на языке программирования MAD-SLIP, который Вейценбаум разработал специально для этой цели.
Поскольку компьютерное время было ценным ресурсом, Элиза могла работать только через систему разделения времени: пользователь взаимодействовал с программой удаленно через электрическую печатную машинку и принтер. Когда пользователь набирал предложение и нажимал клавишу ввода, на главный компьютер отправлялось сообщение. Элиза сканировала сообщение на наличие ключевого слова и использовала его в новом предложении, чтобы сформировать ответ, который после этого отправлялся обратно, распечатывался и прочитывался пользователем.
IBM 7094 — «мозг» Элизы.
Чтобы поощрить постоянный диалог, Вейценбаум разработал для Элизы имитацию разговорного стиля, пародирующего общение с психотерапевтом. По большей части программа просто перефразирует утверждения пользователя, превращая их в вопрос («У меня болит голова» — «Почему вы говорите, что у вас болит голова?»). Также она способна реагировать на некоторые ключевые слова, переходя от частного к общему («Мой отец меня ненавидит» — «Кто ещё из семьи вас ненавидит?»), и задавать простейшие уточняющие вопросы («Приведите пример»).
Вот пример реального «разговора» между Элизой и человеком:
Человек: Все мужчины одинаковы.
Компьютер: В ЧЕМ?
Человек: Они всегда заставляют нас делать что-нибудь по поводу и без повода.
Компьютер: ВЫ МОЖЕТЕ ПРИВЕСТИ КОНКРЕТНЫЙ ПРИМЕР?
Человек: Ну, мой парень заставил меня прийти сюда.
Компьютер: ВАШ ПАРЕНЬ ЗАСТАВИЛ ВАС ПРИЙТИ СЮДА.
Человек: Он говорит, что я в депрессии большую часть времени.
Компьютер: МНЕ ОЧЕНЬ ЖАЛЬ СЛЫШАТЬ, ЧТО ВЫ ВПАЛИ В ДЕПРЕССИЮ.
Человек: Это правда. Я несчастлива.
Вейценбаум выбрал для Элизы такой способ общения, потому что создавалось впечатление, что компьютер понимает сказанное, при этом не предлагая ничего нового для разговора. Это создавало иллюзию понимания и вовлеченности всего за 200 строк кода.
Чтобы проверить способность Элизы общаться с собеседником, Вейценбаум приглашал студентов и коллег в свой кабинет и позволял им поболтать с машиной, наблюдая за их реакцией. Он с некоторым беспокойством замечал, что во время их краткого общения с Элизой многие пользователи начали формировать эмоциональную привязанность к алгоритму. Они открывались машине и признавались в проблемах, с которыми сталкивались в своей жизни и отношениях.
Еще более удивительным было то, что это чувство близости сохранялось даже после того, как Вейценбаум показывал, как работает машина, и объяснял, что на самом деле она ничего не понимает. Вейценбаум был очень обеспокоен, когда его секретарша, которая наблюдала, как он программировал Элизу с нуля на протяжении многих месяцев, настояла, чтобы он покинул комнату, для того чтобы она могла поговорить с Элизой наедине.
Но, конечно, бывали и исключения. В зависимости от того, как человек вел беседу, иногда возникали забавные ситуации, когда увлечённый пользователь через несколько минут убеждался в отсутствии у машины понимания сути вопросов. Всё происходило из-за того, что человек придает каждому слову смысл, а машина интерпретирует слово как символьные данные.
Для Вейценбаума этот эксперимент с Элизой заставил его усомниться в идее об искусственном интеллекте, предложенной Аланом Тьюрингом в 1950 году. В своей статье, названной «Вычислительная техника и интеллект», Тьюринг предположил, что если компьютер может поддерживать живое общение с человеком в письменном виде так, что человек не поймет, что он общается с машиной, то можно считать, что компьютер обладает искусственным интеллектом — идея, которая стала основой знаменитого теста Тьюринга.
Но Элиза продемонстрировала, что убедительное общение между человеком и машиной может иметь место, даже если понимание идет только с одной стороны: наличия симуляции интеллекта, а не самого интеллекта, было вполне достаточно, чтобы обмануть людей. Вейценбаум назвал это эффектом Элизы и считал, что это тип «бредового мышления», от которого человечество будет коллективно страдать в цифровую эпоху. Это открытие стало для Вейценбаума глубоким потрясением, которое определило его дальнейшую интеллектуальную траекторию в течение следующего десятилетия.
Джозеф Вейценбаум, «отец» Элизы.
В 1976 году он опубликовал книгу «Вычислительная сила и человеческий разум: от суждения к расчету», в которой долго размышлял над тем, почему люди готовы верить, что простая машина способна понять их сложные человеческие эмоции.
В этой книге он утверждает, что эффект Элизы означает более широкую патологию, поражающую «современного человека». В мире, завоеванном наукой, технологиями и капитализмом, люди привыкли считать себя изолированными винтиками в большой и безразличной машине. В таком ограниченном социальном мире, рассуждал Вейценбаум, люди настолько отчаянно нуждаются в поддержке, что готовы отбросить в сторону свой разум и суждения, чтобы поверить, что программа действительно заботится о них и может помочь им с их проблемами.
Вейценбаум провел остаток своей жизни, развивая эту гуманистическую критику искусственного интеллекта и цифровых технологий. Его миссия состояла в том, чтобы напоминать людям, что их компьютеры далеко не так умны, как о них часто говорят. И хотя временами казалось, что они могут говорить, на самом деле они никогда не слушали.
Источник: www.iguides.ru
Эволюция в вашем кармане: как развивались мобильные приложения
Когда-то людей удивлял плеер в телефоне, а теперь и дополненная реальность в смартфоне кажется нам нормой. Технический директор FINCH, Дмитрий Хайретдинов расскажет историю зарождения и развития mobile, какими были первые приложения, и как появились современные инструменты разработки.
WAP и первое подключение к интернету
WAP (Wireless Application Protocol) появился в 1998 году, и именно он объединил интернет и мобильную связь. Теперь можно было встроить в телефон браузер, установить соединение с серверами и получить данные на устройство.
Одним из первых телефоном с WAP-браузером был Nokia 7100, который выпустили в 1999 году. Тогда же начали появляться компании, разрабатывающие продукты специально для мобильных устройств.
WAP дал людям не только игры, но и возможность читать новости с мобильного, пользоваться электронной почтой, загружать карты и даже бронировать билеты. Для этого создавались WAP-сайты со специальной разметкой для мобильных экранов. Это были простые страницы из текста и ссылок, почти без картинок.
В то время компании еще не оценили телефоны как способ коммуникации с клиентами, поэтому таких решений было катастрофически мало.
Например, Ericsson сделали путеводитель Michelin: через WAP была доступна база из 60 000 отелей и ресторанов Европы. Еще несколько примеров использования WAP для бизнеса приведены в White Paper Nokia 1999 года:
- Клиенты Deutsche Bank и Visa International могли получать информацию о последних транзакциях, просматривать баланс и оплачивать счета;
- Пассажиры авиакомпании Finnair могли бронировать билеты и получать информацию о рейсах.
Первая открытая ОС для разработчиков
В 2001 Symbian стала открытой операционной системой, и в это же время появилась Nokia 7650, на которую можно было устанавливать приложения от сторонних разработчиков. Это должно было стать прорывом на рынке, но бума не случилось из-за сложностей разработки и ограниченных возможностей смартфонов.
У разработчиков был бедный выбор средств разработки для Symbian. Основной язык С++ был сложным в изучении и компиляции. Приходилось изворачиваться, чтобы написать приложение, которое было бы совместимо с большинством устройств на Symbian. Также многих отпугивала необходимость покупки сертификатов безопасности для подписи приложений.
Без сертификата приложение не запускалось вообще или сильно страдало в функционале
В это же время развивался рынок Java-приложений. Разработка приложения на Java занимала меньше времени и подходила для Windows Mobilе, Android, bada, Palm OS и BlackBerry OS. В Symbian также поддерживалось подмножество Java — J2ME, но функциональность таких приложений была сильно ограничена, поэтому разработкой на Java под Symbian практически никто не занимался.
В Nokia никак не стремились помогать разработчикам развивать рынок. Все было настолько плохо, что в 2005 году вышла Symbian 9.1, которая была не совместима с приложениями, выпущенными для предыдущих версий. Каждое приложение требовало доработки.
У разработчиков не было нормальной среды для создания проектов, большинство использовали Eclipse, предназначенной изначально для разработки на Java. Nokia выпустили инструмент для разработки на C++ — Carbide на основе Eclipse, но большая часть его возможностей была платной. Лицензия стоила от 300 до 8000 евро, это сильно влияло на конечную стоимость приложения.
При этом развитием самой Symbian никто особо не занимался, больше внимания уделяли новым дизайнам смартфонов Nokia. На рынок выходили новые модели, а саму ОС обновляли примерно раз в год.
Попытки что-то исправить в Nokia начали предпринимать только в 2009 году. Они пытались решить проблемы с недружелюбным API, дать больше возможностей для создания приложений и упростить разработку с помощью фреймворка Qt, затем открыли исходный код Symbian и объявили о создании Symbian Foundation, что должно было помочь популяризировать ОС.
Но это все не помогло собрать вокруг Symbian сообщество разработчиков и партнеров-производителей смартфонов. В итоге ОС не смогла конкурировать с iOS и Android.
Выход iPhone и запуск App Store
В 2007 году Стив Джобс представил миру первый iPhone. Тогда много говорили о возможностях нового смартфона, но никто не говорил, как этих возможностей удалось достичь.
Архитектура iOS была похожа на MacOS, но система была полностью закрытой. Джобс не хотел, чтобы сторонние разработчики могли разрабатывать приложения для iOS, и не собирался открывать SDK. Вместо этого он хотел, чтобы разработчики создавали веб-приложения, и дал возможность создавать браузерные закладки на домашнем экране. Мы знаем это из биографии Джобса, которую написал Уолтер Айзексон.
Полноценный движок Safari уже присутствует внутри iPhone. То есть вы можете создавать изумительные Web 2.0 и Ajax приложения, которые выглядят и ведут себя так же, как родные программы iPhone. И они способны прекрасно взаимодействовать с его сервисами: звонить, отправлять электронные письма, разыскивать местоположение в Google Maps. И знаете что? Для этого не нужен SDK!, — Стив Джобс.
Но пытливые умы взломали файловую систему, начали писать инсталляторы для нативных приложений и заодно — сами приложения. Так появился джейлбрейк.
Позже совет директоров Apple все же убедил Джобса легализовать сторонние приложения. В итоге в марте 2008 года iPhone SDK стал доступен всем желающим, а в июле презентовали App Store. Это означало, что Apple берет на себя дистрибуцию продуктов разработки пользователям.
Стив Джобс презентует AppStore и систему монетизации для разработчиков
App Store стал толчком к развитию индустрии разработки приложений, но проблемой был Objective-C. Язык программирования для iOS кардинально отличался от популярных тогда скриптовых JavaScript и Flash Action Script. Мало кто хотел тратить время на изучение нового синтаксиса, ведь устройства на iOS занимали еще очень маленькую долю рынка, а основная его часть принадлежала смартфонам на Symbian.
На тот момент двигателем прогресса были игры, а разработка приложений — лишь развлечением для специалистов в смежных областях. На продаже игр уже можно было зарабатывать, а спроса на разработку сервисов и приложений для бизнеса еще не было. Компании не были заинтересованы в разработке приложений для клиентов, потому что:
- Бизнес не доверял мобильным технологиям и никто не знал, как их использовать на благо компаний;
- Существовали ограничения смартфонов в отображении, передачи и приеме данных;
- Приложения не подходили для серьезных задач из-за проблем с безопасностью данных.
Проблемы кроссплатформенности: когда всем надо все и сразу
К тому времени мобильный интернет стал доступнее, а в SDK для разных платформ появились решения по безопасности и интеграции. Это был новый этап развития в разработке приложений: от развлечения для народа разработчики перешли к решению задач бизнеса. Но впереди уже маячила другая проблема.
Быстрое параллельное развитие iOS и Android создало двухполярную систему, и разработчикам нужно было поддерживать несколько платформ одновременно. Из кроссплатформенных инструментов были только Flash и обычный мобильный браузер. И то в 2010 году Apple отказались от поддержки технологии Adobe Flash в iOS.
Разработка одного даже самого простого решения под разные платформы уперлась в человеческие, временные и материальные ресурсы. Хотя браузерные технологии были развиты достаточно хорошо, мобильную веб-разработку тормозила низкая производительность смартфонов.
Как все решилось
На помощь пришли библиотеки компонентов и фреймворки для создания приложений на Android и iOS на базе браузерных технологий без использования языков программирования: Xamarin, Cordova, Phonegap.
С их помощью создается подобие мобильного сайта, сверху накладывается платформенный код, который транслирует вызовы от системы к приложению и обратно.
Эти инструменты решили проблемы маленьких приложений с небольшим функционалом и дали возможность бизнесу быстро и за относительно небольшие деньги протестировать свое присутствие на мобильных платформах. Дальше нужно было смотреть в сторону нативной разработки, потому что остро стояли проблемы производительности, потребления ресурсов, отзывчивости кроссплатформенных приложений и «чужеродного» дизайна.
Развитие кроссплатформенных решений: React Native
В 2015 году разработчики Facebook на конференции React.js Conf представили свой инструмент для кроссплатформенных решений — фреймворк React Native. В нем компоненты приложения, написанные на JS, транслируются в нативные Android и iOS. Этот инструмент принципиально отличается от других систем для создания кроссплатформенных приложений:
- Отсутствием WebView и HTML-технологий;
- Отрисовкой интерфейса. В RN её выполняет ОС устройства, а не браузер;
- Отсутствием дополнительной «обертки» кода — вместо нее JS взаимодействует с ОС через специальный мост. Так в приложении используются нативные компоненты пользовательского интерфейса.
Благодаря этим отличиям приложения, сделанные на React Native, максимально похожи на нативную разработку, и у них меньше проблем с производительностью.
Хотя стало проще и лучше, проблемы все равно остались:
- Знаний одного JS все равно не хватит, потому что работу с возможностями мобильной платформы нужно реализовывать через модули на нативных языках;
- Facebook постоянно что-то переписывает в архитектуре RN, поэтому вечно что-то меняется. Новые релизы часто сопровождаются обратной несовместимостью в коде;
- Скорость работы приложений выше, но все еще не на уровне нативных приложений;
- Нативная разработка становится проще.
Производители стараются минимизировать сложности в разработке и пытаются упростить языки разработки. В результате появились более простые Swift и Kotlin.
Swift представили на конференции WWDC в 2014 году. В нем осталось много от Objective-C, но он работает по аналогии со скриптовыми языками. Код определяется типами переменных, а не указателями. Это делает его изучение легче для тех, кто уже владеет каким-либо скриптовым языком.
Kotlin с 2010 года разрабатывала компания JetBrains. Целью было сделать более лаконичный и простой язык, чем Java, в котором уже накопился багаж неудачных решений. С 2017 язык официально рекомендуется для Android-приложений.
Теперь для разработки нативных приложений есть два языка с простым и гибким синтаксисом, при этом они похожи между собой.
Получилось упрощение не только от Objective-C к Swift и от Java к Kotlin, но и от Swift к Kotlin и наоборот. Это гораздо больший шаг к кроссплатформенности, чем разработка приложений на web-view.
Что происходит прямо сейчас
Мобайл — основной канал коммуникации
Если раньше мобайл рассматривали как одну из точек контакта с аудиторией, то теперь во многих сферах он стал даже важнее десктопов.
Компании даже могут отодвинуть сайт на второе место или не делать его совсем, отдав приоритет приложению. Например, у Tinder до прошлого года не было веб-сервиса, а украинский Monobank уместил целый банк в одно приложение — на сайте можно только получить ссылку на скачивание и почитать различные условия по банковским продуктам.
Заказать карту можно только через приложение
Противостояние Native vs Web-view
Когда есть несколько инструментов для решения одной и той же задачи, встает выбор, какой из них использовать. Сейчас при создании мобильного проекта возникает вопрос, делать приложение нативным или использовать браузерные кроссплатформенные технологии.
Есть несколько вещей, которые нужно учитывать, выбирая подход в разработке.
Долгосрочность проекта. Нужно сразу обдумать, возникнет ли необходимость расширять приложение или добавлять в него новые функции.
В нативных приложениях это сделать легче и быстрее, потому что код изначально учитывает все особенности платформы. В случае с Web-view, чтобы добавить функционал, придется тратить время на создание «костылей» и оптимизацию их работы.
Если проект направлен на долгосрочное развитие, нативное приложение — более подходящий вариант. При этом правило работает и в обратную сторону — нативная разработка не подходит для решения маленьких задач. Например, простой раздел с правилами легче сделать на Web-view, потому что не получится просто так сделать текст с нумерованными пунктами, в языках даже нет такого компонента — приходится придумывать «костыли».
Сценарий взаимодействия пользователя и приложения. Если пользователю нужно постоянно пользоваться приложением, важны отзывчивость и нативный интерфейс.
С нативными приложениями удобнее взаимодействовать и пользователю, и смартфону. Они быстрее реагируют и отвечают на действия пользователя, им нужно меньше сетевых ресурсов, а также меньше они нагружают процессор.
Чтобы интерфейс получился интуитивно понятным для пользователя, разработчику нужно просто следовать гайдлайнам Apple и Google. Разработка похожего на нативный интерфейс с помощью Web-view занимает кучу времени, а отличия все равно будут сильно заметны.
Нужен ли доступ к сервисам устройства. В нативном приложении проще реализовать доступ к камере, микрофону или геолокации. Средствами Web-view это тоже возможно, но тогда придется искать возможность оптимизировать нагрузку на процессор. Кстати, это не всегда возможно, в Web-view нет готовых оптимизированных компонентов и приходится каждый раз что-то изобретать. Сначала для того, чтобы что-то работало, а потом — чтобы это что-то не «съедало» батарею смартфона.
Бюджет. Считается, что кроссплатформенная разработка дешевле. Вместо двух приложений нужно разработать всего одно. Это работает с простыми приложениями, но если речь идет о сложных продуктах с множеством функций, то нативная разработка может оказаться выгоднее.
Время. Бывает, что в приоритете скорость, а не качество и функционал. Если нет времени ждать и нужно хоть что-то, используют кроссплатформенные решения.
Когда нужно приложение, которое можно развивать и которым будут пользоваться чаще раза в год, лучше запланировать более поздний запуск и сделать нативным.
Наличие API для бэкенда. Если API есть, это уже шаг в сторону нативки. Необходимость делать API увеличивает цену и срок нативной разработки, для Web-view его разрабатывать не нужно. Но тут снова нужно отталкиваться от задач и планов на этот проект. Чтобы развивать приложение в дальнейшем, лучше выделить деньги и время на API.
Необходимость обновлений. Чтобы внести изменения в нативное приложение, его нужно обновить через публикацию в маркете. Получается, что быстро вносить изменения не выйдет. Но зачастую это можно решить обычным планированием или миксом технологий: основную часть сделать нативной, а разделы, где нужно часто что-то обновлять — на Web-view.
История развития разработки приложений показывает, что браузерные технологии изначально начали использовать, чтобы обойти сложности нативной разработки. В реальности нет никакой кроссбраузерности, и использование web-view — это чаще костыль, чем полноценное решение задачи. При этом в каких-то случаях web-view более пригоден для использования. Есть разделы, которые действительно следует писать на web-view: лицензионные соглашения, договора и прочее.
Разработчикам стоит исходить из задач, потребностей и возможностей бизнеса, и использовать те или иные технологии, когда это оправдано. Не привязываться к «трушности» методов, а миксовать все с учетом ограничений так, чтобы приложение помогало бизнесу взаимодействовать с пользователем, а не ограничивало коммуникацию.
Источник: apptractor.ru