Языки будущего

Крис Касперски ака мыщъх

Спецвыпуск: Хакер, номер #055, стр. 055-052-4

Прогнозировать трудно. Языки всегда были консервативны. Мы до сих пор находимся под влиянием синтаксиса С и парадигмы объектно-ориентированного программирования. Язык, каким бы замечательным он ни был, находится под властью требований обратной совместимости миллионов исходных строк, которые никто не будет переписывать с нуля. Необходима обширная инфраструктура - компиляторы/интерпретаторы, библиотеки, отладочные средства, учебные пособия. Взять хотя бы Haskell, магическое очарование которого влюбляет в него с первого взгляда. Многие были бы не прочь писать на нем и только на нем, но… "Я пробовал изучать Haskell и был впечатлен его элегантностью и тем, как он позволяет писать код, который работает с первой попытки (или со второй). Однако я не исследователь. Я занимаюсь коммерческой разработкой программного обеспечения, и мне требуется документация и стабильность", - Alexander Jacobson.

fac n

| n == 0 = 1

| otherwise = n * fac (n-1)

Мысли о новом языке

Чего нам не хватает в приплюснутом С и прочих языках? Простоты. Именно той простоты и элегантности, на которой сделали карьеру Unix и классический С. Кстати, Unix до сих пор остается простой и дружелюбно настроенной к программисту средой, предлагающей элегантный интерфейс с минимальным оверхидом. Свой первый драйвер под Windows я писал несколько дней и всю последующую неделю ходил как пришибленный, а под Linux загружаемый модуль ядра я написал через несколько минут(!) после того, как открыл документацию. "Как просто… Невероятно… Так не бывает…", - носилось у меня в голове.

Гениальность создателей Unix'а в том, что они предоставили унифицированный интерфейс ко всем компонентам системы. Одна и так же функция открывает и файл, и устройство, и даже оперативную память! Microsoft же на все заводит свой API. Отсюда и неподъемная сложность. Библиотеки (типа MFC) ничего не меняют. Вместо того чтобы учить API операционной системы, мы вынуждены учить и API, и разлапистую иерархию библиотек. Тот же самый пресловутый ActiveX/OLE можно было сделать намного проще, если бы подойти к делу с головой.

Итак, новый язык, прежде всего, должен быть прост. Платформа .NET на эту роль явно не тянет. Да, она, похоже, на нее и не претендует. Это узкоспециализированный набор языков, ориентированный на базы данных и клиент-серверные приложения, но ни словом ни делом не поддерживающий ни векторное, ни параллельное программирование. А зря! Тактовая частота не резиновая, и быстродействию процессоров очень скоро наступит предел. Многопроцессорные системы уже не за горами (достаточно вспомнить хотя бы Hyper Threading). Существует множество диалектов приплюснутого С, поддерживающих параллельное программирование, существуют библиотеки, поддерживающие векторные команды (они же мультимедийные), но все это жалкие костыли. Неудобные, ни с чем не совместимые, да к тому же недостаточно эффектные. Это как морская свинка. Еще не морская, но уже и не свинка. Векторно-параллельное программирование требует совсем другого подхода и типа мышления, а значит, и принципиально нового языка.