LINUX.ORG.RU

14
Всего сообщений: 45

Smalltalk, web, 2020-2021

Приветствую, комрады!

Интересует вопрос, на ниве популярности переползания в web и ориентации на бизнес-логику приложений вроде бы выглядет нормальным реализовывать сервисы (интересует API) на всеми забытом smalltalk.

А что, хорошие вроде бы начальные: image based код (контейнирозоваться должно с пол пинка, получаем замкнутую кодовую базу), в теории очень не плохая производительность, большая часть диалектов/реалзаций имеют оптимизированную VM, синтаксис прост как пять копеек, средства разработки отличные…

Есть ли примеры success story и серьезные web-продукты? Есть ли туториалы из разряда «пишем на pharo + vue todo приложение» и тд? Заранее спасибо.

З.Ы.: на ниве популярности electron выглядит вполне вкусно и какой-нибудь софт на Smalltalk для декстопа. Портирован почти везде, умеет много, код может быть схож с вебприложением (поменяется по идее только слой view).

 , , , ,

silver-bullet-bfg ()

Smalltalk - изучаем вместе

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

Видео 1. Общие сведения

Краткая история, перечисление некоторых реализаций, общая суть некоторых принципов системы Смолток.

………………………………………………………..

Видео 2. Сообщества, книги, проекты.

Показаны русскоязычные сообщества по Smalltalk, в частности, группа в ВК. Сделан обзор архива с книгами, которые я нашёл в Сети и выложил на Гугл-диск. Рассказано о двух крупных проектах, которые использовали Smalltalk (FLProg и OpenCobalt). Расширенный список ссылок находится в описании к видео, непосредственно на Youtube

………………………………………………………..

Видео 3. Виртуальные машины.

В уроке кратко рассмотрены среды программирования Squeak, Pharo, и Dolphin.

………………………………………………………..

В темах, не затронутых в видеороликах, я ещё либо сильно «плаваю», либо пока не знаю их вообще. Поэтому обсуждать могу только уже выложенное на Ютуб.

 , ,

Oleg_Kon ()

Pharo - жив?

Комрады, приветствую. Очень интересует - а smalltalk и pharo вообще еще живы? Какова область их применения сейчас?

 , ,

silver-bullet-bfg ()

Числа, строки, указатели в ООП языках.

ООП языки это языки где все объект без исключений! Но как там представляются числа? С Java все понятно, там int не объект, а в ООП языках? Эмулируется существование всех объектов-чисел? Или у объектов-чисел все же особое поведение? Все не пойму что то.

 , , ,

Deleted ()

Любопытный факт из истории смоллтока

Оказывается, ранний смоллток был концептуально очень похож на модель Акторов, но позже деградировал. Вероятно, смоллток-80 уже не отражал в полной мере идеи Алана Кея, они были существенно искажены в этой реализации:

The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation. Versions of Smalltalk before Smalltalk-80 were still largely based on the (asynchronous, unidirectional) ActorsModel of computation, but with Smalltalk-80, the developers of SmalltalkLanguage switched entirely to the (synchronous, bidirectional) procedural model, while misleadingly retaining the ActorsModel terminology (such as «messages» for what essentially are procedure calls rather than one-way notifications). This has caused endless terminological difficulties especially when considering that the the other major sources of OO thinking--capability architectures and the SIMULA 67 research--were not in the least inspired by ActorsModel thinking.

http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

 , ,

callbackhell ()

А много ли есть языков, где нет фиксированного «синтаксиса»?

Вообще, под синтаксисом часто понимаются разные вещи, понятие довольно расплывчатое. Кстати, есть ли четкое, абсолютно однозначная, каноническая трактовка?

Я бы, наверное, интуитивно определил это так. Не-синтаксис — это только лишь вражения языка. Сюда не входят любые макроопределения, спецформы, statements, операторы и так далее. В таком случае синтаксиса нет в том смысле, что нет такого синтаксиса, который бы нельзя было изменить средствами самого языка. Грамматика при этом, конечно, никуда не денется.

Опять же, тут есть тонкая грань. Если каждому оператору соответствует какое-либо выражение языка, то все еще можно считать, что в языке все есть выражение. В таком случае, это можно считать легкой косметикой. Например, оператору := в Io соответствует выражение setSlot. Спецформе define в Scheme не соответствует никакое выражение. Соответственно, на Io можно писать используя одни только выражения, на scheme — нет.

Таким образом, к языкам без синтаксиса(или как это лучше назвать) можно отнести те, на которых весь код может быть написан без использования препроцессора, на одних только выражениях.

Наверное, tcl сюда входит, picolisp, возможно смоллток(поправьте, если я ошибаюсь). А еще есть?

UPD точней будет, наверное, не «без синтаксиса», а «независим от синтаксиса»

 , , ,

