идиотизм прикладной информатики
Locked
 
|
Последние 40 лет прикладной информатики похожи на бой с тенью Lispа и Smalltalkа. Каждое следующее поколение любого промышленного языка программировани (особенно нацеленного на интенсивное коммерческое использование в широком диапазоне применений) силится реализовать следующие две-три фичи древней системы, представленной еще в 1979 (!) году Xerox Park, в 1967 (Simula), и в еще более теплые ламповые годы истории Лиспа. Как пример, Жаба больше 20 лет ее истории претендует на роль ведущей технологии программирования не только в кровавом энтерпрайзе, но и везде от встраиваемых применений до (особенно) глобальных распределенных вычислений. И за все эти годы, с мегалиардными бюджетами потраченными на разработку и продвижение, этот уродский язык все еще не имеет механики обработки асинхронных сообщений в ядре языка (с сопоставлением с шаблонами и фильтрацией). Я это особенно хочу отметить для языка, нацеливающегося на распределенные вычисления, при том что в этой области передача сообщений и потоковая обработяка являются родной моделью вычислений. Чуваки, Smalltalk имеет неограниченную парралельную масштабируемость на основе модели передачи сообщений уже с конца 70х! -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/cd555e0a-fa5c-4654-a086-2314e9b6f884%40googlegroups.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: идиотизм прикладной информатики
|
Ещё одна вариация на тему "десятого правила Гринспуна".
-- > Чуваки, Smalltalk имеет неограниченную парралельную масштабируемость на основе модели передачи сообщений уже с конца 70х! "Если ты такой умный, то почему ты такой бедный?" Увы, какими бы замечательными не были отдельные качества лиспа, смолтока, хаскеля и прочих, в ход пошёл именно инструментарий доступный и массовый. Свободный рынок и естественный отбор сделали своё дело. вс, 2 июн. 2019 г. в 12:47, Dmitry Ponyatov <[hidden email]>:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/CAOW%3DR8kXA9%2BuFSkcBMNT9udHBqxsm3an_EPi2KUSPr8cxL8s%3Dg%40mail.gmail.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
|
|
In reply to this post by ponyatov
Ну, как бы в Java есть java.rmi.*. Мне не хочется никого расстраивать, но ни у кого нет цели получить "параллельную масштабируемость" per se. Есть задача не слишком сложно решать проблемы. Если для решения проблемы нужна параллельная масштабируемость, ее делают, причем не обязательно в ядре языка. Для джавы этого добра столько, что можно каждому участнику этого мейлинг листа выдать по одному и еще останется, в том числе в коробке с языком. А вообще есть эрланг, где все это в коробке. И что-то я не вижу доминирования эрланга на рынке нигде. Я не говорю, что джава хорошая, тут скорее теорема Эскобара. Я прекрасно понимаю желание оправдать любимый язык, но можно мне посмотреть хотя бы одну реализацию реально распределенной посылки сообщений между объектами на Smalltalk, которую можно использовать в продакшен-системе? В общем, вы не туда ругаетесь. Фичи языка сами по себе никому не нужны, в конечном итоге важны только два фактора: цена реализации и цена эксплуатации. Джава не идеальна по обоим пунктам, но в конечном итоге оказывается дешевле, чем тоже самое на Smalltalk. On Sun, 2 Jun 2019, at 14:47, Dmitry Ponyatov wrote:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/d60431d1-01d5-4dfa-a9a7-f2f98f363a15%40www.fastmail.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: идиотизм прикладной информатики
|
|
В 2010-11 годах развивал проект Amers, в котором реализовывал удаленную посылку сообщений, в тот момент применить его никуда не смог, никому не был интересен и честно сказать был довольно сырой, его нужно было отлаживать и отлаживать -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/CAPgTEnkUEL-znJKbQONna2cD7pUrbneYvDUPfKT%2B6f-OKLRHGA%40mail.gmail.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: идиотизм прикладной информатики
|
|
In reply to this post by ponyatov
Smalltalk-системы являются по себе очень закрытыми. При универсальности реализации "посылки сообщений" с "внешним миром" разговор тяжеловатый. В основном передача сообщений идет в рамках одного потока, можно передавать межпотоковые сообщения. Передача сообщений между образами, насколько мне известно, не реализовано. Возможно что-то сделано в GemStone. вс, 2 июн. 2019 г. в 15:47, Dmitry Ponyatov <[hidden email]>:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/CAPgTEnkkKM3BkY6pO98dejnXwmbc%3DASJ6PmiJMKvR_2kWEOKOg%40mail.gmail.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: идиотизм прикладной информатики
|
|
In reply to this post by ponyatov
А по факту, Threaded FFI в Pharo делать некому. -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/9d2702ff-4733-40be-9d84-604dc66abf42%40googlegroups.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: идиотизм прикладной информатики
|
|
Общался я по этому поводу с Мирандой, говорят вот вот будет (мол ВМ уже есть, но с гилом как в питоне). Глядишь через лет 5 появится вт, 4 июн. 2019 г., 10:08 vvm13xyz xyz <[hidden email]>:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/CAOW%3DR8n7rQ971dZ7x3FaOT9_ajXKCpwnx8wJBEBad10f1rYfug%40mail.gmail.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
|
|
In reply to this post by vvm13xyz xyz
дык некогда думать, надо на Жабе долбашить -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/1901b93f-a8c2-4961-9ed7-0fa4fed1e64a%40googlegroups.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: идиотизм прикладной информатики
|
|
Кстати, на https://groups.google.com/forum/#!forum/va-smalltalk в очередной раз всплыла тема многонитевой VM. см. Smalltalk's Greatest Performance Issue
-- Ответ был тот же самый. Seth BermanWhat 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. Запускайте много им 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 я вычитал выражение "зависимость от выбранного пути". Видимо, где-то что-то раньше было упущено, далеко до начала этого века. Робертсон рассказывал про безумного менеджера его конторы. -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/00997396-8b26-4349-9642-e1386e094dd0%40googlegroups.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: идиотизм прикладной информатики
|
|
Может, я зря страдал по поводу Threaded FFI? (См. ниже). Правда, реально я пока не представляю, что это за ZeroMQ такой и как с ним работать. https://groups.google.com/forum/#!topic/va-smalltalk/kPPLvYNXRjs
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 ********************************
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. -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/c37f4472-c151-49be-992a-07d5f3b2fa23%40googlegroups.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: идиотизм прикладной информатики
|
|
Теперь актуальным считается nanoMsg: https://nanomsg.org/documentation.html https://github.com/mumez/NanoStrand -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/7c82eb85-d417-4adb-9089-7bea364d0d37%40googlegroups.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: идиотизм прикладной информатики
|
|
In reply to this post by Nikolay Kleptsov
OpenTalk из VisualWorks не подойдёт ? пн, 3 июн. 2019 г. в 09:08, Nikolay Kleptsov <[hidden email]>:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/CANKUHKD%3DGexCZJZHWj8vmvM1BqtWXyRedcMYC3HtL9aA2KALgg%40mail.gmail.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
|
|
In reply to this post by ponyatov
Перевел письмо Алана Кея, ситуация проясняется -- разные подходы
-- Разъяснение приниципа ООП \copyright\ Alan Kay\\ \url{http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en} \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 -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/c98b0320-8f20-473b-986a-7c5d18fbf5ce%40googlegroups.com. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
«
Return to русский язык (Russian)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |