идиотизм прикладной информатики

49 views
Skip to first unread message

Dmitry Ponyatov

unread,
Jun 2, 2019, 5:47:33 AM6/2/19
to Russian Smalltalk User Group

Последние 40 лет прикладной информатики похожи на бой с тенью Lispа и Smalltalkа. Каждое следующее поколение любого промышленного языка программировани (особенно нацеленного на интенсивное коммерческое использование в широком диапазоне применений) силится реализовать следующие две-три фичи древней системы, представленной еще в 1979 (!) году Xerox Park, в 1967 (Simula), и в еще более теплые ламповые годы истории Лиспа.


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


Чуваки, Smalltalk имеет неограниченную парралельную масштабируемость на основе модели передачи сообщений уже с конца 70х!

Dmitry Matveev

unread,
Jun 2, 2019, 6:59:12 AM6/2/19
to Russian Smalltalk User Group
Ещё одна вариация на тему "десятого правила Гринспуна".


> Чуваки, Smalltalk имеет неограниченную парралельную масштабируемость на основе модели передачи сообщений уже с конца 70х!

"Если ты такой умный, то почему ты такой бедный?"

Увы, какими бы замечательными не были отдельные качества лиспа, смолтока, хаскеля и прочих, в ход пошёл именно инструментарий доступный и массовый.
Свободный рынок и естественный отбор сделали своё дело.

вс, 2 июн. 2019 г. в 12:47, Dmitry Ponyatov <dpon...@gmail.com>:

Последние 40 лет прикладной информатики похожи на бой с тенью Lispа и Smalltalkа. Каждое следующее поколение любого промышленного языка программировани (особенно нацеленного на интенсивное коммерческое использование в широком диапазоне применений) силится реализовать следующие две-три фичи древней системы, представленной еще в 1979 (!) году Xerox Park, в 1967 (Simula), и в еще более теплые ламповые годы истории Лиспа.


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


Чуваки, Smalltalk имеет неограниченную парралельную масштабируемость на основе модели передачи сообщений уже с конца 70х!

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес sugr+uns...@googlegroups.com.
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/cd555e0a-fa5c-4654-a086-2314e9b6f884%40googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Semyon Novikov

unread,
Jun 2, 2019, 8:25:12 AM6/2/19
to su...@googlegroups.com
Ну, как бы в Java есть java.rmi.*.

Мне не хочется никого расстраивать, но ни у кого нет цели получить "параллельную масштабируемость" per se.

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

А вообще есть эрланг, где все это в коробке. И что-то я не вижу доминирования эрланга на рынке нигде.
Я не говорю, что джава хорошая, тут скорее теорема Эскобара.

Я прекрасно понимаю желание оправдать любимый язык, но можно мне посмотреть хотя бы одну реализацию реально распределенной посылки сообщений между объектами на Smalltalk, которую можно использовать в продакшен-системе?

В общем, вы не туда ругаетесь. Фичи языка сами по себе никому не нужны, в конечном итоге важны только два фактора: цена реализации и цена эксплуатации. Джава не идеальна по обоим пунктам, но в конечном итоге оказывается дешевле, чем тоже самое на Smalltalk.

Nikolay Kleptsov

unread,
Jun 3, 2019, 2:08:11 AM6/3/19
to Russian Smalltalk User Group


Я прекрасно понимаю желание оправдать любимый язык, но можно мне посмотреть хотя бы одну реализацию реально распределенной посылки сообщений между объектами на Smalltalk, которую можно использовать в продакшен-системе?



В 2010-11 годах развивал проект Amers, в котором реализовывал удаленную посылку сообщений, в тот момент применить его никуда не смог, никому не был интересен и честно сказать был довольно сырой, его нужно было отлаживать и отлаживать

Nikolay Kleptsov

unread,
Jun 3, 2019, 2:27:30 AM6/3/19
to Russian Smalltalk User Group
Smalltalk-системы являются по себе очень закрытыми. При универсальности реализации "посылки сообщений" с "внешним миром" разговор тяжеловатый.
В основном передача сообщений идет в рамках одного потока, можно передавать межпотоковые сообщения.
Передача сообщений между образами, насколько мне известно, не реализовано. Возможно что-то сделано в GemStone.


вс, 2 июн. 2019 г. в 15:47, Dmitry Ponyatov <dpon...@gmail.com>:

Последние 40 лет прикладной информатики похожи на бой с тенью Lispа и Smalltalkа. Каждое следующее поколение любого промышленного языка программировани (особенно нацеленного на интенсивное коммерческое использование в широком диапазоне применений) силится реализовать следующие две-три фичи древней системы, представленной еще в 1979 (!) году Xerox Park, в 1967 (Simula), и в еще более теплые ламповые годы истории Лиспа.


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


