М-м-м, я с вами согласен. Я когда-то пришел к выводу, что ООП это не столько методология программирование, сколько способ организации кодом. Я поясню свою мысль: с увеличением объема программ (в строках, оперируемых сущностях) возникает проблема управления большими объемами кода. И ООП предлагает такой подход: компоновка в одном пространстве данных и процедур, работающих с этими данными. Мы инкапсулируем в отдельном контейнере данные и процедуры.
Словом, как всегда, разделяй и властвуй.
Все остальное — полезные, удобные добавки вокруг.
А так, как ни крути, все равно все сведется к ассемблеру
Могу ошибаться, но по слухам в Транзасе довольно долго делали симуляторы и всякую виртуальную реальность на Smalltalk-е, пользуясь тем фактом, что «сверх-скорость» нужна не везде. Да и игры бывают разные… Не все так однозначно.
Я работал в Транзасе в той самой виртуальной реальности (Trans-Force). Симулятор, это речь о вертолетном тренажере.
Работа с этими проектами на Smalltalk и сейчас ведется (два года назад точно велась).
В обоих проектах Smalltalk используется для написания управляющей программы. За вертолетный тренажер не скажу точно, но, вроде, они все моделирование физики поведения вертолета в Smalltalk перевели. Могу ошибиться. Управление комплексом Trans-Force все написано на St. А теперь жирное НО. Сама визуализация трехмерного пространства (полета) — это другая среда, вроде, называлась «Аврора». На чем написана не знаю, но это не smalltalk.
Amber видел. Пока как приложить к веб-проектам не знаю. Скажите, вот есть meteorjs, мне он нравится. Как его можно использовать вместе с Amber? Если никак, то пока он неинтересен.
1. Да возможно очищение. Но жесткое вряд ли. Поскольку язык динамической типизации, то самостоятельно определить, что выкидывать, а что нет он не в состоянии.
2. Нет, синтаксис языка вы сами изменить не в состояниии. Есть штук 5 жестко определенных конструкций и их изменить нельзя.
3. Можно. Иногда это не будет 1 в 1, но что-то похожее. Так как GUI все таки не native
4. Нет, нельзя. То что вы упоминаете, всего лишь возможность выгрузки пакетов в файлы для интеграции с GIT. Собственные репозитарии кода более удобны для просмотра изменений (версионность базируется на методе, не на файле); Плюшек типа pull request нету
5. Переносить не очень сложно, но различия существуют.
Начинать лучше с Pharo (pharo.org) — относительно большое и отзывчивое коммьюнити, наиболее прогрессивный диалект
Кесарю — кесарево, богу — богово.
Не надо писать игр на smalltalk. Он не для этого.
Давайте я расставлю точки над i
Плюсы:
Основное преимущество St — это офигительное, удобное конструирование. Вам будет легко выделить классы, построить взаимодействие между ними, увидеть как это работает. Представьте себе прозрачный двигатель внутреннего сгорания — вы увидете как взаимодействуют объекты внутри вашей программы. Вы сможете в лобой момент сказать двигателю «замри», подкрутить в нём что-то, изменить поведение объекта, и сказать «отомри» и он пойдет работать с всеми изменениями. Язык предоставляет исключительные возможности по конструированию.
Это преимущество вытекает из следующих предпосылок:
1. Синтаксис близкий к английскому языку. Сравните вызов метода в обобщенной сигнатуре для основных ЯП:
paintItemsInArea(array, canvas, rectangle)
и для St
paintItems: array on: canvas at: rectangle
2. Основной инструмент IDE — class browser. Непревзойденный инструмент для работы с кодом. Позволяет абстрагироваться от бесконечных файлов и их содержимого. Вы видите только список пакетов, классов в них, методов в классе и реализацию выбранного метода. Очень удобно.
Мне этого не хватает в ruby/js
3. Отличная поддержка рефакторинга. В современных IDE это тоже есть, но скорее для галочки. Здесь это один из основных инструментов.
Минусы:
St — это не C++ и скорости ожидать не надо. По производительности он сравним с Java/C#.
Не надо писать сложные веб приложения на нем с rich client-side, поддержка JS бибилотек есть, но работать с ней неудобно. Возможно, это чисто мое имхо. Мне могут возразить, что вот у нас есть знаменитый Seaside web framework, только что с того? В общем для веба — не он.
Заключение: превосходен для прототипирования сложных объектных систем энтерпрайз уровня. Вырабатывает отличные скиллы по ООП.
VisualWorks Smalltalk (платный, есть бесплатная версия для себя без ограничения возможностей)
Pharo (бесплатная)
Под каждую платформу есть своя виртуальная машина, здесь как для Java. Есть возможность скомпоновать исполняемую виртуальную машину и образ в единый бинарник. Только смысла в этом не много. Надо понимать, что если вы пишете тиражируемый софт для домохозяек, то Smalltalk не ваш выбор.
GUI кроссплатформенный и реализован весь на Smalltalk. Отличаются только вызовы к system API для создания окон, но это все инкапсулируется в виртуальной машине. Так что, файл образа абсолютно переносим с платформы на платформу
Генерация PDF есть.
Есть некоторое количество разных интересных библиотек и инструментов.
Но надо понимать, что из-за небольшого размера коммьюнити, очень многие инструменты не реализованы или в находятся в зачаточном состоянии.
Словом, как всегда, разделяй и властвуй.
Все остальное — полезные, удобные добавки вокруг.
А так, как ни крути, все равно все сведется к ассемблеру
Я работал в Транзасе в той самой виртуальной реальности (Trans-Force). Симулятор, это речь о вертолетном тренажере.
Работа с этими проектами на Smalltalk и сейчас ведется (два года назад точно велась).
В обоих проектах Smalltalk используется для написания управляющей программы. За вертолетный тренажер не скажу точно, но, вроде, они все моделирование физики поведения вертолета в Smalltalk перевели. Могу ошибиться. Управление комплексом Trans-Force все написано на St. А теперь жирное НО. Сама визуализация трехмерного пространства (полета) — это другая среда, вроде, называлась «Аврора». На чем написана не знаю, но это не smalltalk.
Amber видел. Пока как приложить к веб-проектам не знаю. Скажите, вот есть meteorjs, мне он нравится. Как его можно использовать вместе с Amber? Если никак, то пока он неинтересен.
И из коробки это не запустится. Мне пришлось вырезать кучу проверок
Посмотрите pharo.org, там среда более sexy look
2. Нет, синтаксис языка вы сами изменить не в состояниии. Есть штук 5 жестко определенных конструкций и их изменить нельзя.
3. Можно. Иногда это не будет 1 в 1, но что-то похожее. Так как GUI все таки не native
4. Нет, нельзя. То что вы упоминаете, всего лишь возможность выгрузки пакетов в файлы для интеграции с GIT. Собственные репозитарии кода более удобны для просмотра изменений (версионность базируется на методе, не на файле); Плюшек типа pull request нету
5. Переносить не очень сложно, но различия существуют.
Начинать лучше с Pharo (pharo.org) — относительно большое и отзывчивое коммьюнити, наиболее прогрессивный диалект
Не надо писать игр на smalltalk. Он не для этого.
Давайте я расставлю точки над i
Плюсы:
Основное преимущество St — это офигительное, удобное конструирование. Вам будет легко выделить классы, построить взаимодействие между ними, увидеть как это работает. Представьте себе прозрачный двигатель внутреннего сгорания — вы увидете как взаимодействуют объекты внутри вашей программы. Вы сможете в лобой момент сказать двигателю «замри», подкрутить в нём что-то, изменить поведение объекта, и сказать «отомри» и он пойдет работать с всеми изменениями. Язык предоставляет исключительные возможности по конструированию.
Это преимущество вытекает из следующих предпосылок:
1. Синтаксис близкий к английскому языку. Сравните вызов метода в обобщенной сигнатуре для основных ЯП:
и для St
2. Основной инструмент IDE — class browser. Непревзойденный инструмент для работы с кодом. Позволяет абстрагироваться от бесконечных файлов и их содержимого. Вы видите только список пакетов, классов в них, методов в классе и реализацию выбранного метода. Очень удобно.
Мне этого не хватает в ruby/js
3. Отличная поддержка рефакторинга. В современных IDE это тоже есть, но скорее для галочки. Здесь это один из основных инструментов.
Минусы:
St — это не C++ и скорости ожидать не надо. По производительности он сравним с Java/C#.
Не надо писать сложные веб приложения на нем с rich client-side, поддержка JS бибилотек есть, но работать с ней неудобно. Возможно, это чисто мое имхо. Мне могут возразить, что вот у нас есть знаменитый Seaside web framework, только что с того? В общем для веба — не он.
Заключение: превосходен для прототипирования сложных объектных систем энтерпрайз уровня. Вырабатывает отличные скиллы по ООП.
Про dolphin smalltalk — забудьте, он умер и вряд ли восстанет из пепла.
Под каждую платформу есть своя виртуальная машина, здесь как для Java. Есть возможность скомпоновать исполняемую виртуальную машину и образ в единый бинарник. Только смысла в этом не много. Надо понимать, что если вы пишете тиражируемый софт для домохозяек, то Smalltalk не ваш выбор.
GUI кроссплатформенный и реализован весь на Smalltalk. Отличаются только вызовы к system API для создания окон, но это все инкапсулируется в виртуальной машине. Так что, файл образа абсолютно переносим с платформы на платформу
Есть некоторое количество разных интересных библиотек и инструментов.
Но надо понимать, что из-за небольшого размера коммьюнити, очень многие инструменты не реализованы или в находятся в зачаточном состоянии.