Smalltalk?! Часть 2
Smalltalk?!
Окончание. Начало в КГ № 15 .
Java HotSpot VM
Среди преимуществ, отличающих динамически типизированные языки программирования (такие, как Smalltalk) от статически типизированных (например, Java) языков, — их однородность и масштабируемость. Проиллюстрируем это примером. В языке Java поддерживается несколько типов выполнения операций над объектами:
• арифметические операции с примитивными типами данных, например, сложение и вычитание целых чисел;
• вызов статического метода;
• вызов виртуального метода;
• вызов виртуального метода через интерфейс;
• вызов посредством рефлексии (reflexion).
Каждый последующий тип вызова выполняется в несколько раз медленнее предыдущего, а последний — даже в десятки-сотни раз медленнее. То есть мы имеем ситуацию, при которой одни типы вызовов предпочтительнее других. Для производительности лучше будет обходиться статическими вызовами и минимальным количеством виртуальных. Но реальные, хорошо спроектированные приложения, как правило, обладают высокой степенью полиморфизма. Поэтому процент использования виртуальных методов может быть значительным, что существенно снижает производительность. Есть категория приложений, в которых время вызовов посредством рефлексии начинает доминировать. Все это приводит к тому, что время выполнения приложений увеличивается нелинейным образом относительно сложности проекта.
В языке Smalltalk ситуация иная: операция посылки сообщения имеет тот же вид как для арифметических, так и для любых других операций. А использование рефлексии снижает производительность на считанные проценты! То есть в языке имеется всего лишь одна базовая конструкция, которая и определяет скорость выполнения приложений. Соответственно, если эта конструкция будет выполняться максимально быстро, то это скажется положительно на всех без исключения приложениях.
Заметим, что посылка сообщения в динамических языках реализуется исключительно эффективно. По скорости она незначительно медленнее статического вызова. И, естественно, намного эффективнее виртуального вызова. Аналогичная ситуация получается в отношении использования памяти. В языке Java небольшие приложения, как правило, используют динамическую память неинтенсивно. По ним нельзя составить картину того, как будут вести себя большие приложения. Поэтому часто получается так, что компилятор, который показывает лучшие результаты в тестах, может показывать худшую производительность в реальных приложениях.
В Smalltalk все сложнее: даже самые маленькие приложения постоянно создают много новых объектов. По статистике, 95% вновь созданных объектов имеют очень короткий срок жизни. Та же картина наблюдается и для больших систем. Поэтому с самого начала перед разработчиками Smal-ltalk ставится трудная задача — минимизировать влияние алгоритмов сборки мусора на работу приложения. Это особенно критично в графических приложениях, где паузы, вызванные работой менеджера памяти, недопустимы. Если сложить все факторы вместе, получается, что эффективная реализация языка Smalltalk будет давать хорошую и предсказуемую производительность для систем любого масштаба. Определяющей величиной скорости выполнения приложения является только количество операций посылки сообщения.
С языком Java ситуация намного сложнее: быстрое выполнение целочисленных тестов еще абсолютно ничего не говорит о работе реальных приложений. Компания Sun, естественно, была в курсе такого положения вещей. Вплоть до JDK 1.2 графические и серверные приложения выполнялись медленно, порой даже очень медленно. С этим, безусловно, нужно было что-то делать, и Sun сделала — в 1997 году она купила компанию Animorphic! Зная историю развития проекта со времен Self compiler technology, она сделала ставку на динамический адаптивный компилятор. Ядро компилятора Animorphic Smalltalk было адаптировано для языка Java, и проект получил название Java HotSpot Virtual Machine. Имя проекта отражало способность компилятора динамически определять наиболее критичные участки приложения и создавать для них высоко оптимизированный машинный код.
Но, видимо, времени до выпуска JDK 1.3 оставалось немного, поэтому не все возможности были реализованы в HotSpot VM — например, полиморфный кэш вызовов. Также не было сделано качественной реализации работы с примитивными типами данных. Из-за этого HotSpot VM проигрывала на простых целочисленных тестах предыдущим версиям JDK. Но ситуация коренным образом поменялась для реальных приложений.
Наконец скорость их выполнения стала приемлемой.
С выходом JDK 1.4 динамический компилятор был существенно доработан — была реализована качественная поддержка примитивных типов данных, рефлексивные вызовы стали выполняться в десятки раз быстрее.
Были добавлены также присущие Self и Smalltalk динамические возможности для подмены методов во время отладки. Естественно, покупка Animorhic Smalltalk компанией Sun сделала невозможным выход этого коммерческого продукта. Но, учитывая многочисленные просьбы сообщества разработчиков, была выложена экспериментальная версия Animorphic Smalltalk 1.1.1. Правда, без исходных текстов компилятора.
VisualAge for Java
Этот факт также может показаться удивительным, но, тем не менее, одна из самых продуктивных сред разработки на языке Java написана на Smalltalk (Visual Age for Smalltalk). Этот продукт по возможностям в целом повторяет своего прародителя, но язык Java накладывает серьезные ограничения на многие динамические функции среды. Правда, проект VisualAge доживает свои последние дни. В настоящее время компания IBM активно занимается продвижением своего нового продукта — Eclipse. Это среда разработки для языка Java, которая построена на базе новой библиотеки визуальных элементов интерфейса SWT. Главное ее отличие от стандартной библиотеки AWT — легковесность и простота использования. И как раз основные черты SWT были позаимствованы у платформонезависимого набора компонент, разработанного еще для Visual Age for Smalltalk.
Архитектура SPARC
Во все времена была популярна идея создания процессора, адаптированного для эффективного выполнения команд определенного языка. В начале восьмидесятых все тот же David Ungar работал над проектом Smalltalk-on-a-Risc (SOAR). В ходе проекта были использованы/разработаны следующие технологии:
• большой набор регистров;
• тэговая арифметика;
• отложенная обработка ловушек;
• регистровые окна;
• малая стоимость команды вызова;
• малая стоимость косвенного обращения к памяти.
Правда, в ходе исследований выяснилось, что специализированная архитектура не дает существенного выигрыша в производительности. В среднем получается значение около 30%. Поэтому большого смысла в создании такого процессора не было. Но эти наработки все-таки не пропали даром: многие из них впоследствии были реализованы в архитектуре SPARC.
Открытие множества новых направлений в программировании связано с именами двух людей. Это Kent Beck и Ward Cunningham. Они занимались программированием на Smalltalk еще с середины восьмидесятых, и все, что они изобрели, являлось непосредственным отображением их практического опыта. Кент как-то заметил, что он всего лишь описывал тот способ работы, который Вард использовал каждый день. Вард также является автором идеи Wiki Wiki-сервера, который служит для обмена идеями и их документирования в среде разработчиков. Его сервер c2.com до сих пор является основным местом обсуждения новых идей в гибких методологиях, программировании и проектировании.
Паттерны проектирования
В середине восьмидесятых Smalltalk позиционировался как средство для разработки сложных программных систем с развитым пользовательским интерфейсом. Как-то раз, когда Кент и Вард работали над подобным проектом, они натолкнулись на особенно сложную проблему в дизайне интерфейса. Тогда Кент вспомнил про труды Кристофера Александра, описывающие паттерны проектирования в архитектуре и строительстве, с которыми познакомился еще будучи студентом. Тогда они с Вардом сформулировали первые пять паттернов, с помощью которых им удалось решить некоторые проблемы в проекте.
Вдохновленный таким успехом, Кент выступил на конференции OOPSLA'87 с описанием первых паттернов, но слушатели встретили его доклад прохладно. В то время еще мало кто видел потенциал этого нововведения без демонстрации убедительных примеров. В 1991 году вопросом паттернов занялся Erich Gamma, и спустя три года вышла классическая книга Банды Четырех — "Паттерны проектирования". Большинство примеров было дано на языке C++, но Smalltalk также присутствовал там, где его использование давало дополнительный выигрыш.
Лучшей книгой о паттернах в Smalltalk является книга самого Кента Бека "Smalltalk Best Practice Patterns". Ее прочитали многие разработчики, не знающие этого языка, которые, вместе с тем, отметили, что это одна из лучших книг по объектно-ориентированному программированию. Стиль написания программ в среде Smalltalk является наиболее естественным для объектного подхода, поэтому его изучение может положительно сказаться на качестве разработки в целом.
Экстремальное Программирование
Практики Экстремального Программирования (по крайней мере, те, которые непосредственно касаются разработки) являются логичным обобщением всего того, что разработчики на Smalltalk применяли уже долгое время. Сам Кент Бек однозначно высказывается, что Smalltalk явился той питательной средой, в которой выросло XP. Парадокс заключается в том, что XP по своей популярности намного превзошло своего прародителя. Экстремальное Программирование сыграло свою определенную роль — популяризовало среди широкого круга разработчиков способ разработки, который характерен именно для Smalltalk.
Рассмотрим некоторые практики Экстремального Программирования:
• Simple Design. Сам язык чрезвычайно прост: в нем только пять ключевых слов, одна базовая конструкция и несколько вспомогательных. Все базируется на объектах и посылке сообщений между ними.
• Refactoring. Smalltalk является очень открытой к изменениям системой. Не нужно тратить время на паузы компиляции, любую идею можно тут же испробовать прямо по ходу работы приложения. Все это способствует быстрой апробации множества идей. Выгоднее не сразу закладывать универсальный дизайн, а начать с простого и дальше продвигаться небольшими шагами, расширяя систему по мере необходимости. Этому также способствует наличие автоматизированного средства — Refactoring Browser. Впервые он был создан для среды VisualWorks Smalltalk и позже стал появляться в оболочках для Java — таких, как IDEA и Eclipse. Некоторые разработчики уже не представляют свою работу без Refactoring Browser. В данный момент рефакторинг стал очень популярным благодаря одноименной книге Мартина Фаулера. На написание этой книги его вдохновил тот подход, который Кент Бек и другие Smalltalk'еры каждодневно применяли при разработке программ.
• Test-First Design. Smalltalk является динамически типизированным языком, что означает отсутствие проверок типов во время компиляции. Казалось бы, это должно приводить к большему числу ошибок, чем в статически типизированных языках. В общем случае это неверно. Раннему обнаружению ошибок способствует его развитая динамическая среда. Но среди разработчиков бытует мнение, что язык со строгой типизацией позволяет выловить большинство ошибок. А это расходится с мнением экспертов, что на тестирование нужно выделять до половины ресурсов проекта. Просто те ошибки, которые обнаруживает компилятор, — это далеко не все ошибки, которые могут содержаться в системе. Гораздо важнее удостовериться, что система выполняет именно то, что было задумано, и тестирование в любом случае остается очень важным фактором проекта.
Кент Бек разработал оболочку для модульного тестирования программ на Smalltalk — позже она была названа SUnit. Совместно в Эрихом Гамма они портировали ее для языка Java — так появился JUnit. И с этого момента xUnit framework получил широкую известность.
• Хотя следует отметить, что заслуга xUnit не столько в том, что он позволяет тестировать модули программы, сколько в том, что с его помощью реализуется Test-First Design — подход, при котором тесты пишутся раньше кода, который они тестируют. Практика показывает, что такой вид дизайна часто приводит к оптимальной структуре системы.
Заключение
Самый первый вопрос, возникающий у многих относительно Smalltalk: если он такой хороший, почему же он такой непопулярный? Как всегда, на него непросто дать однозначный ответ. Первое, что приходит на ум: а когда в нашем мире действительно хорошая вещь была очень популярной? Среди объективных факторов стоит выделить следующие:
• Необычный синтаксис. Многие из тех, кто начинал с Pascal или C, не могут к нему привыкнуть. И это несмотря на то, что он в большей степени напоминает предложения на естественном языке. Те, кто начинает изучение программирования со Smalltalk, никаких проблем с синтаксисом не имеют.
• Объектный подход. За тридцать с лишним лет, которые прошли с момента появления объектного подхода, индустрия так и не приняла его. Большей популярностью пользуются псевдообъектно-ориентированные гибриды, такие, как C++ и Java.
• Производительность. Поначалу производительность приложений на Smalltalk была существенно ниже, чем у аналогичных программ, написанных на C. Это сдерживало многих разработчиков, так как скорость обычно является одним из определяющих факторов выбора технологии. Но времена меняются. Теперь благодаря таким проектам, как Animorphic Smalltalk, производительность больше не является проблемой. В умах разработчиков также намечается перелом — в большинстве случаев выгоднее написать программу вдвое быстрее, чем написать вдвое более быструю программу.
• Маркетинг. В данный момент у Smalltalk нет хозяина, который мог бы вложить миллионы/миллиарды долларов в его развитие, как это было сделано с VB/Java/C#. Компании, которые раньше занимались продвижением Smalltalk, сослужили ему очень плохую службу. История могла бы пойти по другому пути, если бы они согласились продать лицензию на виртуальную машину Smalltalk для языка Visual Basic компании Microsoft.
Однако благодаря новым компаниям-разработчикам, таким, как Cincom, Object-Arts и SmallScript, у Smalltalk есть будущее. В частности, Cincom сообщает о росте продаж VisualWorks Smalltalk на 10% ежегодно. Также намечается тенденция возвращения к разработке на Smalltalk у компаний, которые использовали его в прошлом. Вот краткий перечень компаний, которые продолжают пользоваться Smalltalk: AMD, BMW, Chrysler, Deutsche Bank, FedEx, Nokia, Texas Instruments, Volkswagen.
Все эти компании не могут ошибаться. Кроме того, есть тенденция к умалчиванию факта использования Smalltalk, так как это часто рассматривается как конкурентное преимущество.
Есть комментарии? Пишите.
Денис "Denver" Мигачев,
Владимир "Vovin" Лешкевич,
http://www.smalltalk.ru
Окончание. Начало в КГ № 15 .
Java HotSpot VM
Среди преимуществ, отличающих динамически типизированные языки программирования (такие, как Smalltalk) от статически типизированных (например, Java) языков, — их однородность и масштабируемость. Проиллюстрируем это примером. В языке Java поддерживается несколько типов выполнения операций над объектами:
• арифметические операции с примитивными типами данных, например, сложение и вычитание целых чисел;
• вызов статического метода;
• вызов виртуального метода;
• вызов виртуального метода через интерфейс;
• вызов посредством рефлексии (reflexion).
Каждый последующий тип вызова выполняется в несколько раз медленнее предыдущего, а последний — даже в десятки-сотни раз медленнее. То есть мы имеем ситуацию, при которой одни типы вызовов предпочтительнее других. Для производительности лучше будет обходиться статическими вызовами и минимальным количеством виртуальных. Но реальные, хорошо спроектированные приложения, как правило, обладают высокой степенью полиморфизма. Поэтому процент использования виртуальных методов может быть значительным, что существенно снижает производительность. Есть категория приложений, в которых время вызовов посредством рефлексии начинает доминировать. Все это приводит к тому, что время выполнения приложений увеличивается нелинейным образом относительно сложности проекта.
В языке Smalltalk ситуация иная: операция посылки сообщения имеет тот же вид как для арифметических, так и для любых других операций. А использование рефлексии снижает производительность на считанные проценты! То есть в языке имеется всего лишь одна базовая конструкция, которая и определяет скорость выполнения приложений. Соответственно, если эта конструкция будет выполняться максимально быстро, то это скажется положительно на всех без исключения приложениях.
Заметим, что посылка сообщения в динамических языках реализуется исключительно эффективно. По скорости она незначительно медленнее статического вызова. И, естественно, намного эффективнее виртуального вызова. Аналогичная ситуация получается в отношении использования памяти. В языке Java небольшие приложения, как правило, используют динамическую память неинтенсивно. По ним нельзя составить картину того, как будут вести себя большие приложения. Поэтому часто получается так, что компилятор, который показывает лучшие результаты в тестах, может показывать худшую производительность в реальных приложениях.
В Smalltalk все сложнее: даже самые маленькие приложения постоянно создают много новых объектов. По статистике, 95% вновь созданных объектов имеют очень короткий срок жизни. Та же картина наблюдается и для больших систем. Поэтому с самого начала перед разработчиками Smal-ltalk ставится трудная задача — минимизировать влияние алгоритмов сборки мусора на работу приложения. Это особенно критично в графических приложениях, где паузы, вызванные работой менеджера памяти, недопустимы. Если сложить все факторы вместе, получается, что эффективная реализация языка Smalltalk будет давать хорошую и предсказуемую производительность для систем любого масштаба. Определяющей величиной скорости выполнения приложения является только количество операций посылки сообщения.
С языком Java ситуация намного сложнее: быстрое выполнение целочисленных тестов еще абсолютно ничего не говорит о работе реальных приложений. Компания Sun, естественно, была в курсе такого положения вещей. Вплоть до JDK 1.2 графические и серверные приложения выполнялись медленно, порой даже очень медленно. С этим, безусловно, нужно было что-то делать, и Sun сделала — в 1997 году она купила компанию Animorphic! Зная историю развития проекта со времен Self compiler technology, она сделала ставку на динамический адаптивный компилятор. Ядро компилятора Animorphic Smalltalk было адаптировано для языка Java, и проект получил название Java HotSpot Virtual Machine. Имя проекта отражало способность компилятора динамически определять наиболее критичные участки приложения и создавать для них высоко оптимизированный машинный код.
Но, видимо, времени до выпуска JDK 1.3 оставалось немного, поэтому не все возможности были реализованы в HotSpot VM — например, полиморфный кэш вызовов. Также не было сделано качественной реализации работы с примитивными типами данных. Из-за этого HotSpot VM проигрывала на простых целочисленных тестах предыдущим версиям JDK. Но ситуация коренным образом поменялась для реальных приложений.
Наконец скорость их выполнения стала приемлемой.
С выходом JDK 1.4 динамический компилятор был существенно доработан — была реализована качественная поддержка примитивных типов данных, рефлексивные вызовы стали выполняться в десятки раз быстрее.
Были добавлены также присущие Self и Smalltalk динамические возможности для подмены методов во время отладки. Естественно, покупка Animorhic Smalltalk компанией Sun сделала невозможным выход этого коммерческого продукта. Но, учитывая многочисленные просьбы сообщества разработчиков, была выложена экспериментальная версия Animorphic Smalltalk 1.1.1. Правда, без исходных текстов компилятора.
VisualAge for Java
Этот факт также может показаться удивительным, но, тем не менее, одна из самых продуктивных сред разработки на языке Java написана на Smalltalk (Visual Age for Smalltalk). Этот продукт по возможностям в целом повторяет своего прародителя, но язык Java накладывает серьезные ограничения на многие динамические функции среды. Правда, проект VisualAge доживает свои последние дни. В настоящее время компания IBM активно занимается продвижением своего нового продукта — Eclipse. Это среда разработки для языка Java, которая построена на базе новой библиотеки визуальных элементов интерфейса SWT. Главное ее отличие от стандартной библиотеки AWT — легковесность и простота использования. И как раз основные черты SWT были позаимствованы у платформонезависимого набора компонент, разработанного еще для Visual Age for Smalltalk.
Архитектура SPARC
Во все времена была популярна идея создания процессора, адаптированного для эффективного выполнения команд определенного языка. В начале восьмидесятых все тот же David Ungar работал над проектом Smalltalk-on-a-Risc (SOAR). В ходе проекта были использованы/разработаны следующие технологии:
• большой набор регистров;
• тэговая арифметика;
• отложенная обработка ловушек;
• регистровые окна;
• малая стоимость команды вызова;
• малая стоимость косвенного обращения к памяти.
Правда, в ходе исследований выяснилось, что специализированная архитектура не дает существенного выигрыша в производительности. В среднем получается значение около 30%. Поэтому большого смысла в создании такого процессора не было. Но эти наработки все-таки не пропали даром: многие из них впоследствии были реализованы в архитектуре SPARC.
Открытие множества новых направлений в программировании связано с именами двух людей. Это Kent Beck и Ward Cunningham. Они занимались программированием на Smalltalk еще с середины восьмидесятых, и все, что они изобрели, являлось непосредственным отображением их практического опыта. Кент как-то заметил, что он всего лишь описывал тот способ работы, который Вард использовал каждый день. Вард также является автором идеи Wiki Wiki-сервера, который служит для обмена идеями и их документирования в среде разработчиков. Его сервер c2.com до сих пор является основным местом обсуждения новых идей в гибких методологиях, программировании и проектировании.
Паттерны проектирования
В середине восьмидесятых Smalltalk позиционировался как средство для разработки сложных программных систем с развитым пользовательским интерфейсом. Как-то раз, когда Кент и Вард работали над подобным проектом, они натолкнулись на особенно сложную проблему в дизайне интерфейса. Тогда Кент вспомнил про труды Кристофера Александра, описывающие паттерны проектирования в архитектуре и строительстве, с которыми познакомился еще будучи студентом. Тогда они с Вардом сформулировали первые пять паттернов, с помощью которых им удалось решить некоторые проблемы в проекте.
Вдохновленный таким успехом, Кент выступил на конференции OOPSLA'87 с описанием первых паттернов, но слушатели встретили его доклад прохладно. В то время еще мало кто видел потенциал этого нововведения без демонстрации убедительных примеров. В 1991 году вопросом паттернов занялся Erich Gamma, и спустя три года вышла классическая книга Банды Четырех — "Паттерны проектирования". Большинство примеров было дано на языке C++, но Smalltalk также присутствовал там, где его использование давало дополнительный выигрыш.
Лучшей книгой о паттернах в Smalltalk является книга самого Кента Бека "Smalltalk Best Practice Patterns". Ее прочитали многие разработчики, не знающие этого языка, которые, вместе с тем, отметили, что это одна из лучших книг по объектно-ориентированному программированию. Стиль написания программ в среде Smalltalk является наиболее естественным для объектного подхода, поэтому его изучение может положительно сказаться на качестве разработки в целом.
Экстремальное Программирование
Практики Экстремального Программирования (по крайней мере, те, которые непосредственно касаются разработки) являются логичным обобщением всего того, что разработчики на Smalltalk применяли уже долгое время. Сам Кент Бек однозначно высказывается, что Smalltalk явился той питательной средой, в которой выросло XP. Парадокс заключается в том, что XP по своей популярности намного превзошло своего прародителя. Экстремальное Программирование сыграло свою определенную роль — популяризовало среди широкого круга разработчиков способ разработки, который характерен именно для Smalltalk.
Рассмотрим некоторые практики Экстремального Программирования:
• Simple Design. Сам язык чрезвычайно прост: в нем только пять ключевых слов, одна базовая конструкция и несколько вспомогательных. Все базируется на объектах и посылке сообщений между ними.
• Refactoring. Smalltalk является очень открытой к изменениям системой. Не нужно тратить время на паузы компиляции, любую идею можно тут же испробовать прямо по ходу работы приложения. Все это способствует быстрой апробации множества идей. Выгоднее не сразу закладывать универсальный дизайн, а начать с простого и дальше продвигаться небольшими шагами, расширяя систему по мере необходимости. Этому также способствует наличие автоматизированного средства — Refactoring Browser. Впервые он был создан для среды VisualWorks Smalltalk и позже стал появляться в оболочках для Java — таких, как IDEA и Eclipse. Некоторые разработчики уже не представляют свою работу без Refactoring Browser. В данный момент рефакторинг стал очень популярным благодаря одноименной книге Мартина Фаулера. На написание этой книги его вдохновил тот подход, который Кент Бек и другие Smalltalk'еры каждодневно применяли при разработке программ.
• Test-First Design. Smalltalk является динамически типизированным языком, что означает отсутствие проверок типов во время компиляции. Казалось бы, это должно приводить к большему числу ошибок, чем в статически типизированных языках. В общем случае это неверно. Раннему обнаружению ошибок способствует его развитая динамическая среда. Но среди разработчиков бытует мнение, что язык со строгой типизацией позволяет выловить большинство ошибок. А это расходится с мнением экспертов, что на тестирование нужно выделять до половины ресурсов проекта. Просто те ошибки, которые обнаруживает компилятор, — это далеко не все ошибки, которые могут содержаться в системе. Гораздо важнее удостовериться, что система выполняет именно то, что было задумано, и тестирование в любом случае остается очень важным фактором проекта.
Кент Бек разработал оболочку для модульного тестирования программ на Smalltalk — позже она была названа SUnit. Совместно в Эрихом Гамма они портировали ее для языка Java — так появился JUnit. И с этого момента xUnit framework получил широкую известность.
• Хотя следует отметить, что заслуга xUnit не столько в том, что он позволяет тестировать модули программы, сколько в том, что с его помощью реализуется Test-First Design — подход, при котором тесты пишутся раньше кода, который они тестируют. Практика показывает, что такой вид дизайна часто приводит к оптимальной структуре системы.
Заключение
Самый первый вопрос, возникающий у многих относительно Smalltalk: если он такой хороший, почему же он такой непопулярный? Как всегда, на него непросто дать однозначный ответ. Первое, что приходит на ум: а когда в нашем мире действительно хорошая вещь была очень популярной? Среди объективных факторов стоит выделить следующие:
• Необычный синтаксис. Многие из тех, кто начинал с Pascal или C, не могут к нему привыкнуть. И это несмотря на то, что он в большей степени напоминает предложения на естественном языке. Те, кто начинает изучение программирования со Smalltalk, никаких проблем с синтаксисом не имеют.
• Объектный подход. За тридцать с лишним лет, которые прошли с момента появления объектного подхода, индустрия так и не приняла его. Большей популярностью пользуются псевдообъектно-ориентированные гибриды, такие, как C++ и Java.
• Производительность. Поначалу производительность приложений на Smalltalk была существенно ниже, чем у аналогичных программ, написанных на C. Это сдерживало многих разработчиков, так как скорость обычно является одним из определяющих факторов выбора технологии. Но времена меняются. Теперь благодаря таким проектам, как Animorphic Smalltalk, производительность больше не является проблемой. В умах разработчиков также намечается перелом — в большинстве случаев выгоднее написать программу вдвое быстрее, чем написать вдвое более быструю программу.
• Маркетинг. В данный момент у Smalltalk нет хозяина, который мог бы вложить миллионы/миллиарды долларов в его развитие, как это было сделано с VB/Java/C#. Компании, которые раньше занимались продвижением Smalltalk, сослужили ему очень плохую службу. История могла бы пойти по другому пути, если бы они согласились продать лицензию на виртуальную машину Smalltalk для языка Visual Basic компании Microsoft.
Однако благодаря новым компаниям-разработчикам, таким, как Cincom, Object-Arts и SmallScript, у Smalltalk есть будущее. В частности, Cincom сообщает о росте продаж VisualWorks Smalltalk на 10% ежегодно. Также намечается тенденция возвращения к разработке на Smalltalk у компаний, которые использовали его в прошлом. Вот краткий перечень компаний, которые продолжают пользоваться Smalltalk: AMD, BMW, Chrysler, Deutsche Bank, FedEx, Nokia, Texas Instruments, Volkswagen.
Все эти компании не могут ошибаться. Кроме того, есть тенденция к умалчиванию факта использования Smalltalk, так как это часто рассматривается как конкурентное преимущество.
Есть комментарии? Пишите.
Денис "Denver" Мигачев,
Владимир "Vovin" Лешкевич,
http://www.smalltalk.ru
Компьютерная газета. Статья была опубликована в номере 16 за 2003 год в рубрике программирование :: разное