Чуваки, Smalltalk имеет неограниченную парралельную масштабируемость на основе модели передачи сообщений уже с конца 70х!

--

Vladimir Musulainen

unread,
Jun 3, 2019, 7:36:31 AM6/3/19
to Russian Smalltalk User Group
Opentalk в VW Smalltalk существует уже лет 20, если не больше. Я его использовал в ряде проектов.


On Monday, June 3, 2019 at 9:27:30 AM UTC+3, Kleptsov Nikolay wrote:
Smalltalk-системы являются по себе очень закрытыми. При универсальности реализации "посылки сообщений" с "внешним миром" разговор тяжеловатый.
В основном передача сообщений идет в рамках одного потока, можно передавать межпотоковые сообщения.
Передача сообщений между образами, насколько мне известно, не реализовано. Возможно что-то сделано в GemStone.


вс, 2 июн. 2019 г. в 15:47, Dmitry Ponyatov <dpon...@gmail.com>:

Последние 40 лет прикладной информатики похожи на бой с тенью Lispа и Smalltalkа. Каждое следующее поколение любого промышленного языка программировани (особенно нацеленного на интенсивное коммерческое использование в широком диапазоне применений) силится реализовать следующие две-три фичи древней системы, представленной еще в 1979 (!) году Xerox Park, в 1967 (Simula), и в еще более теплые ламповые годы истории Лиспа.


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


Чуваки, Smalltalk имеет неограниченную парралельную масштабируемость на основе модели передачи сообщений уже с конца 70х!

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес sugr+unsubscribe@googlegroups.com.

vvm13xyz xyz

unread,
Jun 4, 2019, 3:07:59 AM6/4/19
to Russian Smalltalk User Group
А по факту, Threaded FFI в Pharo делать некому.

Dmitry Matveev

unread,
Jun 4, 2019, 5:39:29 AM6/4/19
to Russian Smalltalk User Group
Общался я по этому поводу с Мирандой, говорят вот вот будет (мол ВМ уже есть, но с гилом как в питоне). Глядишь через лет 5 появится

вт, 4 июн. 2019 г., 10:08 vvm13xyz xyz <vvm...@gmail.com>:
А по факту, Threaded FFI в Pharo делать некому.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес sugr+uns...@googlegroups.com.
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/9d2702ff-4733-40be-9d84-604dc66abf42%40googlegroups.com.

Dmitry Ponyatov

unread,
Jun 5, 2019, 4:09:36 AM6/5/19
to Russian Smalltalk User Group
А по факту, Threaded FFI в Pharo делать некому.

дык некогда думать, надо на Жабе долбашить 

vvm13xyz xyz

unread,
Jun 7, 2019, 4:29:51 AM6/7/19
to Russian Smalltalk User Group
Кстати, на https://groups.google.com/forum/#!forum/va-smalltalk в очередной раз всплыла тема многонитевой VM. см. Smalltalk's Greatest Performance Issue

Ответ был тот же самый.
Seth Berman

What you probably mean is, will VA Smalltalk be able to run multiple instances of the interpreter (with Smalltalk process context) using native threads instead of green threads.
Or, will each Smalltalk process be mapped to a native thread.

If so, I would say the answer is no...mostly by design.

Запускайте много им

И Mariano Martinez Peck немного потоптался по Pharo:

Do you recall where did you read that (про многонитевую фаровую VM)? Because I am really curious and I probably missed it.  I honestly don't see any Smalltalk community being able to address that. I will give you a simple example. I started a simple database driver called SqueakDBX in 2008 (which we then moved to Pharo). It was a simple FFI wrapper of a C library. The FFI calls would BLOCK the whole VM while the C function was being executed. Can you imagine that for a database driver? All the other Smalltalk process are on hold (yes, even those that should attend for other web requests!)??. I (and many others) have been wanting "just a async FFI". Eleven years after and it is still not there (at least to my knowledge).

Did I do it? No. Did I put 200k USD for someone to do it? No. So I can't complain and I am not complaining. I am being realistic.

So..how would you realistically expect multicore VM?

Это довольно неприятно.

У Snarky я вычитал выражение "зависимость от выбранного пути". Видимо, где-то что-то раньше было упущено, далеко до начала этого века. Робертсон рассказывал про безумного менеджера его конторы.

vvm13xyz xyz

unread,
Jun 8, 2019, 1:41:56 PM6/8/19
to Russian Smalltalk User Group
Может, я зря страдал по поводу Threaded FFI? (См. ниже). Правда, реально я пока не представляю, что это за ZeroMQ такой и как с ним работать.


