Smalltalk › русский язык (Russian)

Каким я хочу видеть свой Smalltalk

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

HandleX

Каким я хочу видеть свой Smalltalk

1) Гибко настраиваемые области видимости. Я хочу иметь в образе области, в которых невозможно выполнить, например, Processor := nil, просто потому, что в этой области нет доступа к этой замечательной переменной.

2) Я хочу видеть ядро в smalltalk.exe, образ в наборе из *.dll, причём для каждого package — своя dll. Компиляция в работающем образе создаёт соответствуюшие *.diff файлы с изменениями. Которые обновляют существ. *.dll после вызова #saveImage. Ну и т.п.

3) Я хочу иметь в CompiledMethod'е не только поле byteCode, но и после наработки определённой статистики (многократных вызовов метода) поле asmCode, оптимизированное под текущую архитектуру (ну там x86 или x64, есть или нет там SSE3 и проч.). Меняется архитектура -- все такие поля инвалидируются, компиляция в процессорный код начинается заново. Компиляция может, а вернее должна происходить на фоне, современные многопоточные процессоры позволяют. Компилятор на основе чего-нить свободного и стабильно развивающегося, например, LLVM. Ну и вы поняли — проект CLang так и просится (из-за своей близости к LLVM) стать основой для создания нашей супер VM :)

4) Compiler не крысить в недрах VM, пусть всё будет единообразно, на Smalltalk, и доступно для исследований и изменений.

5) VM не крысить в *.exe, постараться сделать такой Smalltalk, который сможет скомпилять и свою же VM.

6) Гуй пилить под кросплатформенные библиотеки, например QT. Более простой вариант — иметь среду разработки в браузере, подключаясь к образу по http. Однако, запиливание хорошей среды разработки даёт гарантию качества имеющихся там гуёвых либ, потому что отцы-создатели знают в этом толк, посмотрите к примеру на прекрасную среду разработки Dolphin Smalltalk и великолепную её интеграцию с вендой. Хотя это и палка о двух концах, ибо не вендой единой... Больше склоняюсь к HTTP, хотя это и может в первое время откатить пользователей такого Smalltalk'а к системным API при разработке GUI интерфейсов ;)

7) Не вздумать никоим образом "интегрироваться" с .net, получим смесь ежа с ужом.

8) Обязательно запилить в Smalltalk-процессы поддержку нативных потоков OS, ну или по крайней мере дать возможность управлять ими изнутри и возможность назначать любому внутреннему объекту Process нужный поток OS. Но лучше не ломать мозг, и сделать сразу один Smalltalk-Process -> один OS Thread.

9) Может быть со временем понять, что на классах с метаклассами свет не сошёлся, и в своё время была Self, которая показывала определённые неплохие результаты. Но это гигантская работа по перепиливанию всего, как среды разработки, так и основных либ, те же Collection's, которые есть уже сейчас, бери-не-хочу. Ну и писать всё в том же лаконичном и красивом стиле — это надо влезть в шкуру Алана Кея, не каждому дано ;) Я к тому, что вот пытаешься использовать те же дотнетовские либы -- тошнит, а от старого доброго лампового смоллтока приятное тепло разливается... потому что классика, которая почти не стареет :)

Такие дела. Все хотят такой Smalltalk? Как бы объединить людей... Железной рукою... загнать человечество к счастью -)) А по сути, нужно собирать такое сообщество, с которым не жалко будет делиться баблом с будущей прибыли, которую мог бы собрать такой проект. Например: написал либу, вошла она в основную ветку -- имеешь соотв. дивиденды. И т.д., эх, мечты-мечты...

--
http://groups.google.ru/group/sugr

Nikolay Kleptsov

Re: Каким я хочу видеть свой Smalltalk

1) Гибко настраиваемые области видимости. Я хочу иметь в образе области, в которых невозможно выполнить, например, Processor := nil, просто потому, что в этой области нет доступа к этой замечательной переменной.

В теме "Безопасность в Smalltalk" подробно рассматривали. Потребуется довольно серьезная переработка как ВМ, так и образа. Приведет к несовместимости прежних приложений. Фактически систему придется с нуля разрабатывать.

2) Я хочу видеть ядро в smalltalk.exe, образ в наборе из *.dll, причём для каждого package — своя dll. Компиляция в работающем образе создаёт соответствуюшие *.diff файлы с изменениями. Которые обновляют существ. *.dll после вызова #saveImage. Ну и т.п.

Что-то подобное есть в Smalltalk/X. В методы можно вставлять C/C++ участки кода. Таким образом написаны все примитивы. Скорость на уровне VisualWorks.

3) Я хочу иметь в CompiledMethod'е не только поле byteCode, но и после наработки определённой статистики (многократных вызовов метода) поле asmCode, оптимизированное под текущую архитектуру (ну там x86 или x64, есть или нет там SSE3 и проч.). Меняется архитектура -- все такие поля инвалидируются, компиляция в процессорный код начинается заново. Компиляция может, а вернее должна происходить на фоне, современные многопоточные процессоры позволяют. Компилятор на основе чего-нить свободного и стабильно развивающегося, например, LLVM. Ну и вы поняли — проект CLang так и просится (из-за своей близости к LLVM) стать основой для создания нашей супер VM :)

Проблематично переносить образ с одной архитектуры на другую. Потребуется дополнительная перекомпиляция и усложнение системы. Все-таки жесткое деление на образ и ВМ (независимая и зависимая часть от платформы) проверено временем.

4) Compiler не крысить в недрах VM, пусть всё будет единообразно, на Smalltalk, и доступно для исследований и изменений.

Всему виной быстродействие.

