Как изучение Smalltalk может улучшить ваши навыки программиста

https://medium.com/smalltalk-talk/how-learning-smalltalk-can-improve-your-skills-as-a-programmer-fc5b2f56685
  • Перевод


Smalltalk обычно воспринимается как старый, умирающий язык – антиквариат из ушедшей эпохи. Нет ничего более далёкого от правды.

Smalltalk по-прежнему очень актуален. Это отличный язык для обучения программированию людей, не имеющих технического образования. Это превосходный язык прототипирования для стартапов. Это мощный промышленный язык, используемый как крупными, так и малыми компаниями по всему миру. Есть веские причины рассмотреть использование современного Smalltalk сегодня, поскольку многое было сделано за последнее время, чтобы улучшить его возможности.

Вы не обязаны использовать Smalltalk в промышленном программировании, но попробуйте кое-что написать на нём и прислушайтесь к своим ощущениям. Они должны быть знакомы, потому что реализация объектно-ориентированной парадигмы в Smalltalk настолько великолепна, что повлияла на целое поколение ОО языков, таких как Objective-C, Python, Ruby, CLOS, PHP 5, Perl 6, Erlang, Groovy, Scala, Dart, Swift и многих иных.

Изучая Smalltalk, вы поймете, как все эти полезные функции в современных языках стали реальностью. Изучение Smalltalk может также дать вам преимущество среди ваших коллег, и ещё он может быть отличным инструментом для обучения программированию.

Что нам дал Smalltalk?


Вклад Smalltalk в индустрию программного обеспечения огромен. Просто взгляните на этот список функций и технологий, которые он представил:

  • Smalltalk представил миру виртуальную машину (VM), которая позволяет программному обеспечению быть независимым от платформы. Это та же технология, которую поддерживает Java (JVM) и .NET, а также Android (Dalvik).

  • Smalltalk был пионером JIT компиляции (just-in-time), методики резкого повышения производительности программного обеспечения байт-кодов, такого как Java.

  • В Smalltalk появилась первая современная среда разработки (IDE), которая включала текстовый редактор, браузер системы и классов, инспектор объектов и свойств и отладчик. Это привело к возникновению многих IDE, которые сегодня используют разработчики, такие как Visual Studio, Xcode и IntelliJ IDEA. Лично я считаю, что ни одна из этих IDE не может сравниться со Smalltalk в простоте, элегантности и скорости разработки; оригинал все ещё лучший!

  • С самого начала Smalltalk имел замыкания, представляющие собой функции первого класса, имеющие лексическую область видимости. По сути, замыкание – это функция обратного вызова (callback) которая может видеть нелокальные переменные в том месте, где они были определены. Это может помочь вам написать гораздо более компактный и читаемый код. Замыкания находят своё применение во многих языках, например, в Java, C# и PHP.

  • Smalltalk был первым языком, поддерживающим «живое» программирование и усовершенствованные методы отладки, такие как проверка и изменение кода во время выполнения. Сегодня отладка в реальном времени возможна в C# с помощью Visual Studio функции «Edit and Continue» и Java с использованием HotSwap.

  • Smalltalk представил миру концепцию MVC (Model-View-Controller). MVC – это программный архитектурный шаблон для реализации пользовательских интерфейсов. Он популярен в настольных графических приложениях и веб-приложениях. В наши дни это та самая архитектура, которую в первую очередь изучают веб-разработчики.

  • В значительной степени именно Smalltalk ответственен за разработку на основе тестов (TDD) и экстремальное программирование (XP), которые очень важны в нынешних «гибких» (Agile) практиках.

  • Smalltalk сделал «утиную типизацию» расхожим выражением (ну, если оно ещё расхаживает по вашему дому). В утиной типизации проверка типов отложена до выполнения программы – когда рефлексия используются для обеспечения правильного поведения. Сегодня мы находим утиную типизацию во многих языках, включая Java, Python, Common Lisp, Go, Groovy, Objective-C и PHP.

  • Smalltalk первым ввёл использование объектных баз данных. Хотя они и не получили широкого распространения, всё же объектные базы данных имеют свои нишевые рынки. Лучшим примером объектной базы данных является GemStone/S, который хорошо подходит для масштабируемых, высокопроизводительных, многоуровневых распределённых систем.

  • Smalltalk представил нам первый браузер рефакторинга. Конечно, поддержку рефакторинга можно найти в большинстве современных IDE.

  • Smalltalk сыграл важную роль в разработке графического пользовательского интерфейса (GUI) и пользовательского интерфейса «что видишь, то и получишь» (WYSIWYG).

Но как изучение Smalltalk сделает меня лучшим разработчиком?


Smalltalk имеет целый ряд функций, намного опередивших своё время:

  • Основанное на образе сохранение
  • Объекты: все является объектом, а объекты обмениваются только сообщениями (наиболее «чистая» реализация ООП и одна из самых ранних)
  • «Живое» программирование
  • Расширенные методы отладки, такие как изменение кода на лету
  • Простой, незагромождённый интерфейс IDE
  • Предметно-ориентированные языки (DSL): единственный способ работы Smalltalk, поэтому программистам необходимо сосредоточиться на проблеме, используя язык и нотацию, являющуюся естественной для этой проблемы

И есть ещё несколько фич, которые делают Smalltalk особенным.

По существу, ключевым преимуществом Smalltalk как продуктивного языка и инструмента обучения является то, что он снимает большую часть, если не весь, когнитивный стресс в промышленных OO языках, таких как Java. Smalltalk не содержит синтаксического мусора или сбивающих с толку функций. Он вежливо уступает вам дорогу, так что вы можете сосредоточить всё своё внимание на проблеме или приложении. Дело не в том, что Java – плохой язык, потому что он более сложный (и имеющий 30-символьные имена классов); я говорю о том, что изучение необремененного лишними функциями OO языка на самом деле может сделать вас лучшим Java-программистом, как только вы поймёте концепции OOП с другой точки зрения.

Устранение когнитивного стресса является целью многих языков – например, Python, Ruby, Elixir, Elm и Go. Даже если вы его не чувствуете, стресс есть. Часто говорят, что программирование в Smalltalk или Python похоже на Дзен; ваше сознание просто течёт легко и непринуждённо вместе с решаемой задачей. Это красота и ценность языковой простоты, и Smalltalk обладает ею в полной мере.

В Smalltalk концепция ООП очищена до базовых понятий классов и методов, метаклассов и рефлексии, и, самое главное, передачи сообщений. Smalltalk, в силу своей объектной чистоты и согласованности, даст вам глубокое понимание объектно-ориентированного программирования и того, как использовать его с максимальной эффективностью.

Простота Smalltalk также делает его идеальным учебным языком для обучения программированию, особенно если у вас нет технической подготовки. Простота языка и инструментов позволяет сосредоточить ваши усилия на изучении методов программирования, а не языковых конструкций и формализма.

«Живой» отладчик значительно сокращает цикл редактирование – тестирование – отладка.

Как работает Smalltalk? Основанный на образе подход к программированию