callbackhell ()

объекты и сообщения

Сразу оговорюсь, что скорей всего эта тема не заинтересует поклонников квази-ооп.

Начал пилить язык, и задумался вот о какой вещи.

У нас все есть объект. Сообщение — тоже объект. Тогда зачем, выделять сообщения в отдельную сущность? Ведь мы можем считать, что объект в качестве сообщения получает другой объект, любого типа. При этом, он может в своей реализации (поведении) что-то делать с этим полученным объектом, либо делать что-то связанное с этим объектом, либо вообще что-то другое. С этой точки зрения, отдельный тип «сообщение», в каком бы то ни было виде, кажется лишним. Собственно, в качестве сообщений обычно используются различные вариации строковых данных. Тут присутствует семантика «символ - значение», где символ — это вариант типа «строка», или что-то близкое этому. Как бы имя слота — это некий мост между сообщением и поведением. Что если снять это ограничение?

Следствием такого решения как мне видится, должно стать разрешение использования в качестве ключей/имен слотов объекты произвольного типа. Могут ли возникнуть какие то трудности в подобной реализации?

 ,

aboutcard ()

ООП без множественного наследования.

А не кажется ли вам, господа, что, сабж попахивает противоречием. Например, Вася работает слесарем, а в свободное время играет в футбол. В множественном мы просто наследуем его от футболиста и слесаря, а как без него это выразить? Миксины я не беру в расчет, они в Ъ не катят. А как еще? Никак.

Допустим, я насколько знаю, в Смоллтоке нет сабжа. Я честно говорю, уважаю Алана Кея, он говорит много правильных вещей, его позиция и взгляды мне близки. Но тут ИМХО, он сделал ошибку. Как вы считаете?

 ,

javaQest ()

Юзкейсы для объектов, в языках, где все — объект.

Я имею в виду, что все really — объект, а не как в JS, например, где классы примитивных объектов можно расширять, но функциональностью настоящих объектов примитивные типы не обладают. Например, вот так:

"foo".bar=1
Хрен сделаешь. Также, есть проблемы с наследованием. Короче, не ведут примитивы себя как полноценные объеты.

Слышал, что в смоллтоке все есть объект. Думаю, есть еще несколько языков, где также. Например, в Io тоже все есть объект. Однако, я не могу найти нормальные паттерны проектирования, где это свойство языков используются на полную катушку, не вижу юзкейсов. Где посмотреть? Примеры кода очень приветстуются. Спасибо.

 , , ,

theKingOfJava ()

Язык описания инженерных данных

Последние два года я занимался вопросами внедрения ISO 16949, разработки инструкций для команд, немного автоматизации методик выявления потенциальных дефектов и/или потенциально опасных мест в предельно нагруженных гидравлических системах и механизмах - https://ru.wikipedia.org/wiki/FMEA.

Самое интересное, что в этой сфере действительно есть большой потенциал, много «вкусного» для QA, производственников, да и для процесса проектирования много полезного. Но вот проблема - с софтом проблемы. А со свободным, так и вообще можно забыть.

С более-менее интересного я нашел только один продукт, а именно XFMEA http://xfmea.reliasoft.com/?gclid=CNezzqXg0MQCFcXItAodVlQAyQ. Скажем честно - за 2.5к € Вы получаете немного прокачанный офисный пакет Calc с шаблонами расчетов, которые могут считать и красиво раскрашивать SOD, потешая при этом членов команды DFMEA/PFMEA.

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

Подскажите, на Ваш взгляд, какой ЯП лучше всего подойдет для описания инженерных данных? Наиболее подходящие: UML, Smalltalk, Java?

 , , , ,

int13h ()

Существуют ли иные модели ООП?

На сегодняшний день известно 2 модели ООП. Назовем их условно, «сильная» и «слабая».

Первая — смолтоковская модель, основанная на, воистину, величайших идеях Алана Кея, в первую очередь — позднее связывание и концентрация на сообщениях.

Вторая — основанная на лексических замыканиях.

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

А вопрос такой: есть ли какая-нибудь альтернативная модель, некий третий путь. Тут следует пояснить, наверное, что я не провожу различия между смолтоковской классовой(smalltalk, ruby) и прототипной(js, self, io) моделями, условно считаем, что это то же самое, также я не провожу различия между замыканиями и java-like-классами, в данном случае (т.е. модель scheme в контексте примеров модели вычислений с окружениями из SICP === java-style etc), нутыпонел — я обобщил. Может быть что-то еще, принципиально отличающееся от этих двух, есть такое?

 , ,

oop ()

В чём разница между посылом сообщения и вызовом метода?

По-моему, в одном из срачей где-то рядом это упоминалось, но не нашёл.

 , ,

grimwaken ()

Два подхода к контекстам