9) Может быть со временем понять, что на классах с метаклассами свет не сошёлся, и в своё время была Self, которая показывала определённые неплохие результаты. Но это гигантская работа по перепиливанию всего, как среды разработки, так и основных либ, те же Collection's, которые есть уже сейчас, бери-не-хочу. Ну и писать всё в том же лаконичном и красивом стиле — это надо влезть в шкуру Алана Кея, не каждому дано ;) Я к тому, что вот пытаешься использовать те же дотнетовские либы -- тошнит, а от старого доброго лампового смоллтока приятное тепло разливается... потому что классика, которая почти не стареет :)

Self и сейчас существует. http://selflanguage.org/
В середине 90-х система брала 60 и более мегабайт памяти, тогда это было много. Почему его сейчас почти не развивают?

Конечно, можно пойти двумя путями: первый - постепенное совершенствование существующей системы, второй - написание с нуля.
По моему в Smalltalk (свободные версии) достаточно добавить сверхбольшие коллекции и взаимодействие объектов только через сообщения.

--
http://groups.google.ru/group/sugr

Dennis Schetinin

Re: Каким я хочу видеть свой Smalltalk

In reply to this post by HandleX

Все хотят такой Smalltalk?

Нет, конечно!

Например, с моими желаниями данный список совпадает лишь частично. Причем некоторые несовпадения на первый взгляд выглядят принципиальными. Думаю, почти каждый смоллтокер сможет сказать примерно тоже самое: наверняка всех чем-то не устраивает Smalltalk в том виде, в каком он есть сейчас, но у каждого свои претензии и их приоритетность. Кто-то хотел бы "теоретическую" часть подтянуть, а кого-то практические аспекты больше занимают; кто-то согласится, что чистота и простота важнее, а кто-то будет настаивать, что сначала надо сделать так, чтобы было быстро… Вообще сложно найти хотя бы один аспект, с которым бы все однозначно бы согласились :)

Как бы объединить людей... Железной рукою... загнать человечество к счастью -)) А по сути, нужно собирать такое сообщество, с которым не жалко будет делиться баблом с будущей прибыли, которую мог бы собрать такой проект. Например: написал либу, вошла она в основную ветку -- имеешь соотв. дивиденды. И т.д., эх, мечты-мечты...

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

Best regards,

Dennis Schetinin

Sent with Sparrow

On Sunday, 5 August 2012 г. at 20:13, HandleX wrote:

1) Гибко настраиваемые области видимости. Я хочу иметь в образе области, в которых невозможно выполнить, например, Processor := nil, просто потому, что в этой области нет доступа к этой замечательной переменной.
2) Я хочу видеть ядро в smalltalk.exe, образ в наборе из *.dll, причём для каждого package — своя dll. Компиляция в работающем образе создаёт соответствуюшие *.diff файлы с изменениями. Которые обновляют существ. *.dll после вызова #saveImage. Ну и т.п.
3) Я хочу иметь в CompiledMethod'е не только поле byteCode, но и после наработки определённой статистики (многократных вызовов метода) поле asmCode, оптимизированное под текущую архитектуру (ну там x86 или x64, есть или нет там SSE3 и проч.). Меняется архитектура -- все такие поля инвалидируются, компиляция в процессорный код начинается заново. Компиляция может, а вернее должна происходить на фоне, современные многопоточные процессоры позволяют. Компилятор на основе чего-нить свободного и стабильно развивающегося, например, LLVM. Ну и вы поняли — проект CLang так и просится (из-за своей близости к LLVM) стать основой для создания нашей супер VM :)
4) Compiler не крысить в недрах VM, пусть всё будет единообразно, на Smalltalk, и доступно для исследований и изменений.
5) VM не крысить в *.exe, постараться сделать такой Smalltalk, который сможет скомпилять и свою же VM.
6) Гуй пилить под кросплатформенные библиотеки, например QT. Более простой вариант — иметь среду разработки в браузере, подключаясь к образу по http. Однако, запиливание хорошей среды разработки даёт гарантию качества имеющихся там гуёвых либ, потому что отцы-создатели знают в этом толк, посмотрите к примеру на прекрасную среду разработки Dolphin Smalltalk и великолепную её интеграцию с вендой. Хотя это и палка о двух концах, ибо не вендой единой... Больше склоняюсь к HTTP, хотя это и может в первое время откатить пользователей такого Smalltalk'а к системным API при разработке GUI интерфейсов ;)
7) Не вздумать никоим образом "интегрироваться" с .net, получим смесь ежа с ужом.
8) Обязательно запилить в Smalltalk-процессы поддержку нативных потоков OS, ну или по крайней мере дать возможность управлять ими изнутри и возможность назначать любому внутреннему объекту Process нужный поток OS. Но лучше не ломать мозг, и сделать сразу один Smalltalk-Process -> один OS Thread.
9) Может быть со временем понять, что на классах с метаклассами свет не сошёлся, и в своё время была Self, которая показывала определённые неплохие результаты. Но это гигантская работа по перепиливанию всего, как среды разработки, так и основных либ, те же Collection's, которые есть уже сейчас, бери-не-хочу. Ну и писать всё в том же лаконичном и красивом стиле — это надо влезть в шкуру Алана Кея, не каждому дано ;) Я к тому, что вот пытаешься использовать те же дотнетовские либы -- тошнит, а от старого доброго лампового смоллтока приятное тепло разливается... потому что классика, которая почти не стареет :)

Такие дела. Все хотят такой Smalltalk? Как бы объединить людей... Железной рукою... загнать человечество к счастью -)) А по сути, нужно собирать такое сообщество, с которым не жалко будет делиться баблом с будущей прибыли, которую мог бы собрать такой проект. Например: написал либу, вошла она в основную ветку -- имеешь соотв. дивиденды. И т.д., эх, мечты-мечты...

--
http://groups.google.ru/group/sugr

--
http://groups.google.ru/group/sugr