"Я придумал термин "объектно-ориентированный", и вот что я вам скажу,
я не имел ввиду С++."
-- Алан Кей, OOPSLA '97
"Наши программы живут дольше, если у нас получается придумать
более простые абстракции для самих себя, и я думаю,
что способы достичь этого в Smalltalk намного более мощные чем в
традиционных языках."
-- Рон Джефрис.
"В сущности, Smalltalk это язык больше ориентированный на людей,
чем на компьютеры."
-- Алан Найт.
"Smalltalk - лучший из всех существующих smalltalk-ов."
(об использовании С++ для кодирования идиом из динамических
языков, таких как Lisp или Smalltalk)
-- Бьярн Страуструп.
"Ну, я думаю, что одна из вещей, которая мне всегда нравилась в Smalltalk,
это то, что там всё есть объект. Это очень всё упрощает, так как не
важно с какими данными вы работаете, вы можете переместить их из
точки А в точку Б как объект. Некоторые операции могут проводиться над
любым объектом. Вы можете положить его в любой контейнер."
-- Эндерс Хейльсберг (разработчик языков Object Pascal и C#).
"Говорить, что Java проще чем C++ это, как утверждать, что К2 ниже, чем Эверест."
-- Ларри О'Браен (редактор журналов Computer Language и Software Development).
"Почему Smalltalk? Потому, что Smalltalk использует упрощенный вариант английского.
Существительные и глаголы. Объекты - это существительные. Глаголы - это сообщения,
посылаемые от одних объектов к другим. Просто, как раз, два, три. Больше не нужно
писать непонятные программы. Значит, почти каждый может научиться писать программы
на Smalltalk-е"
-- Питер Вильям Лаунт.
"Основная проблема в сообществе программистов на С++, это попытки использовать
стандартный С++ либо как облагороженный С, либо как Smalltalk для бедных."
-- Бьярн Страуструп (создатель С++).
"Smalltalk, с его акцентом на человеческом аспекте программирования,
был той питательной средой, на которой выросло
Экстремальное Программирование. Smalltalk всё еще не имеет себе равных
по уменьшению стоимости изменений в течении всего времени жизни проекта.
А это то, без чего существование XP не возможно."
-- Кент Бек.
"Экстремальное программирование изначально ... это набор практик,
которые относятся к Smalltalk-у. Очень инкрементальная разработка.
Очень простой дизайн. Тестирование, и так далее."
-- Рон Джефрис.
Алан Кей, The History Of Smalltalk.
"Дизайн Smalltalk -- и его существование вообще -- обусловлен тем,
что все, что мы можем описать, возможно представить рекурсивной композицией
отдельных видов поведенческих строительных блоков, которые внутри
самих себя скрывают свою текущую комбинацию состояния и процессов, и
могут взаимодействовать друг с другом только посредством обмена
сообщениями."
Алан Кей,
Squeak mailing list.
"Хочу намекнуть, что на последней OOPSLA я пытался напомнить всем,
что Smalltalk это НЕ ТОЛЬКО синтаксис или библиотека классов,
это даже не классы вообще. Я прошу прощения, что давным давно
выдумал термин "объекты" для этой темы, потому что большинство
людей сосредоточились на менее важной идее.
Более важная идея это "обмен сообщениями", то есть то, что лежит в
основе Smalltalk/Squeak (и именно то, что никогда не было полностью
доделано во время работы в Xerox PARC). В японском языке есть
маленькое слово "мэ", означающее "то, что лежит между". Возможно,
что наиболее близкий эквивалент -- "промежуточный".
Для создания мощной и способной развиваться системы нужно сосредоточиться
больше на проектировании того, как модули взаимодействуют между собой,
чем на внутренних для модулей свойствах и поведении. Подумайте об интернете.
Чтобы жить, он, во-первых, должен допускать существование множества различных
идей и реализаций единого стандарта, и, во-вторых, допускать в той или иной
степени взаимодействие между этими идеями.
Если вы сосредоточитесь на обмене сообщениями (и поймёте,
что хорошая метасистема может использовать позднее связывание
между различными архитектурами второго уровня, которые используются в
объектах),
то большинство дискуссий о языках, интерфейсах с пользователем,
операционных системах, которые были подняты в этом треде становятся
действительно спорными.
Именно по этой причине, на последней OOPSLA я жаловался, что, хотя
в PARC мы постоянно изменяли Smalltalk, считая, что он постоянно
развивается,
когда ST попал в большой мир он был больше воспринят как "нечто,
что нужно вызубрить", как это было с Паскалем или Алголом.
Smalltalk-80 никогда не превратился в следующую, лучшую версию ООП.
Учитывая текущий низкий уровень программирования вообще, я думаю, что
это большая ошибка."
Энди Бауэр, создатель Dolphin Smalltalk
Smalltalk опасен. Smalltalk это как наркотик.
Мой совет Вам - не пробуйте его; он может разрушить Вашу жизнь.
Когда вы найдете время изучить его (ДЕЙСТВИТЕЛЬНО изучить) вы увидите,
что нет ничего (пока), что может с ним сравниться.
Конечно, как и для любого наркотика, его опасность зависит от вашего
характера. Возможно, что когда Вы попадете в зависимость, Вам будет
тяжело (если вообще возможно) вернутся назад к другим языкам
программирования и, если Вас все-таки заставят вернуться, Вы можете
стать постоянно ворчащей озлобленной личностью. Кто знает, возможно Вы
даже уйдете из софтверной индустрии вообще, так как ничего более не
достойно Ваших ожиданий.
Эрик Наггум, переписка Usenet
> Всегда нелегко освоить что-то новое. Тут, конечно, присутствует
> экономический фактор что, для примера, разработчики на C++ по два за пени,
> а Eiffel и Smalltalk программисты далеко нет.
Это одно из наиболее сбивающих с толку неправильных применений статистики.
Только то, что высока вероятность попасть в C++ программиста, кинув камень в толпу,
не означает более высокую вероятность его способности заменить Вашего C++ программиста,
нежели поиск подходящей замены для Eiffel или Smalltalk программиста. Оттого, что Вы
вынуждены просеять толпы идиотов, которые заявляют, что они знают C++, усилия,
необходимые для поиска настоящей замены могут быть значительно меньше в случае Eiffel и Smalltalk.
Кроме того, если вы можете найти хорошего программиста, высок шанс, что он сможет в
достаточной мере выучить любой язык программирования, который вы используете, за время поиска
хорошего C++ программиста. И, в общем случае, обучение по исходным текстам
предыдущего программиста намного проще, чем изучение языка с нуля.
Я был свидетелем этого. Компания, на которую я работал, ввела новый уровень менеджмента,
который был абсолютно излишен. Так что новый менеджер должен был доказать себе, что он
делает настоящую работу и потратил много времени в спорах против использования нераспространенных
языков . И, в конце концов, сделал невозможным использование чего бы то ни было, кроме Java, после
чего много хороших специалистов ушло. И как-то случилось, что Java разработчик серьезно заболел.
Менеджер не мог заменить его на протяжении пяти месяцев его отсутствия. Другие Java разработчики
не могли сделать эту работу. К изумлению менеджера, выбор языка имел меньшую роль, чем способности
программистов. В заключение этой истории менеджер оказался в такой ситуации, что было невыгодно
держать квалифицированных программистов - он сам мог принимать архитектурные решения, а программисты
просто кодировали это. Он теперь мог вернуться к своему правилу использования только распространенных
языков нанимая только неопытных программистов, которые говорили неправду о своем знании языка.
Насколько я знаю, ничего интересного не случилось с этой компанией за долгое время.
Самюэль Шустер, разработчик VisualWorks, из переписки Usenet.
VisualWorks является прямым преемником оригинального Smalltalk-80,
который вышел из Xerox PARC. Smalltalk-80 начинался в ранних 70-х и
предшествует даже ДОСу [Речь идёт о высказанном в дискуссии мнении,
что причина наличия эмулированных виджетов в том,
что широкораспространённая в 80-х гг. MS-DOS не имела
графического интерфейса. -- Прим. перев.]...
Фактически это была операционная система. С течением времени,
St-80 перешел на более широкораспространённые машина, включая
печальноизвестную Apple Lisa. Таким образом, дело не в ДОСе самом по
себе. Фактически, Smalltalk был второй по счету графической оконной
системой (или первой, если не считать Sketchpad, который обычно
учитывают).
Это значит, что не было никаких виджетов, когда он начинался...
все прочие впоследствии подражали Smalltalk-ам. Либо взяли за основу
и доработали.
VW изначально был кроссплатформенным. Было принято решение эмулировать
системы на которых он был запущен. Если подумать, то это наиболее
очевидное решение. В то время, пользовательский интерфейс был простым, и
VW легко мог эмулировать все те простые виджеты.
Время шло, и сообщество программистов перестало предавать значение
эмулированным виджетам, в основном потому, что очень тяжело поддерживать
их соответсвие множеству новых стилей, и каждый программист, создающий
эмулированные виджеты всегда находился в позиции догоняющего. Естесвенно,
с течением времени стали относиться небрежно и к объектным технологиям,
виртуальным машинам, сборщикам мусора и динамической типизации. (К
последним трём, в основном, из-за BASIC-а и dBase, которые, естественно,
не были "настоящими" инструментами для программиста).
В 90-х гг. появились Smalltalk-и, использующие "родные" виджеты
(Smalltalk/V - VisualSmalltalk) и смешанные наборы из эмулированных и
"родных" виджетов (VisualAge). Где-то в 1996-97 гг. инженеры VW
разработали две различных системы для создания графического
пользовательского интерфейса и позволяющие использовать "родные"
виджеты в VW. Эти системы/проекты назывались "Ван Гог" и "Jigsaw".
Ни одна из них не была выпущена в свет из-за владельцев и менеджеров
VW и их, по-видимому врождённой, неспособности владеть или управлять.
Связывать задержку в выпуске с трудностями внесения изменений не
правильно, хотя, вне уровня "молвы", я уверен, может показаться,
что это так и было. Больше было похоже на сознательные помехи развитию.
Сейчас это не так.
Проект "Поллок" [Поллок -- художник абстракционист.
http://www.askart.com/artist/p/jackson_pollock.asp -- Прим. Перев.]
в VW является предвестником, и необходимой частью к появлению поддержки
"родных" виджетов в VW. В ближайшее время будет представлена бетта 2, и
будет еще один бетта-выпуск перед выходом окончательной версии.
Поллок -- это замена "полностью эмулирующей системе", которая может
использовать "родные" виджеты. И проект "Ван Гог" и "Jigsaw" ("Лобзик")
выбрали (правильно) путь создания заново системы с эмулированными
виджетами в основе и с "родными" виджетами на верху, так как
существующая система просто не способна поддерживать "родные"
виджеты (причин множество, и если вы захотите угостить меня,
я буду рад перечислить эти причины со всеми скучными подробностями).
Поллок, однако, будет создан в несколько этапов. Во-первых, эмулированные
виджеты начнут работать быстрее чем всё, что вы видели до этого.
За тем, в отдельном проекте, называемом сейчас "Шагал" и еще даже не
начатом, будут добавлены "родные" виджеты.
Должен сказать, что есть не так много других вариантов, кроме как
использовать XP, делая небольшие кусочки работы за раз, и делая частые
промежуточные выпуски.
Вот и весь ответ.
Что касается того, почему в VisualAge немного медленнее со своими
виджетами, то я могу сказать пару слов.
Во-первых, у VW самая быстрая из всех виртуальных машин, имеющихся на
рынке. Изначально я собирался написать "Smalltalk ВМ", но, я уверен,
что она быстрее любой Java ВМ, которые я видел. [Следует заметить,
что в отсутсвие однозначных тестов это более чем спорное утверждение.
Особенно если вспомнить, что ВМ существует не только у Java и ST
-- Прим. Перев.]
Во-вторых, разработчики графического интерфейса в VA приняли несколько
интересных решений, в надежде на то, что это поможет использованию "родных"
виджеты на множестве платформ. В результате слой абстракции выглядит
слегка, я бы сказал, процедурным и кривым. Я не говорю, что они не могут
всё сделать правильно, ведь в конце концов они то сделали. И, за
исключением того, что система запускается на ужасной и тормозной
платформе -- Java, SWT (созданная теми же людьми) является примером того,
что во-второй раз получается лучше.