В этом посте я собираюсь рассмотреть различия в объектной модели Smalltalk и CLOS и как эти модели связаны с понятием контекста. Поклонники статической типизации могут не читать. С открытием CLOS возникли споры о том, CLOS — это что? ООП или не ООП? Становление новой науки неизбежно приводит к терминологическим спорам. ООП — термин расплывчатый и ИМХО, его следовало бы избегать. Как CLOS, так и Smalltalk реализуют одну важную фичу — ad hoc полиморфизм. Эта фича крайне важна для программирования, т.к. позволяет настраивать уже существующий код без изменения его исходного текста. Модель Smalltalk имеет ограниченный ad hoc полиморфизм, т.к. фактически позволяет производить диспетчеризацию лишь по одному аргументу. Однако, кроме ad hoc полиморфизма есть еще одна вещь, связанная с ООП — инкапсуляция. Итак, кратко опишем две ОО модели:

  • Инкапсуляция и ad-hoc полиморфизм (Smalltalk).
  • Ad-hoc полиморфизм без инкапсуляции (CLOS).

Далее я покажу, что эти два подхода противостоят друг другу. В Smalltalk объект — самодостаточная сущность. Чтобы распечатать объект (получить его внешнюю репрезентацию) необходимо послать объекту соответствующее сообщение. Это означает, что внешняя репрезентация объекта зависит только от него, и в минимальной степени зависит от внешнего контекста вызова. В CLOS внешняя репрезентация объекта целиком и полностью зависит от текущей обобщенной функции print-object. Теоретически у одного экземпляра Lisp системы может быть много различных обобщенных функций print-object.

Обычно естественные языки имеют лишь одно текстовое представление. Это не так для иероглифических языков, и скорее всего мы придём со временем к ситуации, когда один и тот же язык будет иметь множество проекций на текст. К этому же идет и эволюция языков программирования. Так, в Perl 6 функция load принимает на вход грамматику, которая описывает Perl 6 и написана на Perl 6. Далее свойство независимости от внешнего представления мы будем называть синтаксической абстракцией. ЯП, наиболее полно поддерживающий синтаксическую абстракцию — Lisp. Программы на Lisp записываются в виде S-выражений, но скобки тут нужны только для того, чтобы указать ридеру структуру. В Lisp текстовая репрезентация программы называются выражениями, а вычислитель работает не с выражениями, а с формами. Термин форма подчеркивает абстрактную природу вычислителя. Я ранее уже писал о том, как можно усилить синтаксическую абстракцию символов в Lisp.

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

Контекст — крайне важное понятие. Игнорирование контекста и абсолютизация понятий приводит к проблемам. Как определить тип объекта? Широко известен спор между Платоном и Диогеном. «Человек, - сказал Платон, - это двуногое животное без перьев». Тогда Диоген ощипал петуха и со словами: «Вот твой человек». Платону пришлось сделать уточнение: «Двуногое животное без перьев и имеющее ногти». Понятно, что тип объекта зависит от наблюдателя. Языки программирования начали с простой идеи — к каждому объекту прилеплен бейджик с его типом. В Smalltalk человеком является тот, кто на вопрос «ты кто?» отвечает — человек. Какой может быть типизация, которая учитывает контекст? Она носит название предикатная типизация. Еще иногда эту идею называют утиной типизацией. В этом подходе тип объекта зависит от того, кто и какие вопросы задает объекту. Платон может определить человека по отсутствию перьев и наличию ногтей, а Диогену нужен фонарь, чтобы определить, кто есть человек.

Одна из наиболее важных идей в истории программирования — гомоиконность является примером переключения контекста. В Lisp нет специально выделенного типа для AST. Является ли определенное дерево AST или нет, зависит от намерений исполнителя. Благодаря этому стало возможным метапрограммирование без значительного усложнения языка. Язык, который выделяет отдельный тип для AST должен иметь весь набор селекторов и конструкторов для этого типа, тогда как представление AST формами дает возможность пользоваться общими селекторами и конструкторами.

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

 , ,

komputikisto ()

Память это зло

Многие неполноценные создания, проектируя объектно ориентированные интерфейсы, вместо того, чтобы использовать правильный паттерн — делгирование


function Super(){}
Super.prototype.a=1
function Class(){}
Class.prototype=Object.create(Super.prototype)
Class.prototype.constructor=Class
Class.prototype.b=2

instanceOfClass=new Class

alert(instanceOfClass.a) // 1
alert(instanceOfClass.b) // 2

Используют быдло-паттерны, основанные на копировании:


Object.defineProperty(Object.prototype, "extend", {
 value: function(src){
   for(var i in src.prototype) this.prototype[i]=src.prototype[i]
 },
 enumerable: false
})

