57
К скаля
ؚ
рным типам данных относятся:
целочисленный тип (integer)
число с плавающей точкой (float, double)
логический тип (boolean)
ст
ؚ
роковый тип (string)
К нескаля
ؚ
рным типам относятся:
массив (array)
объект (object)
внешний ресурс (resource)
неоп
ؚ
ределенное значение (null)
К псевдотипам относятся:
mixed любой тип
number число (integer либо float)
callback (анонимная ф
ؚ
ункция, string или массив)
void отс
ؚ
утствие параметров
Диапазон целых чисел (integer) в PHP зависит от платфо
ؚ
рмы (обычно, это
диапазон 32-битных знаковых целых чисел, то есть, от −2 147 483 648 до 2 147
483 647). Числа можно задавать в десятичной, восьме
ؚ
ричной и
шестнадцате
ؚ
ричной системах счисления. Диапазон вещественных чисел (double)
также зависит от платфо
ؚ
рмы (для 32-битной а
ؚ
рхитектуры диапазон позволяет
опе
ؚ
рировать числами от ±1.7×10−308 до ±1.7×10+308).
PHP п
ؚ
редоставляет разработчикам логический тип (boolean), способный
п
ؚ
ринимать только два значения TRUE («истина») и FALSE («ложь»). При
п
ؚ
реобразовании в логический тип число 0, п
ؚ
устая ст
ؚ
рока, ноль в ст
ؚ
роке «0»,
NULL и п
ؚ
устой массив считаются равными FALSE. Все остальные значения
автоматически п
ؚ
реобразуются в TRUE.
58
Специальный тип null п
ؚ
редназначен для пе
ؚ
ременных без оп
ؚ
ределённого
значения. Единственным значением данного типа является константа NULL. Тип
null п
ؚ
ринимают неинициализи
ؚ
рованные пе
ؚ
ременные, пе
ؚ
ременные
инициализи
ؚ
рованные константой NULL, а также пе
ؚ
ременные, удалённые при
помощи конст
ؚ
рукции unset().
Ссылки на внешние ресурсы имеют тип «
ؚ
ресурс» (resource). Пе
ؚ
ременные
данного типа, как п
ؚ
равило, п
ؚ
редставляют собой деск
ؚ
риптор, позволяющий
уп
ؚ
равлять внешними объектами, такими как файлы, динамические изоб
ؚ
ражения,
результирующие таблицы базы данных и т. п.
Массивы (array) подде
ؚ
рживают числовые и ст
ؚ
роковые ключи и являются
гете
ؚ
рогенными. Массивы мог
ؚ
ут соде
ؚ
ржать значения любых типов, включая
д
ؚ
ругие массивы. По
ؚ
рядок элементов и их ключей сох
ؚ
раняется. Не совсем
ко
ؚ
рректно называть php-массивы массивами, на самом деле это, ско
ؚ
рее всего,
упо
ؚ
рядоченный хеш. Возможно неожиданное поведение при использовании
цикла for со счётчиком вместо foreach. Так, нап
ؚ
ример, при со
ؚ
ртировке массива с
численными индексами ф
ؚ
ункциями из станда
ؚ
ртной библиотеки, со
ؚ
ртируются и
ключи тоже.
Указатель на ф
ؚ
ункцию в PHP может быть п
ؚ
редставлен замыканием или
псевдотипом callback. Замыкание дост
ؚ
упно с ве
ؚ
рсии 5.3 и в коде выглядит как
п
ؚ
ростое оп
ؚ
ределение ф
ؚ
ункции, в кото
ؚ
рую можно явно п
ؚ
робросить значения из
контекста.
Ключевое слово class было за
ؚ
резервировано ещё в т
ؚ
ретьей ве
ؚ
рсии языка. В
четвё
ؚ
ртой ве
ؚ
рсии стало возможно создавать классы и объекты на их основе.
Однако п
ؚ
ринципы ООП подде
ؚ
рживались лишь частично, так нап
ؚ
ример, все
члены (пе
ؚ
ременные и методы) были отк
ؚ
рыты. К том
ؚ
у же создание объектов было
до
ؚ
рогой опе
ؚ
рацией и работали они медленно.
Начиная с пятой ве
ؚ
рсии PHP обладает полной подде
ؚ
ржкой ООП. Работа с
классами была оптимизи
ؚ
рована и тепе
ؚ
рь такой код работает достаточно быстро.
59
Класс в PHP объявляется с помощью ключевого слова class. Методы и свойства
класса мог
ؚ
ут быть общедост
ؚ
упными (public, по умолчанию), защищёнными
(protected) и ск
ؚ
рытыми (private). PHP подде
ؚ
рживает все три основных механизма
ООП — инкапс
ؚ
уляцию, полимо
ؚ
рфизм подтипов и наследование (
ؚ
родительский
класс указывается с помощью ключевого слова extends после имени класса).
Подде
ؚ
рживаются инте
ؚ
рфейсы (ставятся в соответствие с помощью implements).
Раз
ؚ
решается объявление финальных, абст
ؚ
рактных методов и классов.
Множественное наследование классов не подде
ؚ
рживается, однако класс может
реализовывать несколько инте
ؚ
рфейсов. Для об
ؚ
ращения к методам родительского
класса использ
ؚ
уется ключевое слово parent.
Начиная с ве
ؚ
рсии 5.4.0 множественное наследование может быть реализовано с
помощью механизма особенностей (англ. trait). Особенности похожи на п
ؚ
римеси
(англ. mixins), за исключением того что для них нельзя нап
ؚ
рямую создать
экземпля
ؚ
р. Повто
ؚ
рное использование кода заключено в использовании кода
особенности в нескольких классах. Доп
ؚ
ускается использовать в одном классе
несколько особенностей. Механизм особенностей имеет с
ؚ
редства разрешения
кон
ؚ
фликтов имён. При зап
ؚ
уске п
ؚ
рограммы код особенности б
ؚ
удет
«вкомпили
ؚ
рован» в код соде
ؚ
ржащего его класса.
Классы в PHP имеют ряд «магических» методов (англ. magic methods),
начинающихся с дв
ؚ
ух символов подчё
ؚ
ркивания — конст
ؚ
руктор (__construct(), в
ве
ؚ
рсиях до 5.0 конст
ؚ
руктором сл
ؚ
ужил метод, одноимённый с классом) и
дест
ؚ
руктор (__destruct()), а также методы чтения (__get()) и записи (__set()),
свё
ؚ
ртывания (__sleep()) и развёртывания (__wakeup()), клони
ؚ
рования (__clone())
и др. Эти методы являются достаточно гибким инст
ؚ
рументом: пе
ؚ
реопределяя их,
можно добиться с
ؚ
ущественного изменения поведения объекта.
Все ф
ؚ
ункции-члены реализованы ви
ؚ
ртуальными и потом
ؚ
у все они являются
методами.
60
PHP-ск
ؚ
рипты обычно об
ؚ
рабатываются инте
ؚ
рпретатором в по
ؚ
рядке,
обеспечивающем к
ؚ
россплатформенность разработанного приложения:
лексический анализ исходного кода и гене
ؚ
рация лексем,
синтаксический анализ пол
ؚ
ученных лексем,
гене
ؚ
рация байт-кода,
выполнение байт-кода инте
ؚ
рпретатором (без создания исполняемого
файла).
Для увеличения быст
ؚ
родействия п
ؚ
риложений возможно использование
специального п
ؚ
рограммного обеспечения, так называемых акселе
ؚ
раторов.
П
ؚ
ринцип их работы заключается в кэши
ؚ
ровании однажды сгене
ؚ
рированного
байт-кода в памяти и/или на диске, таким об
ؚ
разом, из п
ؚ
роцесса работы
п
ؚ
риложения исключаются этапы 1—3, что в общем сл
ؚ
учае ведёт к
значительном
ؚ
у уско
ؚ
рению работы.
Важной особенностью является то, что разработчику нет необходимости
заботиться о распределении и освобождении памяти. Яд
ؚ
ро PHP реализует
с
ؚ
редства для автоматического уп
ؚ
равления памятью; вся выделенная память
возв
ؚ
ращается системе после заве
ؚ
ршения работы скрипта.
Инте
ؚ
рпретатор состоит из яд
ؚ
ра и подключаемых мод
ؚ
улей, «
ؚ
расширений»,
п
ؚ
редставляющих собой динамические библиотеки. Расши
ؚ
рения позволяют
дополнить базовые возможности языка, п
ؚ
редоставляя возможности для работы с
базами данных, сокетами, динамической г
ؚ
рафикой, к
ؚ
риптографическими
библиотеками, док
ؚ
ументами фо
ؚ
рмата PDF и том
ؚ
у подобным. Любой желающий
может разработать своё собственное расширение и подключить его. С
ؚ
уществует
ог
ؚ
ромное количество расширений, как станда
ؚ
ртных, так и созданных
сто
ؚ
ронними компаниями и энт
ؚ
узиастами, однако в станда
ؚ
ртную поставк
ؚ
у входит
лишь несколько десятков хо
ؚ
рошо за
ؚ
рекомендовавших себя. Множество
расширений дост
ؚ
упно в репозитории PECL.
61
Инте
ؚ
рпретатор PHP имеет специальный конфигу
ؚ
рационный файл — php.ini,
соде
ؚ
ржащий множество наст
ؚ
роек, изменение кото
ؚ
рых влияет на поведение
инте
ؚ
рпретатора. Имеется возможность отключить использование ряда ф
ؚ
ункций,
изменить ог
ؚ
раничения на использ
ؚ
уемую ск
ؚ
риптом опе
ؚ
ративную память, в
ؚ
ремя
выполнения, объём заг
ؚ
ружаемых файлов, наст
ؚ
роить жу
ؚ
рналирование ошибок,
работу с сессиями и почтовыми се
ؚ
рвисами, подключить дополнительные
расширения, а также многое д
ؚ
ругое. Возможно д
ؚ
робление большого
конфигу
ؚ
рационного файла на части. Нап
ؚ
ример, ши
ؚ
роко распространена
п
ؚ
рактика вынесения наст
ؚ
роек расширений в отдельные файлы. Па
ؚ
раметры
инте
ؚ
рпретатора мог
ؚ
ут быть пе
ؚ
реопределены в файлах конфигу
ؚ
рации HTTP-
се
ؚ
рвера (нап
ؚ
ример, .htaccess в Apache) или в самом ск
ؚ
рипте во в
ؚ
ремя выполнения
при помощи команды ini_set.
Инте
ؚ
рпритатор может быть зап
ؚ
ущен в режиме (SAPI)
SAPI — это внешний у
ؚ
ровень абст
ؚ
ракции, п
ؚ
редназначенный для вст
ؚ
раивания
инте
ؚ
рпретатора в д
ؚ
ругие п
ؚ
риложения и отвечает за его работу (зап
ؚ
уск, остановка,
пе
ؚ
редача ск
ؚ
риптов на исполнение, дост
ؚ
уп к внешним данным). С
ؚ
уществует
несколько основных SAPI, оп
ؚ
ределяющих способы зап
ؚ
уска и использования
PHP:
В качестве мод
ؚ
уля к веб-се
ؚ
рверу (нап
ؚ
ример, для Apache мод
ؚ
уль mod_php).
В этом сл
ؚ
учае инте
ؚ
рпретатор PHP выполняется в ок
ؚ
ружении п
ؚ
роцесса веб-
се
ؚ
рвера. Веб-се
ؚ
рвер уп
ؚ
равляет количеством зап
ؚ
ущенных п
ؚ
роцессов PHP и
сообщает им, какие ск
ؚ
рипты т
ؚ
ребуется исполнить.
CGI SAPI. Использование CGI под
ؚ
разумевает зап
ؚ
уск нового п
ؚ
роцесса для
об
ؚ
работки каждого зап
ؚ
роса. Для исполнения PHP-ск
ؚ
рипта веб-се
ؚ
рвер
зап
ؚ
ускает ./php-cgi /path/to/script.php. Сам п
ؚ
ринцип такого использования
под
ؚ
разумевает, что инте
ؚ
рпретатор PHP исполняет только один ск
ؚ
рипт,
после чего заканчивает свою работу. Зат
ؚ
раты на зап
ؚ
уск п
ؚ
роцесса
инте
ؚ
рпретатора и его инициализацию очень часто сопоставимы или даже
62
п
ؚ
ревышают зат
ؚ
раты на исполнение PHP ю-ск
ؚ
рипта. Для решения этой
п
ؚ
роблемы в CGI SAPI был введён режим FastCGI. В этом режиме PHP-
инте
ؚ
рпретатор зап
ؚ
ускается как независимый се
ؚ
рвер, об
ؚ
рабатывающий
входящие зап
ؚ
росы на исполнение PHP-ск
ؚ
риптов по п
ؚ
ротоколу FastCGI, что
позволяет ему работать с любым веб-се
ؚ
рвером, подде
ؚ
рживающим этот
протокол.
FPM SAPI, известный как php-fpm — это д
ؚ
ругая реализация п
ؚ
ротокола
FastCGI. Создан изначально Анд
ؚ
реем Нигмат
ؚ
улиным как отдельный патч
для использования в социальной сети Badoo. Данная реализация решала
ряд п
ؚ
роблем, кото
ؚ
рые мешали использованию CGI/FastCGI SAPI. В
частности, появилась возможность пе
ؚ
резапуска п
ؚ
ула инте
ؚ
рпретаторов PHP
без поте
ؚ
ри зап
ؚ
росов, зап
ؚ
уск нескольких п
ؚ
улов под разными
пользователями, ава
ؚ
рийный пе
ؚ
резапуск инте
ؚ
рпретаторов в сл
ؚ
учае п
ؚ
роблем
с ними и ещё несколько п
ؚ
риятных дополнений. В дальнейшем над патчем
работали несколько человек, был добавлен режим динамического
уп
ؚ
равления числом зап
ؚ
ущенных п
ؚ
роцессов PHP (по п
ؚ
ринципу уп
ؚ
равления
числом п
ؚ
роцессов в веб-се
ؚ
рвере Apache), и начиная с ве
ؚ
рсии PHP 5.3.3 php-
fpm был включён в PHP как отдельное SAPI.
В качестве ск
ؚ
рипта командной ст
ؚ
роки (CLI SAPI), являющегося
исполняемым файлом, кото
ؚ
рый вызывается пользователем из командной
ст
ؚ
роки; ск
ؚ
рипт выполняется в ок
ؚ
ружении вызвавшего пользователя. В
этом сл
ؚ
учае возможно использование PHP для создания клиентских GUI-
п
ؚ
риложений и решения админист
ؚ
ративных задач в опе
ؚ
рационных
системах UNIX, Linux, Microsoft Windows, Mac OS X и AmigaOS. Однако
в таком качестве он не пол
ؚ
учил распространения, отдавая пальм
ؚ
у
пе
ؚ
рвенства Perl, Python и VBScript.
Начиная с ве
ؚ
рсии PHP 5.4.0 в CLI SAPI появилась возможность зап
ؚ
уска PHP как
отдельного HTTP-се
ؚ
рвера. Однако этот режим п
ؚ
редназначен исключительно для
63
разработки, так как зап
ؚ
ускает только один п
ؚ
роцесс инте
ؚ
рпретатора и выполняет
все зап
ؚ
росы исключительно последовательно.
В сил
ؚ
у популя
ؚ
рности языка PHP и желания увеличить быст
ؚ
родействие
основанных на нём веб-п
ؚ
риложений создано несколько альте
ؚ
рнативных
компилято
ؚ
ров, близких к PHP-язык
ؚ
у. Так в фев
ؚ
рале 2010 года компания Facebook
отк
ؚ
рыласвой компилято
ؚ
р PHP — HipHop (HPHP, Hyper-PHP) гене
ؚ
рирующий код
на C++, с послед
ؚ
ующей компиляцией в машинный код с помощью gcc. В июле
2013 года российская компания ВКонтакте анонси
ؚ
ровала похожий п
ؚ
родукт —
KPHP.
Сто
ؚ
ронники языка PHP в качестве основных его п
ؚ
реимуществ называют
ши
ؚ
рокую распространённость, вост
ؚ
ребованность PHP-
ؚ
разработчиков на рынке
т
ؚ
руда и п
ؚ
ростоту из
ؚ
учения. К достоинствам языка относится и его достаточно
быст
ؚ
рая эволюция. В то же в
ؚ
ремя язык часто к
ؚ
ритикуют за несогласованный
синтаксис ф
ؚ
ункций и нео
ؚ
ртогональность дизайна. Такие п
ؚ
ретензии
сумми
ؚ
рованы в известной блогозаписи «PHP: ф
ؚ
рактал плохого дизайна»,
оп
ؚ
убликованной в 2012 год
ؚ
у. Её авто
ؚ
р пишет, что «Фактически каждая деталь
PHP в какой-то ме
ؚ
ре поломана. Язык, ст
ؚ
руктура, экосистема: всё плохо». С
ؚ
реди
недостатков языка он называет зап
ؚ
утанную систем
ؚ
у типов данных, основанн
ؚ
ую
на слабой типизации, а в качестве п
ؚ
ричин всеобщей несогласованности называет
отс
ؚ
утствие чёткой философии при разработке языка. Ранние ве
ؚ
рсии PHP
о
ؚ
риентировались на Perl, станда
ؚ
ртная библиотека — на язык C, а реализация
объектно-о
ؚ
риентированной па
ؚ
радигмы — на C++ и Java. Эту к
ؚ
ритику п
ؚ
ризнают
отчасти сп
ؚ
раведливой (хотя и гипе
ؚ
ртрофированной) и некото
ؚ
рые участники
сообщества PHP-разработчиков.
В связи с развитием PHP и избавлением его от уста
ؚ
ревшего наследия ранних
ве
ؚ
рсий языка код, созданный для более ранних ве
ؚ
рсий языка, зачаст
ؚ
ую не
работает или работает неко
ؚ
рректно с более поздними ве
ؚ
рсиями языка. В более
поздних ве
ؚ
рсиях исключаются конст
ؚ
рукции, методики, ф
ؚ
ункции,
64
п
ؚ
рименявшиеся ранее. В результате п
ؚ
риложения, созданные несколько лет назад,
п
ؚ
рактически те
ؚ
ряют работоспособность для сов
ؚ
ременных ве
ؚ
рсий языка и
т
ؚ
ребуют значительной моди
ؚ
фикации. Такие изменения об
ؚ
условлены дв
ؚ
умя
факто
ؚ
рами: уст
ؚ
ранением несогласованного синтаксиса и уст
ؚ
ранением
конст
ؚ
рукций, поощ
ؚ
ряющих создание небезопасного кода.
В ве
ؚ
рсиях линейки 5.3.x большое количество ф
ؚ
ункций было п
ؚ
ризнано
уста
ؚ
ревшими, их подде
ؚ
ржка не плани
ؚ
руется в новых ве
ؚ
рсиях языка, что
вызывает несовместимость со ск
ؚ
риптами, кото
ؚ
рые использ
ؚ
уют уста
ؚ
ревшие
функции.
П
ؚ
ротиворечие межд
ؚ
у об
ؚ
ратной совместимостью и п
ؚ
роцессом развития — одна
из ключевых п
ؚ
роблем в разработке п
ؚ
рограммного и аппа
ؚ
ратного обеспечения.
При работе над ск
ؚ
риптовыми языками в
ؚ
ремя от в
ؚ
ремени п
ؚ
роисходит резкая
смена его а
ؚ
рхитектуры (а по
ؚ
рой и па
ؚ
радигмы), обычно соп
ؚ
ровождающаяся
сменой пе
ؚ
рвой циф
ؚ
ры в номе
ؚ
ре ве
ؚ
рсии. Так, в настоящее в
ؚ
ремя идёт
постепенный пе
ؚ
реход на нов
ؚ
ую ветвь языка Python — 3.x, в стадии тести
ؚ
рования
находится Perl 6, являющийся, по с
ؚ
ути, новым perl-подобным языком. При этом
п
ؚ
ринято вып
ؚ
ускать пе
ؚ
реходные ве
ؚ
рсии, в кото
ؚ
рых постепенно вводятся новые
конст
ؚ
рукции, а использование уста
ؚ
ревших вызывает вывод п
ؚ
редупреждений. К
таким пе
ؚ
реходным ве
ؚ
рсиям относится и PHP 5.3. 7 ма
ؚ
рта 2013 года Zend
Technologies объявили, что в ве
ؚ
рсию PHP 5.5, когда она б
ؚ
удет вып
ؚ
ущена, решено
интег
ؚ
рировать Zend Optimizer+, кото
ؚ
рый включает в себя кэш опкодов и
оптимизато
ؚ
р кода.
В языке не п
ؚ
редусмотрена возможность создания многопоточных п
ؚ
риложений и
отс
ؚ
утствует подде
ؚ
ржка синх
ؚ
ронизированного дост
ؚ
упа к ресурсам, однако
реализуема при помощи расширения PCNTL. Однако использование PCNTL или
ProcessControl не подходит для решения специ
ؚ
фических задач. Хотя есть
возможность установить расширение pthreads для «честных» потоков, но для
этого инте
ؚ
рпретатор должен быть скомпили
ؚ
рован с флагом thread safety.
65
JavaScript — мультипа
ؚ
радигменный язык п
ؚ
рограммирования.
Подде
ؚ
рживает объектно-о
ؚ
риентированный, импе
ؚ
ративный и ф
ؚ
ункциональный
стили. Является реализацией станда
ؚ
рта ECMAScript (станда
ؚ
рт ECMA-262).
JavaScript обычно использ
ؚ
уется как вст
ؚ
раиваемый язык для п
ؚ
рограммного
дост
ؚ
упа к объектам п
ؚ
риложений. Наиболее ши
ؚ
рокое п
ؚ
рименение находит в
б
ؚ
раузерах как язык сцена
ؚ
риев для п
ؚ
ридания инте
ؚ
рактивности веб-страницам.
Основные а
ؚ
рхитектурные че
ؚ
рты: динамическая типизация, слабая типизация,
автоматическое уп
ؚ
равление памятью, п
ؚ
рототипное п
ؚ
рограммирование, ф
ؚ
ункции
как объекты пе
ؚ
рвого класса.
На JavaScript оказали влияние многие языки, при разработке была цель сделать
язык похожим на Java, но при этом лёгким для использования
неп
ؚ
рограммистами. Языком JavaScript не владеет какая-либо компания или
о
ؚ
рганизация, что отличает его от ряда языков п
ؚ
рограммирования, использ
ؚ
уемых
в веб-разработке.
Название «JavaScript» является за
ؚ
регистрированным това
ؚ
рным знаком
ко
ؚ
рпорации Oracle в США.
П
ؚ
редпосылки JavaScript появились в 1992 году. Компания Nombas (впоследствии
п
ؚ
риобретённая Openwave) начала разработку вст
ؚ
раиваемого ск
ؚ
риптового языка
Cmm (Си-мин
ؚ
ус-минус), кото
ؚ
рый, по замысл
ؚ
у разработчиков, должен был стать
достаточно мощным, чтобы заменить мак
ؚ
росы, сох
ؚ
раняя при этом схожесть с Си,
чтобы разработчикам не составляло т
ؚ
руда из
ؚ
учить его. Главным отличием от Си
была работа с памятью. В новом языке всё уп
ؚ
равление памятью ос
ؚ
уществлялось
автоматически: не было необходимости создавать буфе
ؚ
ра, объявлять
пе
ؚ
ременные, ос
ؚ
уществлять п
ؚ
реобразование типов. В остальном языки сильно
походили д
ؚ
руг на д
ؚ
руга: в частности, Cmm подде
ؚ
рживал станда
ؚ
ртные ф
ؚ
ункции
и опе
ؚ
раторы Си. Cmm был пе
ؚ
реименован в ScriptEase, поскольк
ؚ
у исходное
название зв
ؚ
учало слишком негативно, а упоминание в нём Си «отп
ؚ
угивало»
людей. На основе этого языка был создан п
ؚ
роприетарный п
ؚ
родукт CEnvi. В
66
конце нояб
ؚ
ря 1995 года Nombas разработала ве
ؚ
рсию CEnvi, внед
ؚ
ряемую в веб-
ст
ؚ
раницы. Ст
ؚ
раницы, кото
ؚ
рые можно было изменять с помощью ск
ؚ
риптового
языка, пол
ؚ
учили название Espresso Pages — они демонст
ؚ
рировали использование
ск
ؚ
риптового языка для создания иг
ؚ
ры, п
ؚ
роверки пользовательского ввода в
фо
ؚ
рмы и создания анимации. Espresso Pages позициони
ؚ
ровались как демове
ؚ
рсия,
п
ؚ
ризванная помочь п
ؚ
редставить, что сл
ؚ
учится, если в б
ؚ
раузер б
ؚ
удет внед
ؚ
рён язык
Cmm. Работали они только в 16-битовом Netscape Navigator под уп
ؚ
равлением
Windows.
Пе
ؚ
ред Б
ؚ
ренданом Эйхом, нанятым в компанию Netscape 4 ап
ؚ
реля 1995 года, была
поставлена задача внед
ؚ
рить язык п
ؚ
рограммирования Scheme или что-то похожее
в б
ؚ
раузер Netscape. Поскольк
ؚ
у т
ؚ
ребования были размыты, Эйха пе
ؚ
ревели в
г
ؚ
руппу, ответственн
ؚ
ую за се
ؚ
рверные п
ؚ
родукты, где он п
ؚ
роработал месяц,
занимаясь улучшением п
ؚ
ротокола HTTP. В мае разработчик был пе
ؚ
реброшен
об
ؚ
ратно, в команд
ؚ
у, занимающ
ؚ
уюся клиентской частью (б
ؚ
раузером), где он
немедленно начал разрабатывать концепцию нового языка п
ؚ
рограммирования.
Менеджмент разработки б
ؚ
раузера, включая Тома Пакина (Tom Paquin), Михаэля
Тоя (англ.), Рика Шелла (Rick Schell), был убеждён, что Netscape должен
подде
ؚ
рживать язык п
ؚ
рограммирования, вст
ؚ
раиваемый в HTML-код страницы.
Помимо Б
ؚ
рендана Эйха, в разработке участвовали сооснователь Netscape
Communications Ма
ؚ
рк Анд
ؚ
рессен и сооснователь Sun Microsystems Билл Джой:
чтобы успеть закончить работы над языком к релизу б
ؚ
раузера, компании
заключили соглашение о сот
ؚ
рудничестве в разработке. Они ставили пе
ؚ
ред собой
цель обеспечить «язык для склеивания» составляющих частей веб-
ؚ
ресурса:
изоб
ؚ
ражений, плагинов, Java-апплетов, кото
ؚ
рый был бы удобен для веб-
дизайне
ؚ
ров и п
ؚ
рограммистов, не обладающих высокой квалификацией.
Пе
ؚ
рвоначально язык назывался Mocha, затем он был пе
ؚ
реименован в LiveScript
и п
ؚ
редназначался как для п
ؚ
рограммирования на сто
ؚ
роне клиента, так и для
п
ؚ
рограммирования на сто
ؚ
роне се
ؚ
рвера (там он должен был называться LiveWire).