Главная причина успеха Smalltalk – подход к созданию программного обеспечения, основанный на образе. Образ представляет собой моментальный снимок памяти, который содержит все объекты в вашем запущенном приложении. Он инкапсулирует всё состояние выполнения вашей программы. Образ можно сохранить на диск и позже возобновить точно с того места, где вы остановились!

«Образ Smalltalk» может звучать немного необычно, но на самом деле он очень похож на нечто, широко используемое сегодня в ИТ: системные образы в виртуализации ОС, такие как в VMware и VirtualBox. Не забывайте, что Smalltalk первоначально был автономной операционной системой, созданной в Xerox PARC в 1970-х годах.

Образ Smalltalk похож на DOM (Document Object Model) в веб-приложении. Обратите внимание, что веб-приложение представляет собой по существу операционную систему, изолированную в веб-браузере и лишённую прямого доступа к файловой системе хоста и другим ресурсам. Когда веб-браузер закрывается, состояние динамического веб-сайта может быть сохранено или кэшировано, и в следующий раз, когда браузер возобновит работу, веб-сайт может быть восстановлен в браузере (с некоторыми ограничениями).

Даже электронная таблица очень близка к концепции образа. Она инкапсулирует всю нужную информацию. Она не может получить доступ к системным ресурсам. Её можно сохранить и восстановить. И вы должны знать, что электронные таблицы по-прежнему используются для разработки сложных моделей и приложений с собственным языком.

В общем, концепция образа широко распространена. Это настолько удобный способ разработки программного обеспечения, что версия образа была создана для JavaScript в Lively Kernel.

Всё в Smalltalk является объектом


Без исключений: всё есть объект. Нет примитивных типов данных. Нет таких управляющих структур, как выбор и итерация! Всё в Smalltalk делается путём посылки сообщений объектам. Именно это делает Smalltalk настолько простым, элегантным и лёгким в освоении. Именно это делает язык настолько чистым синтаксически.

Например, следующий фрагмент кода расширяет класс Number для поддержки нерекурсивной операции факториала:

Number extend [
  my_factorial [
    (self < 2) ifTrue: [ ^1 ]
               ifFalse: [ |c|
                 c := OrderedCollection new.
                 2 to: self do: [ :i | c add: i ].
                 ^ (c fold: [ :a :b | a * b ] ) ]
]].

7 factorial printNl.
7 my_factorial printNl. “should be the same result as the previous line”

Здесь ifTrue: это ключевое сообщение посылаемое булевому объекту, возвращённому выражением (self < 2). Аргументом для сообщения является блок кода (обозначенный квадратными скобками). На самом деле ifTrue: это первая часть сообщения с двумя аргументами, вторая часть ifFalse:.

Унарное сообщение new отправляется классу OrderedCollection для создания новой коллекции. Сообщение printNl отправляется в результат (являющийся объектом) отправки сообщения my_factorial числу 7. Всё это очень похоже на естественный язык!

Рефлексия в Smalltalk


Рефлексия в Smalltalk особенно ценна как механизм проверки собственной структуры и вычислений во время выполнения. Это очень мощный механизм, позволяющий программам расширять себя новыми классами и методами или задавать вопрос «кто послал это сообщение мне?»

Рефлексия используется для реализации мощного способа обработки ошибок. Когда объект получает сообщение, которое он не реализует, ему посылается сообщение doesNotUnderstand: и код исходного сообщения. Есть много вещей, которые программа может делать с сообщением doesNotUnderstand:, включая расширение своей функциональности!

Концепция образа и рефлексия также позволяют Smalltalk устранить границу между приложением и IDE. Всё, что нужно для разработки, отладки и запуска приложения, находится в образе. Нет необходимости когда-либо покидать среду вашего приложения. Это совершенно целостный подход к разработке программного обеспечения, который делает всё более дзен-подобным и продуктивным.

Возрождение Smalltalk


Последние 15 лет развития в мире Smalltalk сделали язык более привлекательным.

Smalltalk теперь доступен для программирования веб-интерфейсов с использованием Amber Smalltalk, который транслируется в JavaScript. Выполнение Amber происходит исключительно в браузере. Одна из удивительных особенностей Amber в том, что при импорте библиотеки JavaScript её объекты можно обрабатывать так же, как объекты Smalltalk.

В 2002 году была выпущена веб-платформа Seaside, которая стала самым популярным инструментом для веб-разработки в Smalltalk. Подход, основанный на продолжениях (сontinuation), обеспечил обычный механизм «call / return» для вашего веб-приложения. Это позволило решить проблемы с двойным запросом и кнопкой «Назад». Весьма революционно для своего времени, и до сих пор не реализовано в других веб-фреймворках.

Проект Pharo начался в 2008 году, чтобы сосредоточиться на современных методах разработки программного обеспечения. Он продвинул Smalltalk гораздо дальше, чем предыдущий проект с открытым исходным кодом – Squeak, основанный на диалекте Smalltalk-80. Проект Pharo также начал исследования нового типа IDE под названием Glamorous Toolkit. Он основан на идее, что ваша среда программирования должна быть «пластичной», чтобы соответствовать вашим потребностям.

В прошлом году любимый многими Dolphin Smalltalk стал открытым проектом, предложив ещё один прекрасный вариант для поклонников Smalltalk. Dolphin Smalltalk часто хвалят за то, что он обладает одной из лучших реализаций IDE.

Наследие Smalltalk: программируй с удовольствием


Когда вы используете современные средства разработки программного обеспечения, такие как JVM, Eclipse IDE, замыкания, «живое программирование», MVC, TDD, VMware и даже простое веб-приложение, вспомните об их происхождении в Smalltalk и испытайте уважение к тому, что вы делаете. Будьте признательны ему за языки, которые вы используете, будь то Objective-C, Python, Ruby, Groovy, Scala, Dart или Swift.

Работа с языком, из которого произошли все эти замечательные функции и технологии, предоставляет уникальную возможность значительно улучшить ваши знания, остроту ума и производительность в качестве разработчика программного обеспечения. Слово «удовольствие» не всегда используется в разговорах о программной инженерии, но я думаю, что Smalltalk и его ОО собратья обеспечивают более низкий когнитивный барьер и простоту программирования, которые могут превратить разработку программ в удовольствие.

Об авторе