Marten Feldtmann
image.png
4:13 PM (6 hours ago)
Lots of people have faced this problem in the past ... and people in the past have found solution/how to get around this problem.

Here are my PERSONAL impressions aroud this problem:

* VASmalltalk is able to all of the work in my soluton, but it may be ot wise to use Smalltalk everywhere in my solution
* asychronous calls are expensive (my experiences up to 8.6) in VASmalltalk. So it is wise to make calls only in cases, that this call is doing good, much work.
* heavy socket communication can take Smalltalk CPU power

MY PERSONAL solution therefore is/was (and I took it over to Gemstone):

* try to put all external communication into an external library with own threading

What does this mean ?
 
All my communication solutions to/from Smalltalk are done with 0MQ. 0MQ has its own working thread pool and so a large amount of CPU time is returns to Smalltalk for logic execution.

Other non-0MQ communications are handled via own server processes (e.g. my WebSocket server tasks are written in Python today).

This could also be done with http/http traffic, problems are still large file upload/downloads.

But this is my PERSONAL solution, not mainstream and not acceptable for one language-only developers

********************************
Marten Feldtmann
image.png
9:48 PM (50 minutes ago)
I was not totally clear here: the communication from/to a VASmalltalk system is done via 0MQ only.

The WebSocket server I mentioned below does not do any heavy logic - its just a relay server (or protocol switcher: accept/maintain WebSocket connections and send the requests via 0MA to VASmalltalk/Gemstone. This is the request/answer 0MQ subsystem of all my VASmalltalk/Gemstone systems.

I use Python here because their WebSocket libraries are pretty stable, but Python is much slower than Smalltalk and I've noticed, that Python at this point can be a bottle-neck. So it may be replaced by a Mono-C# based system, or a Java based system - depending which ecosystem has the better WebSocket libraries.

Logging for example is done also using a 0MQ oriented subsystem - but here the system is completely outside of VASmalltalk/Gemstone. VASmalltalk delivers its application log messages to this subsystem. The log-subsystem is written in Python - easier to change/edit. One process within this subsystem is writing all events to files, one process is accepting messages and offers output channels for other processes to get access to the log messages.

The other 0MQ subsystem is the domain-event system. Domain events (user defined) are send (from Smalltalk) through this channel - other processes can react on these events - this kind of "process notificaton" seems to be much faster than e.g. Gemstone offers for their GEM communication.

Load-balancing ? Same answer here - use another pattern of the networking library 0MQ and you have load balancing among various VASmalltalk/Gemstone processes.

So at the end the running application may have 10-20 processes (in my Gemstone solutions). Most of them doing small jobs and they are reused in other projects and I use all the CPUs I have in my computer ...

And another advantage -- due to 0MQ so many different languages can be used here.

So for me: there is no performance problem with Smalltalk - its a problem how to build solutions with Smalltalk

vvm13xyz xyz

unread,
Jun 9, 2019, 3:25:52 AM6/9/19
to Russian Smalltalk User Group
Теперь актуальным считается nanoMsg:


Adarkman Ad

unread,
Jun 12, 2019, 6:01:24 AM6/12/19
to su...@googlegroups.com
OpenTalk из VisualWorks не подойдёт ?

пн, 3 июн. 2019 г. в 09:08, Nikolay Kleptsov <kleptsov...@gmail.com>:




Я прекрасно понимаю желание оправдать любимый язык, но можно мне посмотреть хотя бы одну реализацию реально распределенной посылки сообщений между объектами на Smalltalk, которую можно использовать в продакшен-системе?



В 2010-11 годах развивал проект Amers, в котором реализовывал удаленную посылку сообщений, в тот момент применить его никуда не смог, никому не был интересен и честно сказать был довольно сырой, его нужно было отлаживать и отлаживать

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес sugr+uns...@googlegroups.com.
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/CAPgTEnkUEL-znJKbQONna2cD7pUrbneYvDUPfKT%2B6f-OKLRHGA%40mail.gmail.com.

Dmitry Ponyatov

unread,
Jun 13, 2019, 3:42:29 AM6/13/19
to Russian Smalltalk User Group
Перевел письмо Алана Кея, ситуация проясняется -- разные подходы

  Разъяснение приниципа ООП \copyright\ Alan Kay\\

\noindent
\verb|Stefan Ram>| Когда и где Вами был использован термин «объектно-ориен\-тированный»?
\medskip
  
В Университете Юта, где-то после ноября 1966, когда под влиянием Sketchpad,
Simula, дизайна ARPAnet, Burroughs B5000 и моего опыта в биологии и математике,
я размышлял об архитектуре для программирования. Вероятно, это было в 1967 году,
когда кто-то спросил меня, что я делаю, и я сказал: «это
объектно-ориентированное программирование».

\clearpage
Первоначальная концепция состояла из следующих частей.

\begin{itemize}

  \item
  Я думал об объектах как о биологических клетках и/или отдельных
   компьютерах в сети, которые \emph{могут общаться только через посылку
   сообщений} (поэтому обмен сообщениями появился в самом начале\ ---
   потребовалось некоторое время, чтобы понять, как сделать обмен сообщениями в
   языке программирования достаточно эффективным, чтобы это было полезным).

   \item
   Я хотел избавиться от данных. Burroughs B5000 почти сделал это благодаря
   своей невероятной аппаратной архитектуре. Я понял, что метафора
   «клетка/компьютер» позволит избавится от непосредственного оперирования
   данными, и что операция присваивания \verb|<-| будет просто еще одним
   символом сообщения (мне потребовалось довольно много времени, чтобы
   додуматься до этого, потому что сначала я действительно думал обо всех этих
   символах как об именах для функций и процедур).
   
   \item 
Моя математическая подготовка заставила меня осознать, что с каждым объектом
может быть связано несколько алгебр, и могут существовать их семейства, и это
будет очень и очень полезно. Термин «\term{полиморфизм}» был введен гораздо
позже (я думаю, это сделал Питер Вегнер), и он не совсем корректен, поскольку он
действительно исходит из номенклатуры функций, но я хотел немного больше, чем
функции. Я придумал термин «универсальность» для обозначения общего поведения в
квази-алгебраической форме.

\item 
Мне не понравилось, как Simula I или Simula 67 делали наследовали (хотя я думал,
что Nygaard и Dahl были просто потрясающими мыслителями и разработчиками).
Поэтому я решил оставить наследование как встроенную функцию, пока не пойму ее
лучше.
 
\end{itemize}

\clearpage
Мои первоначальные эксперименты с этой архитектурой были проведены с
использованием модели, которую я адаптировал из «Обобщения Алгола» Ван
Вейнгаартена и его системы Euler. Обе они были скорее похожи на \lisp, но с
более удобным читаемым синтаксисом. Я тогда не понимал монструозную идею 
\lisp а о реальном метаязыке, но немного сблизился с идеями расширяемых
языков, взятых из различных источников, включая IMP от Irons.

Вторая фаза состояла в том, чтобы наконец понять \lisp, и затем использовать
это понимание, чтобы сделать намного более приятные и компактные, более мощные
структуры с поздним связыванием. Диссертация Дэйва Фишера была выполнена в стиле
«МакКарти», и его идеи о расширяемых структурах управления оказались очень
полезными. Также большиое влияние в это время оказал PLANNER Карла Хьюитта
(который так и не получил того признания, которого заслуживает, учитывая,
насколько хорошо и заметно раньше он мог предвосхитить \prolog).

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

\bigskip

\noindent
\verb|Stefan Ram>| Что для вас значит "объектно-ориентированное
программирование"?

\medskip

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

\medskip

Для меня ООП означает только обмен сообщениями, локальное хранение и защиту, а
также скрытие процесса/состояния и крайне позднее связывание всего.
Это можно сделать в \st\ и в \lisp. Возможно, есть другие системы, в которых
это возможно, но я не знаю о них.

\ldots

Если мы посмотрим на всю историю, то увидим, что прото-ООП началось с
ADT\note{абстрактные типы данных}, и имело небольшую развилку в направлении
того, что я называл «объектами»\ --- Smalltalk и т.д. Но после небольшого
разветвления, CS-эстеблишмент сделал ADT основной концепцией, и хотел
придерживаться парадигмы обработки данных. \ldots Самой первой проблемамой,
которую я решил с помощью своих ранних работ в Юте, было «скрытие данных» с
использованием только методов и объектов. В конце 60-х годов (я думаю) Боб
Бальцер написал довольно изящную статью под названием «Программирование без
данных», а вскоре после этого Джон Рейнольдс написал столь же изящную статью
«Gedanken» (я думаю, в 1970 году он показал, что правильное использование
lamda-выражений позволит абстрагировать данные с помощью процедур).

Люди, которым нравились объекты-без-данных, были значительно меньше по
численности, включая меня, Карла Хьюитта, Дейва Рида и некоторых других. В
значительной степени вся эта группа была из сообщества ARPA и так или иначе была
связана с разработкой ARPAnet/Internet, в котором основной единицей вычислений
был целый компьютер. Но просто для того, чтобы показать, насколько упрямо может
держаться идея, в течение семидесятых и восьмидесятых годов, было много людей,
которые пытались обойтись даленным вызовом процедур (RPC), вместо того,
чтобы думать об объектах и сообщениях. Sic Transit Gloria Mundi.

\clearpage

Reply all
Reply to author
Forward
0 new messages