function Super(){}
Super.prototype.a=1
function Class(){}
Class.extend(Super) // copy
Class.prototype.b=2

instanceOfClass=new Class 

alert(instanceOfClass.a) // 1
alert(instanceOfClass.b) // 2

Super.prototype.a=100
alert(instanceOfClass.a) // 1 still!!!

Как видно, это совсем не одно и то же.

На первый взгляд, второй подход тоже имеет свои преимущества — например, ускоряются лукапы (мы сделаем вид, что память у нас не засирается, ведь ее много:)).

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

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

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

Такой вот парадокс памяти. Этот парадокс сродни деградации в человеческом мышлнии — чем больше мы способны запомнить, тем меньше мы мыслим аналитичски, все сводится к поиску по «кешам»

ЗЫ если будут вопросы, отвечу вечером, дела-с

 , ,

terminator-101 ()

Создание образа с нуля

Как создать с нуля образ с полной иерархией объектов, используя лишь примитивы SqueakVM? Как с ним работать, изменять, сохранять его?

cast yoghurt

 ,

buddhist ()

В смоллтоке нет классов

Как-то раз, услышав про то, что в смолтоке есть классы, я подумал, что автор языка выбрал ошибочное направление. Где то в википедии, я читал, что селф перенял у смолтока идеи объектов, но выкинул классы, и я подумал, что тру — это селф, а смолток ушел с праведного пути. Однако я ошибался. Оказывается в смолтоке не было никаких классов, то, что там называлось классами, по-факту есть прототипы. То есть в смолтоке не было классов. Вообще. Это просто терминологическое недоразумение.

Осознать мне это помог анонимус, который однажды, оставив коммент в моей теме, дал ссылку на документ, в котором я нашел следующий отрывок (цитата из чего-то)

«То, что мы рассмотрели, не отвечает на главный вопрос: как объект, получивший сообщение, находит метод, который надо выполнить? Остановимся подробно на механизмах поиска по сообщению необходимого метода и его выполнения. Итак, как уже отмечалось, выполнение любого действия в системе Смолток осуществляется с помощью посылки объекту сообщения. Получив сообщение, получатель ищет метод с соответствующим сообщению шаблоном, начиная поиск обычно со своего класса. Если объект — класс, то метод ищется среди методов класса, а если объект — экземпляр класса, то среди методов экземпляра класса. Если метод с соответствующим шаблоном находится в классе получателя, то он выполняется, и как результат его выполнения обязательно возвращается некоторый объект, который информирует того, кто послал сообщение, что выполнение метода завершилось с содержащимся в возвращаемом объекте результатом. А если метода с нужным шаблоном нет в классе? Тогда к работе подключается иерархия классов, а точнее, цепочка суперклассов для класса объекта-получателя. Если в классе подходящего метода нет, метод ищется в ближайшем его суперклассе. Если нужного метода нет в суперклассе, то поиск продолжается в следующем по иерархии суперклассе и так далее, пока не доберемся до класса Object.»

Таким образом, в JS реализована точная копия смолтока. Семантически, JS — это и есть смолток, правда с ненужными шлюхами. Странно, почему об этом все молчат в тряпочку.

 , , ,

anonimous ()

Почему не стал мейнстримом Smalltalk?

Добрый день ЛОР.

Скоро праздники. Скоро пятница. Поэтому решил создать тред вот с каким вопросом - почему Smalltalk стал так не популярен? Ведь у языка было (и есть) все, чтобы стать мейнстримом, он мог занять ту нишу, в которую потом засели ObjectPaskal/Delphi/VB/C#! Что ему мешает выбиться «в люди»? Почему на том же Pharo нет ни одной серьезной программы с GUI и ориентированной на пользователя?

 , , , ,

silver-bullet-bfg ()

Squeak by Example

C# с точки зрения ООП и DI/IoC перестал вставлять. Хочется назад к корням - Smalltalk.

Нагуглил современную реализацию - Squeak и книжку Squeak by Example.

А есть ли в природе переводы на русском?

Перемещено mono из talks

 , , , ,

EnterpriseMobility ()

Smalltalk на планшете

2 вопроса

*какой смолток зарядить в андроид планшет с целью современного dynabook?

*какой простейший на смолтоке мета-циркулярный интерпетатор?

Перемещено mono из talks

 , , , ,

qulinxao ()

Smalltalk - отличия современных версий от стандарта

Насколько я понимаю, все основополагающие источники по разработке на Smalltalk описывают в основном Smalltalk-80. А насколько современные версии языка отличаются от этого протухшего «стандарта»? Есть ли такие, что опираются на стандарт ANSI Smalltalk (если он вообще был принят, я что-то не пойму)? И где можно увидеть более-менее вменяемый список расширений? Интересуют на данный момент в принципе только Pharo и Cincom VisualWorks.

 

ovk48 ()