Ричард Энг – отставной разработчик программного обеспечения из Канады с более чем 30-летним опытом работы в ИТ-индустрии. Он работал в сфере видео графики, баз данных и финансов, программного обеспечения реального времени, мобильных приложений для iOS и Android, а также в веб-разработке. Он писал в основном на C, но также использовал FORTRAN, Tandem TAL, C++, C#, Objective-C, Java, Smalltalk, Python и Go. Сейчас он возглавляет кампанию Smalltalk Renaissance. Большую часть времени Ричард проводит за написанием статей и эссе.
Метки:
Поделиться публикацией
Комментарии 113
  • +9
    С любезного разрешения Mr Richard Eng я начинаю серию переводов его эссе по языку Smalltalk и OO программированию.
    • +1
      круто, я бы с удовольствием почитал
  • +3
    Оригинал:
    Smalltalk made “duck typing” a household word (well, if your house has a programmer in it).

    Перевод:
    Smalltalk сделал «утиную типизацию» расхожим выражением (ну, если в вашем доме ещё ходит программист).

    Жирный плюс за попытку сохранить каламбур, но все-таки если по вашему дому ходит какой-то там программист, то не забудьте его выгнать перед тем как приниматься за smalltalk.

    7 factorial printNl.

    Сообщение printNl отправляется в результат (являющийся объектом) отправки сообщения my_factorial числу 7. Всё это очень похоже на естественный язык!

    Что-то автор слегка тролльнул, выглядит очень похоже на естественный язык, в котором пишут справа налево. Или может имеется в виду, что иврит — самый естесвенный язык, а остальные — так себе.

    Есть много вещей, которые программа может делать с сообщением doesNotUnderstand:, включая расширение своей функциональности!

    Не, подразумевается расширение функциональности сообщения (типа по дефолту там эксепшн, но можно переопределить и писать в лог, например ).

    В целом, действительно интересно — спасибо за перевод и продолжайте, пожалуйста.
    • +1
      выглядит очень похоже на естественный язык, в котором пишут справа налево.

      Ну почему? И пишем и читаем слева направо:
      7 factorial printNl. вполне читается как «спросить у числа 7 его факториал, после чего распечатать его.»
      • +3
        Это описание логики выполнения smalltalk на естественном языке. А вот описание того, что мы хотим сделать выглядело бы как «распечатать факториал числа 7», то есть
        print factorial 7
        

        — и вот это было бы действительно похоже на естественный язык. ( Почти валидный haskell, кстати)
        • –1

          Да, если знак доллара вставить:


          print $ factorial 7
        • 0
          Это естественный язык в польской нотации получается. Число > в стек; факториал (над результатом в стеке) > в стек; распечатать (число из стека).
          • 0
            На чём ни пиши — всё у людей FORTH получается. :)
            • 0
              Ну, если заглянуть во «внутренности» Java, то да… :))
      • +4
        7 factorial printNl. вполне читается как «спросить у числа 7 его факториал, после чего распечатать его.»

        Вы ведь понимаете, что из-за неправильного порядка оригинальных слов вам приходится вставлять другие слова (костыли), чтобы сделать этот порядок осмысленным.

        «Семерки факториал распечатать» — обычный Йода-язык в сравнении с «распечатать факториал семерки».
        • +1
          «распечатать факториал семерки»

          А кому Вы это говорите?

          Смололк как раз и отличается тем, что Вы всегда КОМУ-ТО что то говорите. Как в обычной беседе.
          А по вашему получается Вы в воздух (наверное отдавая команду господу богу) заявляете — «Эй кто ни будь а ну ка быстро распечатать факториал семерки». В реальной жизни такое бывает?
          • 0
            Кому-кому, компьютеру. В каком-либо C# вначале еще стояло бы «Console», то получилось бы консоли. Что-то вроде «Консоль, распечатай факториал семерки»
            • +1
              Эх жертвы функционального программирования))))

              Мы же говорим о приближении к нормальному человеческому языку.

              По Вашему получается Вы в разговоре говорите: "" Э господь (Console) подними Васе руку".

              В смолтолке мы просто Васе говорим — «Подыми руку». Если Вася это умеет — он это сделает. Если не умеет — выдаст сообщение «Не понимаю» (Don't understand). И тут в отличии от других языков мы можем остановится, научить Васю это делать (реализовать метод), после чего Вася подымет руку и выполнение программы ПРОДОЛЖИТСЯ с этой точки.
              • +2
                С каких пор C# — ФП?
                Не, я говорю (обращаясь к компьютеру) «Вкрути лампочку». Ну или к консоли, если это C#, потому что хочу, чтобы это сделала консоль.
                А вы говорите «Вася, вкрути лампочку», хотя Вася — не электрик, а кот.
                Я не понимаю, почему print — метод числа. Я его могу хотеть распечатать в консоль, в веб-сервер, на принтер, все это print и все это необходимо учить делать число? Где логика?
                • –6
                  Ну С изначально был функциональным а потом к нему прикрутили (и достаточно криво) ООП.
                  Не, я говорю (обращаясь к компьютеру) «Вкрути лампочку». Ну или к консоли,

                  А с чего Вы взяли что компьютер (консоль) должен уметь вкручивать лампочку. Это должен уметь электрик Вася. А кот Вася просто промяукает что он этого делать не умеет. И тут уже ваш выбор, научить кота вворачивать лампочки, или просто научить кота не падать от такой просьбы а мяукать — «Вызовите электрика!»

                  Ну а при правильной архитектуре коту вообще никогда такая просьба прилетать не должна, ну а если прилетает — это бага в матрице.
                  • +4
                    Ну С изначально был функциональным а потом к нему прикрутили (и достаточно криво) ООП.


                    1. Вы понимаете, что C и C# — два совершенно разных языка?
                    2. Язык С никогда не был функциональным. Он процедурный. Это две совершенно разных парадигмы
                    3. С с ООП — это третий язык, С++, хотя и не настолько отличающийся от оригинала, как C#

                    А с чего Вы взяли что компьютер (консоль) должен уметь вкручивать лампочку

                    Вкручивать лампочку не должно уметь ни то не другое. Должен уметь электрик. А вы хотите, чтобы лампочка вкручивалась сама.

                    Аналогично числа. Они не должны писаться сами. Их должно писать то, что мы хотим, чтобы их писало. Консоль, или принтер.

                    • –3
                      Нет я хочу что бы лампочки вкручивал электрик Вася. Я его этому учу, и его же об этом прощу, а не посредника по имени Console.

                      Так же и число, зачем мне нужен какой то посредник если я могу научить число само печататься например в поток, который я уже направлю куда нужно. Зачем плодить бесполезные сущности.
                      • +2
                        Так же и число, зачем мне нужен какой то посредник если я могу научить число само печататься например в поток, который я уже направлю куда нужно. Зачем плодить бесполезные сущности.

                        Так же и лампочка, зачем мне нужен какой-то посредник, если я могу научить лампочку саму вкручиваться в патрон, который я уже вставлю куда нужно. Зачем плодить бесполезные сущности?

                        • 0
                          То же вариант)))) Сейчас мода на умные лампочки. Вас же не смущает когда лампочку (саму лампочку а не диммер в стене) с помощью смартфона просят установить определённую яркость или включится в определённое время. Как видите смолтолк опередил время)))
                          • +1

                            Понимаете, вы вырываете примеры из контекста и передёргиваете. Речь шла о том, зачем нам электрик, если лучше пусть лампочка сама вкручивается, а вы перескакиваете на "умные" лампочки, потому что отвечать на вопрос "Зачем нам электрик?" вам неудобно.


                            И ещё раз: вот в JavaScript тоже легко можно заставить цифру печатать саму себя, но этим никто не пользуется, и такой код совершенно справедливо завернёт любой грамотный тимлид.


                            Вот вы сказали, что вам не нужны дополнительные сущности, но для того, чтобы цифра могла печататься куда угодно, вы ввели дополнительную сущность "Поток". Вы далее будете передавать поток консоли или возлагать ответственность за вывод на сам поток? А если потребуется конфигурировать это в рантайме?

                            • –3
                              И ещё раз: вот в JavaScript тоже легко можно заставить цифру печатать саму себя, но этим никто не пользуется, и такой код совершенно справедливо завернёт любой грамотный тимлид.

                              Меня наверное спасает отсутствие у меня тимлида (я за него). Я там внизу уже писал что я не профессиональный программист, и потому могу просто забить на многие правила которые придуманы неизвестно кем и неизвестно почему. Я инженер и в основном пользуюсь инженерным правилом — «задача должна быть выполнена наиболее ОПТИМАЛЬНЫМ способом», и если какие то патерны программирования не соответствуют этому принципу — то эти патерны не используются. Конечно я понимаю что сейчас прилетит много тухлых помидоров, но такой подход позволяет мне достаточно эффективно реализовывать свой проект. Я не считаю правильным тупо следовать каким то правилам описанным в умных книгах, если они мешают мне работать. Эти правила написанны конкретными людьми с конкретными мозгами, и для конкретого контекста. У других людей мозги работают по другому, и контекст другой, почему же все считают что если великий как его там написал что надо делать так, то не смей делать по другому. Своя то голова должна работать. И если тимлид закостенел на учебниках, то гнать его надо. (сейчас пойдут комменты что гать надо меня, но меня гнать некому, я сам себе начальник, а полтора десятков тысяч пользователей моей программы устраивают результаты моей работы ).
                              • 0
                                Раньше всё больше бисер экономили, а теперь вот и до тухлых помидоров добрались… мда…
                              • 0
                                друзья, так увлекательно следить за вашей беседой) Так кто, в итоге вкрутил лампочку?
                                • 0
                                  Сама вкрутилась)))) Сошлись на этом. (её долго били, мучали пока научилась)
                                • 0
                                  Сколько нужно программистов на Smalltalk, чтобы вкрутить лампочку?
                              • 0
                                А ответить на вопрос «зачем электрик?»))
                              • +2

                                Браво! "Я не профессиональный водитель. Все, что мне нужно, это добраться из пункта А в пункт Б наиболее оптимальным способом. Я не считаю правильным тупо следовать каким то правилам описанным в умных книгах, если они мешают мне ехать. Своя то голова должна работать".

                                • +1

                                  «Дяденька, я не настоящий сварщик!»

                                • –1
                                  Ну почти правильно всё рассказали. За одним исключением. Если какие то правила мне помогают и полезны они применяются. Если нарушение каких то правил может повредить ОПТИМАЛЬНОМУ решению задачи — то их приходится выполнять. Повторюсь, голова то должна работать.
                                  Задача — добраться от пункта А в пункт B оптимальным способом. Нарушение правил ПДД влечёт за собой задержку на объяснение с инспектором. Значит правила соблюдаем. Я не профессиональный водитель, значит можно забить на правило дальнобойщиков поссать на колесо. Тем более завгара (тимлида) которому это правило рассказали великие гуру — дальнобойщики у меня нет. И никто не сможет меня остановить (зарезать мой код) если я поеду без соблюдения этого правила.
                                  • +2

                                    А как вы определяете, является ли ваш способ решения задачи оптимальным, и каковы потенциальные затраты на доработку кода из-за недостатков архитектуры? А то ведь и на одной только первой передаче можно всё время ездить. А зачем её переключать? Надо мучиться со сцеплением и рычагом КПП, а машина и так едет. Пускай «профессиональные» водители этим занимаются. Машину с АКПП тоже смысла покупать нет — она дороже при той же комплектации. Только вот ресурс двигателя и трансмиссии сильно снижается.

                                    • 0
                                      А вот в нахождении способа оптимальной достижения цели и состоит работа разработчика. Необходимо найти баланс между обязательными правилами, рекомендациями и даже возможно костылями и стоимостью результата, а так же временем реализации. Можно годами реализовывать проект вылизывая его в соответствии со всеми патернами, обкладывать его тестами на 100%, убирать всю сильную связанность, создавать кучу прокси объектов, наблюдателей и т.д. Но Ваш проект никогда никто не увидит, и значит это будет бесполезно потраченное время
                                  • +1
                                    Все верно, но вы путаете субъективное и объективное. «поссать на колесо» — это субъективное правило, «не ездить на красный» — объективное, помогает избежать аварий. Способы разбиения на блоки, деление зон ответственности некоторых сущностей в программировании — тоже объективны. Здесь не имеет значения, какой гуру или «гуру» высказал мысль; имеет значение объективный фактор связности. Грубо говоря, сколько вам нужно будет точек в коде изменить для того, чтобы перенаправить вывод не в одно место, а в другое. В третье, в четвертое. А потом — в одно из них по выбору, и так далее.
                                    • +1
                                      Ну давайте рассмотрим фактор сильной связности. У меня в проекте есть такой объект — блок. Внутри блока есть коллекция объектов- входы и коллекция выходов. Эти объекты знают о блоке (том объекте в котором они находятся). Да это грубое нарушение правил. Но такое нарушение очень облегчает мне жизнь, при этом не приносит никаких проблем. Более того — есть объекты «соединение» которое знает о входах- выходах с которыми оно соединенно, и входа выхода знают о соединениях с которыми они соединенны. Это же вообще ужось, любой тимлид с учебником меня просто расстреляет за первым углом))).
                                      Но что предлагается взамен?
                                      Система сообщений. То есть при изменении обекта он должен слать сообщения всем подписанным на них объектам.
                                      Минуточку… а что токое список подписчиков? Это коллекция находящаяся в объекте, где находятся ссылки на все объекты которые подписаны на сообщения. То есть когда я кладу ссылку на родительский объект в переменную объекта — это плохо, а когда великий гуру то же самое реализует и называет это системой сообщений — это гуд.И где тут объективность и субъективность. И почему я должен доверять этим гуру, которые имеют одни правила для себя и другие для остальных?
                                      • +1
                                        Если бы вы немного почитали тот учебник, которого так боитесь, то узнали бы что вы в какомто смысле изобрели паттерн Визитор. Который в свою очередь является вывернутым наизнанку ивент-диспатчером.
                                        И да, ивент диспатчер более удобен и гибок. А базовая реализация, коли нехотите тащить какуюто либу готовую, занимает пару десятков строк кода.
                                      • 0
                                        Эти объекты знают о блоке (том объекте в котором они находятся). Да это грубое нарушение правил.

                                        То есть когда я кладу ссылку на родительский объект в переменную объекта — это плохо, а когда великий гуру то же самое реализует и называет это системой сообщений — это гуд

                                        Это нормально. Вы искажаете «это плохо» в своем сообщении.

                                        И почему я должен доверять этим гуру, которые имеют одни правила для себя и другие для остальных?

                                        Вы судите по тому, как напел Рабинович, это скучно.
                                      • 0
                                        Эти объекты знают о блоке (том объекте в котором они находятся). Да это грубое нарушение правил.

                                        Это зависит от того, что именно они знают и зачем они это знают. Если свойство внутреннего объекта имеет тип внешнего, а потмо там дергается полсотни методов и запрашивается еще столько же публичных свойств, то это плохо. А если это интерфейс какой-нибудь, то почему бы и нет? Во втором вашем примере это будет SubscriberInterface с одним функцией.

                                  • 0

                                    Хм… "Почему нельзя нарушать правила? С инспектором придется олбъясняться!". Т.е. если устранить необхдодимость объяснения с инспектором про ПДД можно забыть?

                  • +1
                    Судя по некорректному использованию термина и контексту, вы парой сообщений выше хотели, видимо, сказать «эх вы, жертвы императивного программирования».
                    • +2

                      «Функциональным» альтернативно одарённые программисты называют процедурное программирование.

                • +1
                  Простите, но это вполне используемая, скажем так, парадигма — что-то вроде .toNumber или .toString для числа. И то же самое — почему объект «число» должен уметь конвертироваться в строку, ведь логичнее было бы иметь черный ящик-функцию для этого?
          • 0

            Алгоритм — набор инструкций, описывающих порядок действий исполнителя для достижения некоторого результата. Исполнитель в данном случае компьютер. Ему эти команды и адресованы.

        • 0
          Возьми 7, передай функции факториала, а то, что получится, передай функции печати…
          • +1
            Как я уже писал:
            Вы ведь понимаете, что из-за неправильного порядка оригинальных слов вам приходится вставлять другие слова (костыли), чтобы сделать этот порядок осмысленным.

            И там всех этих слов (возьми, передай, то что получится) — нету.

            А вот в варианте «print factorial 7» — они и не нужны — так как порядок естественный.
        • +3

          «Раскрыта речи тайна Йоды магистра. Просто на Форте программист старый он», — старая шутка, но как раз в тему, ибо 7 factorial print — как раз валидный код для Форта.

    • –2
      Что-то автор слегка тролльнул, выглядит очень похоже на естественный язык, в котором пишут справа налево. Или может имеется в виду, что иврит — самый естесвенный язык, а остальные — так себе.


      Как раз абсолютно нормальный язык. Переведём: (7 factorial printNl ) «Семёрка, отдай ка факториал, и распечатай его»
      • +2
        С каких пор семерки печатают?
        • 0
          С тех пор как в смолтолке (где то с 80-тых годов) было объявлено что Всё — обекты и каждый из них можно научить чему угодно. Например печатать факториал. Так и семёрка является полноправным объектом, и её то же можно этому научить. В смолтолке НЕТ примитивов, и любой объект можно научить (реализовав соответствующий метод) всему чему надо.
          Надеюсь Вас не огорошит такое известие что и nil является объектом, и его так же можно научить например рисоваться цветочком на канве. И потом сказать ему

          nil paintAsFlowerTo:aCanvas
          
          • +3
            Ну мы ведь не про Смолток, а про то, что оно вроде как читается как человеческий язык и про ваше «Вы в воздух заявляете». Вот почему для вас заявлять семерке, чтобы она что-то там распечатала — кажется нормальным с точки зрения человеческого языка?
            • –2
              Ну почему бы и нет если семёрка УМЕЕТ это делать. Причём обратите внимание что распечататься то мы просим не семёрку, а факториал. Семерку Мы просим отдать нам факториал
              7 factorial 
              

              а потом полученный фактрориал просим напечататься (если точнее отдать строку отображающую его)
              7 factorial printNl
              


              Но семерка то же умеет печататься

              7 printString
              


              И это нормально, так же как сказать
              "Петя беги".
              

              В С бы это звучало

              бег(Петя);
              


              Как то не нормально, правда
              • +4
                Да при чем тут Петя? Вы говорите "Цифры, пишитесь!". Это очень глупо, что цифры умеют сами писаться. Как я уже спросил, а вы проигнорировали — куда именно писаться? В консоль, в диалоговое окно, или на принтер? И это все ответственность цифр, знать куда писаться?

                Бег — некорректный пример. Потому что Петя может сам побежать, а цифры сами написаться не могут. Именно потому на smalltalk «petya run» читалось бы естественно, а «number print» читается глупо.
                • –2
                  Вы говорите «Цифры, пишитесь!». Это очень глупо, что цифры умеют сами писаться.
                  Глупо или нет — это дозволенное в языке обращение к цифрам, как к объектам
                  • +2
                    Вы как-то ворвались в середину ветки даже не постаравшись понять суть разговора.
                • –4
                  Могу ещё раз повториться, жертвы функционального программирования которым всю жизнь твердили — есть крутые сущности — классы и есть бесправные примитивы, которым ничего не позволено.
                  Чем семёрка хуже Пети. Она не имеет права научится печататься? Если её научить — она и побежит. Это всё вопросы абстракции и необходимости. В смолтолке очень умные цифры (да и вообще все), их можно чему угодно научить. Да и вообще там демократия и все равны (ну чем не мечта)))). Там нет неравноправия и разделения на главных (классы) и второстепенных (примитивы).
                  • +6

                    Какое отношение имеет функциональное программирование к классам, объектам и примитивам? Функциональное программирование начинается там, где функции становятся сущностями первого рода.

                    • +2
                      Бардак в голове у человека. Я уже акцентировал на этой ошибке, но он не читатель, а писатель
                  • +2
                    Ну замените семёрку на строку. Легче стало? Строку я могу напечатать в консоль, послать в принтер, завернуть в POST-запрос и отправить куда-нибудь через интернет, засунуть в синтезатор голоса и озвучить через динамик, использовать в качестве параметра при вызове какой-нибудь программы (в общем случае написанной неизвестно на каком языке и требующей ещё неизвестно каких ключей). И что, бедной строке во всём этом разбираться? Или мне имплементировать отдельно «Строку, умеющую звучать», «Строку, умеющую печататься», «Строку, умеющую превращаться в последовательность битов ASCII», «Строку, нарисованную тонкой кистью» и «Строку, принадлежащую Императору»?
                • +1
                  Сообщение «printString» означает «напечатай строку» и просто возвращает объект строки, описывающий получателя сообщения. Вывод куда-либо (консоль) не предполагается.

                  Но printNl, в принципе, выглядит не понятно. В смолтолках такого сообщения и нет.
                  • 0
                    Судя по синтаксису в примере был использован GNU Smalltalk, а в нём не образ, а обычный консольный интерпретатор. В классических версиях Smalltalk вывод куда-либо осуществляется с помощью объектов специального назначения. Например, вывод в 'консоль', называемую Transcript, при помощи:

                    Transcript show: (7 factorial asString), cr.  
                    
                    • 0
                      Ну или если установлен пакет OUT то вывод в Transcript вообще простой.
                      7 factorial out
                      
          • +1

            В Ruby и JavaScript тоже можно научить цифры печататься. Но это вообще-то криво и нарушает принцип единственной ответственности, хотя в Rails и используются всякие 7.days_ago. Многие даже паттерн ActiveRecord критикуют за то, что бизнес-сущности не должны уметь сами сохраняться и находиться из базы. В общем, если Smalltalk умеет так делать, это не означает, что так делать хорошо.

            • +2
              Как по мне, то смысл не в том, что можно научить. Смысл в том, что все объект, а вместо методов сообщения. В жизни вы же можете кошке сказать: «иди помой посуду». Но вот понимание и выполнение — это уже отвественность кошки.
              Если вы хотите, чтобы кошка мыла посуду, то научите (добавьте метод) понимать такое сообщение. Но с чего бы ктото должен был мешать вам говорить с кошкой (ошибка при вызове несуществующего метода)?
              А вот уже кого вы чему научите зависит только от вас, как от программиста.
              • –1

                Беда как раз в том, что если язык может приказать посуде помыть себя саму, то некоторые считают, что так и следует делать. В результате получаются объекты, нарушающие принцип единственной ответственности. Разумеется, изначально так писать проще, поскольку не нужно задумываться над архитектурой приложения и композицией объектов. Подобное возникает при создании десктопных программ в Delphi и .NET WinForms: классы форм содержат и бизнес-логику, и взаимодействие со средствами ввода-вывода, и хранят промежуточные слои этого взаимодействия, а ещё и дочерние формы. Так постепенно форма превращается в God object. Да, маленькую программу так писать быстрее, но вот в большой программе все компоненты становятся очень сильно связанными, и доработка становится очень дорогой.


                Вот накопленный за десятилетия практической разработки опыт и выливается в лучшие практики программирования, такие как DRY, SOLID, KISS, YAGNI и т.п.

                • +1
                  то некоторые считают, что так и следует делать.


                  Ну это проблема «некоторых», а не языка.
      • 0

        Не так.


        • Семерка, верни факториал.
        • Че там вернулось, распечатайся.

        Все почему-то упускают, что здесь два сообщения а не одно, и посылаются они разным объектам. Так что в одно предложение это не надо упаковывать.

        • +1
          Никто ничего не упускает. И никто не критикует СТ. Просто он не похож на естественный язык. Это не плохо. Просто это факт. В естественном языке не надо разбивать на два сообщения, потому что они посылаются разным объектам.

          Ну и, как я уже неоднократно замечал, «распечайтася» не имеет никакого смысла как «лампочка, вкрутись», «суп, сварись», «дичь — убейся», "ведра — сходите за водой".
          • +1

            Ну это старая история. Что правильно: плита->грей(кастрюля) или кастрюля->грейся(плита)?


            По моему скромному мению скорее будет верным первый вариант. То что меняет состояние — аргумент метода (субъект), то что неизменно — объект. Иными словами следует избегать возвратных глаголов.
            В модном иммутабельном подходе аргумент — это то, чье измененное состояние возвращается. Т.е. не мертвая_дичь = дичь->убейся(ружье), а мертвая_дичь = ружье->убей(дичь).
            Бывают правда случаи, когда состояние меняется у обоих объектов. Ну вот например в этом примере ружье->состояние = СостояниеРужья::РАЗРЯЖЕНО и дичь->живаЛи = нет. С моей точки зрения тут напрашивается охотник, который выполнит эти действия в ´охотник->убей(ружье, дичь)´, вызвав ружье->стреляй() и дичь->умри(). Но тут мы уже приходим к другой теме. Как это сделать в иммутабельном стиле я не понимаю.

            • 0
              ИМХО, вы правильно заметили, что нужен охотник. Возможно вам будет интересно почитать о DCI

              А по поводу иммутабельности. Результатом выполнения операции должен быть тупл с новыми объектами. разряженным ружьем и убитой дичью)
              • 0

                Ну вот, теперь мы имеем композитный объект, в которм хранятся состояния нескольких объектов. Отсюда остается маленький шажок до глобального объекта SystemState, в котором хранится состояние всей системы (кажется в Redux это так и есть, хотя я могу ошибаться) и… многомировой интерпретации квантовой механики :-)

              • 0

                Насчет DCI. Пробежал по диагонали. Я честно говоря не знаю, почему эта статья была написана в 2012 году, но в принципе я не вижу в ней ничего революционного. Есть сущности, содержащие данные. Есть репозитори, отвественные за взаимодействие с хранилищем. Есть сервисы, ответственные за их обработку. Окройте любой проект и там вы все это найдете. Все достаточно обыденно :-) Я и не знал, что я говорю прозой использую Data Context Interaction ;-)

                • 0
                  По моему опыту в 90% проектов вся бизнесс-логика сосредоточена в контроллерах))
                  • 0

                    Сочувствую. У вас была тяжелая жизнь ;-)

                    • 0
                      Деревянные контроллеры, прибитые к полу
  • 0
    Спасибо! Мне очень хотелось сохранить каламбур, и на мой взгляд получилось неплохо. :3 Ежели предложите лучший вариант — буду рад.
    • +10
      «Smalltalk сделал «утиную типизацию» расхожим выражением (правда, расхаживает оно исключительно по программистам)».
  • 0
    все супер, но как черт бери на этом заработать? где найти, к примеру, хотя бы джуниорскую вакансию, с перспективой заменить старшего? и главный вопрос: зачем всё это, кроме расширения кругозора, сейчас? тем паче, наследников море, и так или иначе мы все работаем со смол парт оф смолтолк :)
    это супер, и очень полезно, когда тебе 18, но в 30 лучше уделить времени родным, право слово, и учить $ языки как я их называю. их много, выбор есть.
    • +4
      Эх, каждый раз люди задают одни и те же вопросы, словно не читали ни саму статью, ни ссылки в ней.

      Расширение кругозора — более чем достаточная причина, боьшинство наследников реализуют или урезанную версию ООП, или вообще кривую. Конечно, в ральной жизни не всегда получается всё чисто и красиво, но именно поэтому нам и нужны референсные реализации. Своего рода маяки в сером океане. После изучения Objective-C я научился писать намного лучше на C++.

      Рано вы себя хороните — в XXI веке 30 ещё начало жизни, средний возраст у аспирантов в Европе (к слову, средний возраст у студентов — 25). Ну и учиться нужно всю жизнь, за этим мы и живём, чтобы каждый день узнавать новое.

      В науке и инженерии (а любой хороший программист — несоменно инженер) вы учитесь всё время, и всё время создаёте новое знание. Такие языки, как Lisp, Scheme, Ada, C и Smalltalk — нужны всем. В равной мере изучение основы теории чисел будет очень не лишне физику, ибо в конце концов он использует числа в вычислениях. Все специалисты по человеческим языкам учат латынь — ибо поняв его, намного легче изучать современные европейские языки.

      Вообще говоря, начальную позицию найти очень сложно, но они и не нужны. Дело в том, что Smalltak редко бывает первым языком, профессионалу на одном языке легче перейти на другой, в конце концов язык — всего лишь язык, самое главное — алгоритмы, структуры данных и принципы разработки везде схожи, но самое главное, он настолько простой, что изучить его на хорошем уровне очень легко в короткие сроки.

      Работа по нему есть — не очень много, но безработных спецов я ещё не видел. И платят очень хорошо.
      • 0
        Расширение кругозора — более чем достаточная причина
        Это универсальная отмазка, которая не работает для очень занятых людей, для которых время дороже денег.

        Такие языки, как Lisp, Scheme, Ada, C и Smalltalk — нужны всем.
        Очень сильное утверждение. Не всем. Среднестатистическому фронтендеру пригодится знание C? Ох, вряд ли. Разумнее потратить это время на изучение очередного фреймворка, чтобы скакнуть в новую компанию с повышением зарплаты, компетенций и новыми задачами, или на написание своего. Нужен ли Lisp инженеру машинного обучения? Нет, не нужен. Гораздо разумнее потратить это время на новые статьи, ведь их выходит столько же сколько фреймворков JS если не больше или на Kaggle. Есть ли польза от Smalltalk для Linux kernel developer-а? Сомневаюсь. Им лучше потратить время на сборку ядра (шутка). Остатется не так много групп — бэкенд и прикладники.

        Работа по нему есть — не очень много, но безработных спецов я ещё не видел. И платят очень хорошо.
        Не убедительно. Работа на Коболе тоже есть. И платят там реально очень хорошо. Какой средний возраст программистов на Smalltalk? Как много новых проектов выходит в единицу времени? Это важно, т.к. если ты выходишь свежий из интитута, заниматься некромантией это одна их худших идей, которые могут прийти в голову.
        • 0
          если ты выходишь свежий из интитута, заниматься некромантией это одна их худших идей, которые могут прийти в голову

          Напротив! В институте как раз и имеет смысл ознакомиться с различными парадигмами программирования (без углублённого изучения, просто ознакомиться). И не только для кругозора, но, и чтобы облегчить изучение новых языков, потому что тому кто знает несколько непохожих языков легче изучить новый язык, чем тому кто знает только один.

          • –1
            В институте — может быть. После института — увольте.
            • +1
              Дану… После универа вот прям настолько занятым человек становится что на саморазвитие времени совсем-совсем нет?
        • +1
          Это универсальная отмазка, которая не работает для очень занятых людей, для которых время дороже денег.

          Если человека ничего кроме его денег не интересует, то никто и не заставляет изучать что-то новое, отвлекающее от зарабатывания.


          Просто бывают люди, для которых деньги — это не единственная цель. Есть желание изучить что-то новое просто потому, что это интересно.

          • +1
            Речь о приоритетах. Можно учить все подряд, потому что интересно. А можно выборочно, так сказать 20% усилий дадут 80% результата.

            Есть желание изучить что-то новое просто потому, что это интересно.
            Речь в статье точно не о новом, а скорее об истории ЯП. Хотите новое — изучайте Ликвид Хаскель, Раст, Елм.
            • 0

              Знать бы заранее, какие именно 20% усилий дадут 80% результата.

        • 0
          Среднестатистическому фронтендеру пригодится знание C?

          Среднестатистическому — нет (хотя WebAssembly набирает обороты). А вот крутому — да. Чтоб он потом не писал очередной транспилер на ноде, заставляя тысячи других фронтэндеров покупать новые макбуки.

    • +1
      Например питерская фирма «Транзас» вроде ищет смолторкера
  • 0
    Не туда написал.
  • +15
    Как изучение Smalltalk может улучшить ваши навыки программиста

    Да никак! Вот так начнешь тыкать в разные обскурные языки, а потом начинаешь что-нибудь писать, и думаешь: "во, это же один-в-один линейный тип, а тут мне лень думать — запущу запрос с backtrack как в Prolog, пусть сам разбирается; мда, а тут вообще самое оно будет всё это в STM обернуть, а тут красиво подходит shift/reset."


    А потом вспоминаешь, что ты пишешь на Python, и ничего такого у тебя нет, и ты страдаешь, начинаешь пить, тебя выгоняют с работы, и ты сидишь под мостом и думаешь: "Зачем я эту статью на хабре читал? Сейчас бы сидел в офисе, писал бы на Питоне и не тужил."


    Правдивая история.

    • +2

      Пиши на Coq, экстракти в OCaml, бинарям добавляй расширение .py. (Была такая история, только без этапа с Coq, и ссылку никак не могу найти.)

      • 0

        У кока какой-то феерически наркоманский синтаксис.

        • 0

          У подмножества, которое можно рассматривать как ЯП, вроде вполне обычный, ML-подобный.

    • +1
      Вот другая правдивая история.
      Я не профессиональный программист, образования не имею (я промышленный программист, и разработчик систем автоматизированного проектирования). Какое то время (очень давно) баловался дельфями. По ряду причин на моей работе был организован отдел прикладного программирования (производственная контора вообще никак не связанная с програмированием). Меня как единственного хоть немного разбирающегося в программировании отправили туда. В помощь наняли проффесионала пришедшего с проекта на смолтолке. В течении нескольких лет Мы практически вдвоём (помощники то приходили, то уходили) подняли проект САПР Cadel.(программа написана полностью на смолтолке)
      По семейным обстоятельствам мне пришлось уехать из Питера, и что бы не потерять навыки я начал свой проект — FLProg. Я работаю над ним один, и на 100% уверен что мне не удалось добиться даже десятой доли того что я сделал ни на каком другом языке. В рамках проекта мне приходится работать на С и PHP. Поэтому я могу сравнивать. Например разработка через дебаг насколько я знаю невозможна больше ни на одном языке. Ну а возможности рефакторинга просто восхищают.
      Ещё раз повторюсь, я не профессиональный программист, но смолтолк позволил мне написать программу на вполне проффесиональном уровне (по крайней мере по отзывам пользователей)
      • 0
        Например разработка через дебаг насколько я знаю невозможна больше ни на одном языке. Ну а возможности рефакторинга просто восхищают.

        А давайте предметно, с примерами?

        Ещё раз повторюсь, я не профессиональный программист, но смолтолк позволил мне написать программу на вполне проффесиональном уровне (по крайней мере по отзывам пользователей)

        Профессиональный уровень — это не только понравилась ли она пользователю. Это и отказоустойчивость, и легкость развертывания, поддержки, изменения. В том числе — сторонними программистами.
    • 0
      К сожалению, это действительно стандартный этап в жизни программиста, когда он начитается и начнет загоняться пытаясь применить все свои знания там, где это не нужно (вспоминаем себя/знакомых, которые узнали про паттерны и начали сувать куда не надо). Обычно после этого из них выбивают дурь и они переходят в сеньоров.
      • 0

        Паттерны куда не нужно и вот это все — это таки разные вещи.

        • 0
          Почему же, это все весьма стандартная проблема перехода с одного языка на другой, а в данном случае — использование конкретного языка после использования другого конкретного языка. Везде свои «best practices» и везде свои подходы к решению проблем. Где-то принято запариваться на счет выделенной памяти, считать, следить за утечками, где-то это просто не имеет смысла. Очень хорошо знать разные подходы и вовремя их применить, но, к сожалению, вовремя это делают лишь самые опытные разработчики.
      • +1
        Мне ужасно интересно, почему в прочих инженерных науках подобные проблемы распространены намного меньше? Видимо, в программной инженерии явно что-то неправильно. Возможно, одна из причин — слишком ранний старт у руля боевого сервера. Например, тридцатилетний авиационный инженер или физик-теоретик — ещё более чем начинающий, молодой и перспективный (за исключением небольшого числа гениев), а у многих программистов в 30 кризис идентичности и прочие проблемы, вроде сложности поиска работы из-за возраста. Во всяком случае, судя по жалобам на Хабре и других русскоязычных ресурсах.
        • +1
          Во-первых, в программировании можно достичь какой-то цели бОльшим количеством способов, чем в «физическом» инженерном деле. А во-вторых, там где в «железном» мире есть вариативность, встречается все то же самое — споры между новыми методами, «давайте поробуем» и «всегда делали так, будем делать так».
  • +1
    Например разработка через дебаг насколько я знаю невозможна больше ни на одном языке.

    Common lisp тоже позволяет писать в похожем стиле. В нем по крайней мере можно исправлять функции прямо в работающей программе. И интерактивный отладчик тоже хорош.


    Выбор языка очень сильно зависит от обстоятельств. Кому-то в молодости подвернулся smalltalk, кому-то lisp, кому-то ещё какой-то другой язык. Потом с этим языком люди по жизни идут и используют, где это возможно. Причём каждый язык хорош по своему.

  • 0
    «Кипит наш разум возмущённый...» ©
    :)
    Smalltalk представил миру виртуальную машину (VM), которая позволяет программному обеспечению быть независимым от платформы. Это та же технология, которую поддерживает Java (JVM) и .NET, а также Android (Dalvik).


    FORTH

    Smalltalk был пионером JIT компиляции (just-in-time), методики резкого повышения производительности программного обеспечения байт-кодов, такого как Java.


    FORTH

    Ну, и так далее. "Тщательнее надо!" (М. Жванецкий) :)

    • 0
      В оригинале автору уже упрекнули в подобном, но он говорил вовсе не о том, что Smalltalk впервые создал все эти методы, а о том, что именно в нём они впервые нашли широкое промышленное применение.
      • +2
        А дальше мы упрёмся в понятия «широкое» и «промысленное». Одно время Форт применялся на всех компьютерах Apple, на всех серверах Sun и всех POWER-серверах IBM. Это — уже промышленное применение или ещё нет?
        • 0
          Думаю, да, уже.
          Ещё можно вспомнить про его применение в космонавтике и промышленной автоматике — но надо ли?..
    • 0

      Э… Ну, что execute (выполняющий шитый код) можно считать виртуальной машиной — ладно (хотя я бы так не выразился).
      А вот про JIT в forth лично я не слышал, и мне эта идея кажется странной. Понятно, что можно реализовать — но велика ли будет выгода?

      • +1
        Э… Ну, что execute (выполняющий шитый код) можно считать виртуальной машиной — ладно (хотя я бы так не выразился).
        Имеются в виду разные вещи типа FCode. Но это всё — уже 70е, а O-код — это порождение 60х, так что Forth — тоже не «пионер».

        А вот про JIT в forth лично я не слышал, и мне эта идея кажется странной.
        Типичная программа содержит кучу вызовов очень «мелких» функций типа dup и swap. Их очень полезно вставить туда, где они вызываются, но использование байткода делает это весьма сложным…

        Но тут FORTH — тоже явно не пионер, всякие LISP-системы делали это раньше.
      • 0
        Ну, что execute (выполняющий шитый код) можно считать виртуальной машиной — ладно (хотя я бы так не выразился).

        А чем это «можно считать»? :)
        Да, маленькая и компактная, но тем не менее…

        А вот про JIT в forth лично я не слышал, и мне эта идея кажется странной. Понятно, что можно реализовать — но велика ли будет выгода?

        Вы уже упомянули шитый код. Что это, если не JIT?
        Так что реализация изначально является неотъемлемой часть. любой Форт-системы, а вовсе не «можно реализовать».
        • +1
          Нет, шитый код это не JIT. Совсем.

          Где тут компиляция в машинный код во время исполнения? Нет самой основной части JIT — самого компилятора.
          • 0
            Вопрос трактовки терминологии, не более того.

            А «сам компилятор» — неотъемлемая часть любой Форт-системы.
            • 0
              Подождите, так есть JIT, т.е. компиляция на лету, по ходу исполнения, или нет? JIT это весьма конкретный термин, а не «вопрос терминологии».
              • 0
                Подождите, так есть JIT, т.е. компиляция на лету, по ходу исполнения, или нет?

                Есть. :)
                Исходный код компилируется в шитый код (или в машинный код целевой системы, в зависимости от реализации), а затем исполняется уже шитый (или машинный) код.
                По крайней мере, это было так, когда я изучал и применял FORTH. Не думаю, что что-то принципиально изменилось.

                JIT это весьма конкретный термин, а не «вопрос терминологии».

                Ну, не такой уж и конкретный. Смотрим Wiki:
                JIT-компиляция (англ. Just-in-time compilation, компиляция «на лету»), динамическая компиляция (англ. dynamic translation) — технология увеличения производительности программных систем, использующих байт-код, путём компиляции байт-кода в машинный код или в другой формат непосредственно во время работы программы.

                Я здесь вижу описание работы Форт-системы в части обработки исходного кода программы и последующего выполнения. :)
                • +1
                  Сразу скажу — я не спорю, поскольку не знаком с работой Форт-системы, мне интересно выяснить именно эту подробность.
                  Есть. :)
                  Исходный код компилируется в шитый код (или в машинный код целевой системы, в зависимости от реализации), а затем исполняется уже шитый (или машинный) код.

                  Эта компиляция выполняется до начала работы системы, верно? В итоге у нас есть последовательность вызовов подпрограмм. Все может быть в машинном коде, но это неважно.

                  В JITе работа производится иначе — программа транслируется всегда в переносимый промежуточный код, который (результат трансляции) может исполняться виртуалками на разных платформах. А JIT на конкретной целевой платформе транслирует этот уже готовый промежуточный код (байт-код Java, например) в машинный по ходу работы виртуалки, «без отрыва от производства». Например, если видно, что вот этот участок — критичен по времени.

                  Ну, не такой уж и конкретный. Смотрим Wiki:

                  Там указана динамическая трансляция, как синоним. Куда конкретнее.
    • 0
      Так-то любой м. с микрокодом можно считать виртуальной машиной. Да хоть МИР (машина для инженерных расчетов) тоже по сути виртуалка.
  • 0
    А почему бы ТС (я помню что перевод) не посоветовать посвятить себя изучению древне-арамейского, латыни и вычислениям в римской системе счисления?
    Итого
    /сарказм
    но сначала кто бы вспомнил, какой ценник IBM выставила на Visual Age Smalltalk, чтобы потом жаловаться на непопулярность
  • +1
    Пример с факториалом замечательно оттолкнет любого человека, знакомого с программированием, от Smalltalk. Мало того, что кода больше, чем в нормальном языке, так еще и код создает какую-то коллекцию (!). Если автор выбрал настолько убогий пример, чтобы продемонстрировать крутость языка, мне страшно представить, что там творится в обычном коде.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.