Maybe Erlang is OO after all?
Andrei N. Sobchuck
--
Андрей Собчук
and...@itware.com.ua
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Serguey Zefirov
Monday, August 25, 2003, 3:23:43 AM, you wrote:
ANS> http://www.erlang.org/ml-archive/erlang-questions/200308/msg00185.html
Uladzimir Liashkevich (sorry for my humble out-of-memory spelling) как-то раз
осторожно высказал именно эту идею, когда был поставлен лицом перед фактом,
что в Erlang:
а) Есть независимые процессы и
б) процессы обмениваются сообщениями и
в) Erlang не статически типизирован.
По его мнению, все, что обменивается сообщениями - ОО. ;)
А по-моему, это притянуто за уши. И то, и твоя ссылка.
В свою очередь (as seen on Lambda the Ultimate):
http://web.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/patterns.pdf
Generic programming consists of increasing the expressiveness of programs by
allowing a wider variety of kinds of parameter than is usual. The most popular
instance of this scheme is the C++ Standard Template Library. Datatype-generic
programming is another instance, in which the parameters take the form of
datatypes. We argue that datatype-generic programming is sufficient to express
essentially all the genericity found in the Standard Template Library, and to
capture the abstractions motivating many design patterns. Moreover,
datatype-generic programming is a precisely-defined notion with a rigorous
mathematical foundation, in contrast to generic programming in general and the
C++ template mechanism in particular, and thereby offers the prospect of
better static checking and a greater ability to reason about generic programs.
--
Best regards,
Serguey mailto:s...@uc.ru
Victor Metelitsa
Serguey Zefirov wrote:
> Hello Andrei,
>
> Monday, August 25, 2003, 3:23:43 AM, you wrote:
>
> ANS> http://www.erlang.org/ml-archive/erlang-questions/200308/msg00185.html
>
> Uladzimir Liashkevich (sorry for my humble out-of-memory spelling) как-то раз
> осторожно высказал именно эту идею, когда был поставлен лицом перед фактом,
> что в Erlang:
> а) Есть независимые процессы и
> б) процессы обмениваются сообщениями и
> в) Erlang не статически типизирован.
>
> По его мнению, все, что обменивается сообщениями - ОО. ;)
>
1. Все - объекты, и ничего кроме;
2. Объекты скрывают в себе данные (имеется в виду инкапсуляция);
3. Объекты взаимодействуют между собой путем посылки сообщений.
Так определял ОО тот, кто придумал этот термин. В частности,
наследование не упоминается.
--
Serguey Zefirov
Monday, August 25, 2003, 3:52:35 AM, you wrote:
>> Uladzimir Liashkevich (sorry for my humble out-of-memory spelling) как-то раз
>> осторожно высказал именно эту идею, когда был поставлен лицом перед фактом,
>> что в Erlang:
>> а) Есть независимые процессы и
>> б) процессы обмениваются сообщениями и
>> в) Erlang не статически типизирован.
>>
>> По его мнению, все, что обменивается сообщениями - ОО. ;)
>>
VM> Насколько я помню, для ОО требуется три признака, примерно такие:
VM> 1. Все - объекты, и ничего кроме;
VM> 2. Объекты скрывают в себе данные (имеется в виду инкапсуляция);
Чем успешнее они их в себе скрывают, тем меньше мы о них знаем. Так, что (в
пределе) есть у объектов данные, что нет у объектов данных (прокси) - разницы
нет.
VM> 3. Объекты взаимодействуют между собой путем посылки сообщений.
VM> Так определял ОО тот, кто придумал этот термин. В частности,
VM> наследование не упоминается.
Теперь сравним:
а) все - процессы;
б) процессы взаимодействуют между собой путем посылки сообщений.
Вот потому я и говорю, что ОО - это, большей частью, просто оборот речи, или,
так сказать, "Оборот Общения". И ничего более.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Alexander Kobets
"Serguey Zefirov" <s...@uc.ru> сообщил/сообщила в новостях следующее:
...
> Теперь сравним:
> а) все - процессы;
> б) процессы взаимодействуют между собой путем посылки сообщений.
>
> Вот потому я и говорю, что ОО - это, большей частью, просто оборот речи,
или,
> так сказать, "Оборот Общения". И ничего более.
Так это же хорошо. Всё гениальное - просто.
Пока.
--
Serguey Zefirov
Monday, August 25, 2003, 5:05:32 AM, you wrote:
>> Теперь сравним:
>> а) все - процессы;
>> б) процессы взаимодействуют между собой путем посылки сообщений.
>>
>> Вот потому я и говорю, что ОО - это, большей частью, просто оборот речи,
AK> или,
>> так сказать, "Оборот Общения". И ничего более.
AK> Так это же хорошо. Всё гениальное - просто.
Иная простота хуже воровства.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N. Sobchuck
ANS>> http://www.erlang.org/ml-archive/erlang-questions/200308/msg00185.html
SZ> Uladzimir Liashkevich (sorry for my humble out-of-memory spelling) как-то раз
SZ> По его мнению, все, что обменивается сообщениями - ОО. ;)
Факт ;) В смысле создатель термина так говорит, значит оно и есть
--
Андрей Собчук
and...@itware.com.ua
Serguey Zefirov
Monday, August 25, 2003, 8:23:40 AM, you wrote:
ANS> Serguey Zefirov <s...@uc.ru> wrote:
ANS>>> http://www.erlang.org/ml-archive/erlang-questions/200308/msg00185.html
ANS> SZ> Uladzimir Liashkevich (sorry for my humble out-of-memory spelling)
ANS> как-то раз
ANS> SZ> По его мнению, все, что обменивается сообщениями - ОО. ;)
ANS> Факт ;) В смысле создатель термина так говорит, значит оно и есть
Да хоть бы и так. Что это дает?
Вот причислили мы Erlang к обществу OO. Стали ли Erlang лучше или хуже от
этого? Если да, то укажите направление и объясните почему. А еще лучше -
попробуйте убедить Ericsson перейти на Smalltalk потому, что оба языка -
Erlang и Smalltalk, - обладают одинаковой семантикой, исходя из их
классификации. О результате обязательно доложите в эху.
--
Best regards,
Serguey mailto:s...@uc.ru
PS
Меняем (контекстно) object на process, получаем process-oriented. Меняем
(контекстно) process на disjoint cartesian sum with named items, получаем
disjoint-cartesian-sum-with-named-items-oriented язык - Haskell без типов
классов. Или наоборот - Haskell без type classes считаем
объектно-ориентированным языком. Вот, от всего этого нам всем стало прельстиво
и любо.
Давай еще кого-либо назовем как-либо. Например, назовем тебя горшком.
Vadim Radionov
25 авг 03 14:52, Victor Metelitsa wrote to Serguey Zefirov:
>> Uladzimir Liashkevich (sorry for my humble out-of-memory spelling)
>> как-то раз осторожно высказал именно эту идею, когда был поставлен
>> лицом перед фактом, что в Erlang: а) Есть независимые процессы и б)
>> процессы обмениваются сообщениями и в) Erlang не статически
>> типизирован.
>>
>> По его мнению, все, что обменивается сообщениями - ОО. ;)
>>
VM> Hасколько я помню, для ОО требуется три признака, примерно такие:
VM> 1. Все - объекты, и ничего кроме;
Перефразируя можно сказать что нет ничего за пределами объектов (между
объектами). Что очень подходит для процессов в Erlang'е. Я имею ввиду
переменные, которые доступны сразу нескольким процессам - там такого нет.
Процессы в Erlang'е изолированны основательно.
VM> 2. Объекты скрывают в себе данные (имеется в виду инкапсуляция)
Так и есть (по отношению к процессам в erlang'е).
Я когда практиковался на erlang'е у меня возникало ощущение что лучшей практики
для ООП я еще не встречал. :)
VM> 3. Объекты взаимодействуют между собой путем посылки сообщений.
VM> Так определял ОО тот, кто придумал этот термин. В частности,
VM> наследование не упоминается.
Vadim
Andrei N. Sobchuck
ANS>> Факт ;) В смысле создатель термина так говорит, значит оно и есть
Я видел фразу на сайте ирланга, что основное его преимущество, это то,
что он ориентированный на сообщения.
Там же, расписывалися преимущества обмена сообщениями.
Сейчас этого я найти не могу, потому буду думать, что это было призрак...
А вообще, ссылка есть:
http://www.erlang.org/ml-archive/erlang-questions/200302/msg00733.html
Вопрос, в чем это не ОО, остался без ответа.
--
Андрей Собчук
and...@itware.com.ua
Serguey Zefirov
Monday, August 25, 2003, 9:27:20 AM, you wrote:
ANS>>> Факт ;) В смысле создатель термина так говорит, значит оно и есть
ANS> SZ> Да хоть бы и так. Что это дает?
ANS> Я видел фразу на сайте ирланга, что основное его преимущество, это то,
ANS> что он ориентированный на сообщения.
ANS> Там же, расписывалися преимущества обмена сообщениями.
ANS> Сейчас этого я найти не могу, потому буду думать, что это было призрак...
Куда я ни посмотрю - везде полиморфные функции, декартовы суммы с
поименоваными слагаемыми... Даже к тиклю припендюрил.
Тоже отрыв от реальности.
ANS> А вообще, ссылка есть:
ANS> http://www.erlang.org/ml-archive/erlang-questions/200302/msg00733.html
ANS> Вопрос, в чем это не ОО, остался без ответа.
А я там такого вопроса и не нашел.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N. Sobchuck
ANS>> http://www.erlang.org/ml-archive/erlang-questions/200302/msg00733.html
ANS>> Вопрос, в чем это не ОО, остался без ответа.
Ну, и аюшки...
--
Андрей Собчук
and...@itware.com.ua
Uladzimir Liashkevich
SZ> Hello Andrei,
SZ> Monday, August 25, 2003, 3:23:43 AM, you wrote:
SZ> ANS>
http://www.erlang.org/ml-archive/erlang-questions/200308/msg00185.html
SZ> Uladzimir Liashkevich (sorry for my humble
out-of-memory spelling) как-то раз
SZ> осторожно высказал именно эту идею, когда был
поставлен лицом перед фактом,
SZ> что в Erlang:
SZ> а) Есть независимые процессы и
SZ> б) процессы обмениваются сообщениями и
SZ> в) Erlang не статически типизирован.
SZ> По его мнению, все, что обменивается
сообщениями - ОО. ;)
SZ> А по-моему, это притянуто за уши. И то, и твоя
ссылка.
Притягивать тут особо нечего. Определение довольно
общее, под него может подпасть множество вещей. Я
бы сказал, что Erlang действительно ОО-шный.
Но девиция имеется. В частности важной
особенностью ОО системы должен являться
рекурсивный дизайн, дающий самым малым частям
такие же возможности, как и у всей системы в
целом. ОО-шность Erlang-а видимо заканчивается на
каком-то определенном макро-уровне. То, что лежит
ниже, реализовано уже с использованием другой
парадигмы. В целом получается многослойный дизайн.
Язык многих парадигм, прямо как в C++ (но ОО туда
не входит ;-)).
SZ> В свою очередь (as seen on Lambda the Ultimate):
SZ>
http://web.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/patterns.pdf
SZ> Generic programming consists of increasing the
expressiveness of programs by
SZ> allowing a wider variety of kinds of parameter
than is usual. The most popular
SZ> instance of this scheme is the C++ Standard
Template Library. Datatype-generic
SZ> programming is another instance, in which the
parameters take the form of
SZ> datatypes. We argue that datatype-generic
programming is sufficient to express
SZ> essentially all the genericity found in the
Standard Template Library, and to
SZ> capture the abstractions motivating many
design patterns. Moreover,
SZ> datatype-generic programming is a
precisely-defined notion with a rigorous
SZ> mathematical foundation, in contrast to
generic programming in general and the
SZ> C++ template mechanism in particular, and
thereby offers the prospect of
SZ> better static checking and a greater ability
to reason about generic programs.
У генерического C++ совсем плохо с компонентным
подходом. Имеется ли такой язык, который позволяет
и изолированные компоненты создавать и полностью
сохранить статическую валидацию generic-функций?
Мне больше нравится подход CLOS - динамический,
ОО-шный, но не object- а function-centered. Еще
один маневр в рамках ОО.
--
Владимир.
Serguey Zefirov
Monday, August 25, 2003, 11:16:39 AM, you wrote:
UL> Притягивать тут особо нечего. Определение довольно
UL> общее, под него может подпасть множество вещей. Я
UL> бы сказал, что Erlang действительно ОО-шный.
UL> Но девиция имеется. В частности важной
UL> особенностью ОО системы должен являться
UL> рекурсивный дизайн, дающий самым малым частям
UL> такие же возможности, как и у всей системы в
UL> целом. ОО-шность Erlang-а видимо заканчивается на
UL> каком-то определенном макро-уровне. То, что лежит
UL> ниже, реализовано уже с использованием другой
UL> парадигмы. В целом получается многослойный дизайн.
UL> Язык многих парадигм, прямо как в C++ (но ОО туда
UL> не входит ;-)).
И что, биты в объекте Int языка Smalltalk тоже обмениваются сообщениями?
Или где-то на уровне Int или Char заканчивается ООшность?
UL> design patterns. Moreover,
SZ>> datatype-generic programming is a
UL> precisely-defined notion with a rigorous
SZ>> mathematical foundation, in contrast to
UL> generic programming in general and the
SZ>> C++ template mechanism in particular, and
UL> thereby offers the prospect of
SZ>> better static checking and a greater ability
UL> to reason about generic programs.
UL> У генерического C++ совсем плохо с компонентным
UL> подходом. Имеется ли такой язык, который позволяет
UL> и изолированные компоненты создавать и полностью
UL> сохранить статическую валидацию generic-функций?
Система типов ML или Haskell умеет большую часть возможностей шаблонов.
UL> Мне больше нравится подход CLOS - динамический,
UL> ОО-шный, но не object- а function-centered. Еще
UL> один маневр в рамках ОО.
О! Ну да.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Victor Metelitsa
Serguey Zefirov wrote:
>
>>>Uladzimir Liashkevich (sorry for my humble out-of-memory spelling) как-то раз
>>>осторожно высказал именно эту идею, когда был поставлен лицом перед фактом,
>>>что в Erlang:
>>>а) Есть независимые процессы и
>>>б) процессы обмениваются сообщениями и
>>>в) Erlang не статически типизирован.
>>>
>>>По его мнению, все, что обменивается сообщениями - ОО. ;)
>>>
>
> VM> Насколько я помню, для ОО требуется три признака, примерно такие:
>
> VM> 1. Все - объекты, и ничего кроме;
> VM> 2. Объекты скрывают в себе данные (имеется в виду инкапсуляция);
>
> Чем успешнее они их в себе скрывают, тем меньше мы о них знаем. Так, что (в
> пределе) есть у объектов данные, что нет у объектов данных (прокси) - разницы
> нет.
>
> VM> 3. Объекты взаимодействуют между собой путем посылки сообщений.
>
> VM> Так определял ОО тот, кто придумал этот термин. В частности,
> VM> наследование не упоминается.
>
> Теперь сравним:
> а) все - процессы;
> б) процессы взаимодействуют между собой путем посылки сообщений.
К сожалению (или счастью? ;-) ), с Erlang'ом я не знаком. Там есть
числа? А числа - это процессы? Числам можно посылать сообщения?
--
Victor Metelitsa
Serguey Zefirov wrote:
> Hello Uladzimir,
>
> Monday, August 25, 2003, 11:16:39 AM, you wrote:
>
>
> UL> Притягивать тут особо нечего. Определение довольно
> UL> общее, под него может подпасть множество вещей. Я
> UL> бы сказал, что Erlang действительно ОО-шный.
>
> UL> Но девиция имеется. В частности важной
> UL> особенностью ОО системы должен являться
> UL> рекурсивный дизайн, дающий самым малым частям
> UL> такие же возможности, как и у всей системы в
> UL> целом. ОО-шность Erlang-а видимо заканчивается на
> UL> каком-то определенном макро-уровне. То, что лежит
> UL> ниже, реализовано уже с использованием другой
> UL> парадигмы. В целом получается многослойный дизайн.
> UL> Язык многих парадигм, прямо как в C++ (но ОО туда
> UL> не входит ;-)).
>
> И что, биты в объекте Int языка Smalltalk тоже обмениваются сообщениями?
>
Нету там никаких битов. (Именно так: битовые операции есть, а битов нету
;-) ).
--
Serguey Zefirov
Tuesday, August 26, 2003, 12:05:19 AM, you wrote:
>>
>> И что, биты в объекте Int языка Smalltalk тоже обмениваются сообщениями?
>>
VM> Нету там никаких битов. (Именно так: битовые операции есть, а битов нету
VM> ;-) ).
Ну, вот мы и натолкнулись на ограничение применимости. Thank you very much.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Serguey Zefirov
Tuesday, August 26, 2003, 1:08:21 AM, you wrote:
>>>>И что, биты в объекте Int языка Smalltalk тоже обмениваются сообщениями?
>>
>> VM> Нету там никаких битов. (Именно так: битовые операции есть, а битов нету
>> VM> ;-) ).
>>
>> Ну, вот мы и натолкнулись на ограничение применимости. Thank you very much.
>>
VM> Не понял. На ограничение применимости в чем мы натолкнулись?
В эффективности.
Victor Metelitsa
Serguey Zefirov wrote:
> Hello Victor,
>
> Tuesday, August 26, 2003, 1:08:21 AM, you wrote:
>
>
>
>>>>>И что, биты в объекте Int языка Smalltalk тоже обмениваются сообщениями?
>>>
>>>VM> Нету там никаких битов. (Именно так: битовые операции есть, а битов нету
>>>VM> ;-) ).
>>>
>>>Ну, вот мы и натолкнулись на ограничение применимости. Thank you very much.
>>>
>
> VM> Не понял. На ограничение применимости в чем мы натолкнулись?
>
> В эффективности.
На ограничение применимости в эффективности???
--
Serguey Zefirov
Tuesday, August 26, 2003, 1:21:53 AM, you wrote:
>>
>> VM> Не понял. На ограничение применимости в чем мы натолкнулись?
>>
>> В эффективности.
VM> На ограничение применимости в эффективности???
Ну так. Никто же не пользуется числами Пеано в числодробилках _напрямую_, для
вычисления, например, значения аккумулятора в MAC. Так и здесь - как стало
невыгодно, так и не ОО. А иначе - где коллекция битов числа?
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Victor Metelitsa
Serguey Zefirov wrote:
> Hello Victor,
>
> Tuesday, August 26, 2003, 1:21:53 AM, you wrote:
>
>
>
>>>VM> Не понял. На ограничение применимости в чем мы натолкнулись?
>>>
>>>В эффективности.
>
>
> VM> На ограничение применимости в эффективности???
>
> Ну так.
Так и не понимаю я этого выражения. Буду считать, что было сказано
что-то вроде "ограничение применений в связи с низкой эффективностью".
> Никто же не пользуется числами Пеано в числодробилках _напрямую_, для
> вычисления, например, значения аккумулятора в MAC. Так и здесь - как стало
> невыгодно, так и не ОО. А иначе - где коллекция битов числа?
Да, возможно, но невыгодно. Но и не царское это дело - в битах
ковыряться. [Я вот на разработчиков "Сирены-2.3" удивляюсь - в одной из
таблиц (СУБД Sybase) влепили в одно поле три, битовыми операциями -
приступ жадности напал?].
--
Uladzimir Liashkevich
SZ> Hello Uladzimir,
SZ> Monday, August 25, 2003, 11:16:39 AM, you wrote:
UL>> Притягивать тут особо нечего. Определение
довольно
UL>> общее, под него может подпасть множество вещей. Я
UL>> бы сказал, что Erlang действительно ОО-шный.
UL>> Но девиция имеется. В частности важной
UL>> особенностью ОО системы должен являться
UL>> рекурсивный дизайн, дающий самым малым частям
UL>> такие же возможности, как и у всей системы в
UL>> целом. ОО-шность Erlang-а видимо заканчивается на
UL>> каком-то определенном макро-уровне. То, что лежит
UL>> ниже, реализовано уже с использованием другой
UL>> парадигмы. В целом получается многослойный
дизайн.
UL>> Язык многих парадигм, прямо как в C++ (но ОО туда
UL>> не входит ;-)).
SZ> И что, биты в объекте Int языка Smalltalk тоже
обмениваются сообщениями?
SZ> Или где-то на уровне Int или Char
заканчивается ООшность?
Это как рекурсия или индукция. Есть база, с
которой все начинается. ОО это не технология для
машин, а технология для людей. Поэтому ОО-шность
начинается там, где начинается работа
программиста. А как внутри машины это устроено -
проблема инженеров и создателей компиляторов.
UL>> design patterns. Moreover,
SZ>>> datatype-generic programming is a
UL>> precisely-defined notion with a rigorous
SZ>>> mathematical foundation, in contrast to
UL>> generic programming in general and the
SZ>>> C++ template mechanism in particular, and
UL>> thereby offers the prospect of
SZ>>> better static checking and a greater ability
UL>> to reason about generic programs.
UL>> У генерического C++ совсем плохо с компонентным
UL>> подходом. Имеется ли такой язык, который
позволяет
UL>> и изолированные компоненты создавать и полностью
UL>> сохранить статическую валидацию generic-функций?
SZ> Система типов ML или Haskell умеет большую
часть возможностей шаблонов.
UL>> Мне больше нравится подход CLOS - динамический,
UL>> ОО-шный, но не object- а function-centered. Еще
UL>> один маневр в рамках ОО.
SZ> О! Ну да.
--
Владимир.
Serguey Zefirov
>> вычисления, например, значения аккумулятора в MAC. Так и здесь - как стало
>> невыгодно, так и не ОО. А иначе - где коллекция битов числа?
VM> Да, возможно, но невыгодно. Hо и не царское это дело - в битах
VM> ковыряться.
VM>[Я вот на разработчиков "Сирены-2.3" удивляюсь - в одной из
VM> таблиц (СУБД Sybase) влепили в одно поле три, битовыми операциями -
VM> приступ жадности напал?].
А вот какой алгоритм возведения числа в степень ты знаешь?
Я, например, такой, в котором коллекция битов показателя степени была бы
не лишней.
Serguey Zefirov.
Serguey Zefirov
UL>>> Язык многих парадигм, прямо как в C++ (но ОО туда
UL>>> не входит ;-)).
SZ>> И что, биты в объекте Int языка Smalltalk тоже
UL> обмениваются сообщениями?
SZ>> Или где-то на уровне Int или Char
UL> заканчивается ООшность?
UL> Это как рекурсия или индукция. Есть база, с
UL> которой все начинается. ОО это не технология для
UL> машин, а технология для людей. Поэтому ОО-шность
UL> начинается там, где начинается работа
UL> программиста. А как внутри машины это устроено -
UL> проблема инженеров и создателей компиляторов.
Первое - все технологии создаются для людей.
Второе - старый неоконченый спор насчет преимуществ Smalltalk продолжить
не желаешь? Мы остановились в районе безымянных функций и полиморфизма.
Кстати, является ли безымянный блок кода объектом, и какие собщения
он умеет обрабатывать?
Serguey Zefirov.
Anton Moscal
You wrote to Serguey Zefirov on Mon, 25 Aug 2003 18:16:39 +0000 (UTC):
UL> У генерического C++ совсем плохо с компонентным
UL> подходом. Имеется ли такой язык, который позволяет
UL> и изолированные компоненты создавать и полностью
UL> сохранить статическую валидацию generic-функций?
Haskell. Cобственно - его классы типов это как раз и есть то самое для
template и перегрузки функций. C точностью до того, что некоторые
дизайнерские решения были другими (в основном в сторону искоренения
конфликтов имен - там где С++ предлгает правило разрешения конфликта, авторы
Haskell препочитают считать это ошибкой)
Anton
Victor Metelitsa
Извини, но это опять не царское дело. На это специальные люди есть,
которые виртуальные машины пишут. Вот они и занимаются подобными вопросами.
Sergey P. Derevyago
> конфликтов имен - там где С++ предлгает правило разрешения конфликта, авторы
> Haskell препочитают считать это ошибкой)
--
С уважением, Сергей. http://cpp3.virtualave.net/
mailto:ders?skeptik.net
Serguey Zefirov
Tuesday, August 26, 2003, 9:44:32 AM, you wrote:
>> А вот какой алгоритм возведения числа в степень ты знаешь?
>>
>> Я, например, такой, в котором коллекция битов показателя степени была бы
>> не лишней.
VM> Извини, но это опять не царское дело.
И все же: какой алгоритм возведения в числа в целую степень ты знаешь?
VM> На это специальные люди есть,
VM> которые виртуальные машины пишут. Вот они и занимаются подобными вопросами.
И что, виртуальная машина должна поддерживать все алгоритмы, в которых может
потребоваться обращаться к индивидуальным битам числа?
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Uladzimir Liashkevich
AM> Hello, Uladzimir!
AM> You wrote to Serguey Zefirov on Mon, 25 Aug
2003 18:16:39 +0000 (UTC):
UL>> У генерического C++ совсем плохо с компонентным
UL>> подходом. Имеется ли такой язык, который
позволяет
UL>> и изолированные компоненты создавать и полностью
UL>> сохранить статическую валидацию generic-функций?
AM> Haskell. Cобственно - его классы типов это как
раз и есть то самое для
AM> template и перегрузки функций. C точностью до
того, что некоторые
AM> дизайнерские решения были другими (в основном
в сторону искоренения
AM> конфликтов имен - там где С++ предлгает
правило разрешения конфликта, авторы
AM> Haskell препочитают считать это ошибкой)
Теоретический аспект я понимаю. В этом вопросе я
спрашивал про практику. Можно ли разработать свою
библиотеку generic-функций, скомпилировать ее в
некоторое бинарное представление и распространять
ее как это делается в случае dll, com-объектов или
jar-файлов. Чтобы другие приложения могли ее
использовать, причем имея всю ту же статическую
валидацию как и при наличии исходников.
AM> Anton
Victor Metelitsa
Serguey Zefirov wrote:
> Hello Victor,
>
> Tuesday, August 26, 2003, 9:44:32 AM, you wrote:
>
>
>>>А вот какой алгоритм возведения числа в степень ты знаешь?
>>>
>>>Я, например, такой, в котором коллекция битов показателя степени была бы
>>>не лишней.
>
>
> VM> Извини, но это опять не царское дело.
>
> И все же: какой алгоритм возведения в числа в целую степень ты знаешь?
>
А зачем тебе такие сведения? Чтобы продемострировать, что ты знаешь
больше этих алгоритмов? Или надеешься найти какие-нибудь, не знакомые тебе?
> VM> На это специальные люди есть,
> VM> которые виртуальные машины пишут. Вот они и занимаются подобными вопросами.
>
> И что, виртуальная машина должна поддерживать все алгоритмы, в которых может
> потребоваться обращаться к индивидуальным битам числа?
Какой мощный прыжок - от возведения в степень ко "всем алгоритмам"!
Причем ведь я тебе уже _все_ объяснил.
--
Alexander Kobets
"Uladzimir Liashkevich" <u...@atwss.com> сообщил/сообщила в новостях
следующее:
...
> Теоретический аспект я понимаю. В этом вопросе я
> спрашивал про практику. Можно ли разработать свою
> библиотеку generic-функций, скомпилировать ее в
> некоторое бинарное представление и распространять
> ее как это делается в случае dll, com-объектов или
> jar-файлов. Чтобы другие приложения могли ее
> использовать, причем имея всю ту же статическую
> валидацию как и при наличии исходников.
Позднее связывание? IDispatch?
Пока.
--
Serguey Zefirov
Wednesday, August 27, 2003, 1:42:28 AM, you wrote:
>> VM> Извини, но это опять не царское дело.
>>
>> И все же: какой алгоритм возведения в числа в целую степень ты знаешь?
>>
VM> А зачем тебе такие сведения? Чтобы продемострировать, что ты знаешь
VM> больше этих алгоритмов? Или надеешься найти какие-нибудь, не знакомые тебе?
Мне интересно, какие алгоритмы возведения в целую степень ты знаешь. Хотя твои
ответы-вопросы достаточно красноречивы.
>> VM> На это специальные люди есть,
>> VM> которые виртуальные машины пишут. Вот они и занимаются подобными вопросами.
>>
>> И что, виртуальная машина должна поддерживать все алгоритмы, в которых может
>> потребоваться обращаться к индивидуальным битам числа?
VM> Какой мощный прыжок - от возведения в степень ко "всем алгоритмам"!
VM> Причем ведь я тебе уже _все_ объяснил.
То есть, мы приехали к концу "рекурсивного дизайна". Ну, и замечательно.
Конец этот довольно размыт, и находится где-то в районе "не царского
дела для Victor Metelitsa". Где-то в районе битовых операций. Или MAC. Где-то
там.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Uladzimir Liashkevich
UL>>>> Язык многих парадигм, прямо как в C++ (но
ОО туда
UL>>>> не входит ;-)).
SZ>>> И что, биты в объекте Int языка Smalltalk тоже
UL>> обмениваются сообщениями?
SZ>>> Или где-то на уровне Int или Char
UL>> заканчивается ООшность?
UL>> Это как рекурсия или индукция. Есть база, с
UL>> которой все начинается. ОО это не технология для
UL>> машин, а технология для людей. Поэтому ОО-шность
UL>> начинается там, где начинается работа
UL>> программиста. А как внутри машины это устроено -
UL>> проблема инженеров и создателей компиляторов.
SZ> Первое - все технологии создаются для людей.
Едва ли.
Могу перечислить какие признаки говорят что
технология не для людей:
* Говоришь - примитивные типы все усложняют, тебе
отвечают - а иначе тормоза.
* Если нарушается принцип 7+-2 даже в простейших
случаях.
* Если для того чтобы увидеть результат простейшей
операции нужно проделать множество действий.
Smalltalk старается минизировать количество
артефактов на пути от идеи до получения результата.
Он и создавался уникальным образом, я не знаю
других таких случаев.
В общем было 5 больших итераций создания языка, по
годам - 72, 74, 76, 78, 80. На каждом этапе
разрабатывался детальный дизайн языка на основе
каких-то предположений и практических результатов.
Потом язык проходил тестирование в реальных
условиях на реальных задачах.
Причем основной упор делался на работу с детьми в
возрасте 10-12 лет. У них мышление не зашорено
никакими предпочтениями и с их помощью можно четко
увидеть какие подходы предпочтительны с точки
зрения обучения и эффективности использования
человеком.
После этого шла следующая итерация создания языка
с учетом всей собранной информации.
[Я видел видео, на котором 14-летний школьник в
76-ом году демонстрировал графический редактор
электрических схем, написанный самостоятельно
(выглядел отлично между прочим - с drag&drop,
редактированием - как Visio). Спустя годы
защищались диссертации с программами похуже этой.]
Отсюда видно, что сам процесс создания языка
подпадает все под те же принципы ООП -
динамическое эволюционное развитие. Отсюда также
видно насколько родственны Smalltalk и XP - они
фактически являются воплощением принципов ООП в
своих областях.
Многие другие технологии делают упор на
надежность. Это как в случае с web-серверами -
100% up-time. Но цель недостижима и это всем
известно. Вместо этого Smalltalk смещает упор на
recoverability и adaptability - насколько ты
быстро можешь приспособиться к меняющимся условиям
и восстановиться после сбоя. Статические
технологии в погоне за 100% надежности (в
действительности 99.9%) теряют гибкость в
результате чего цена нестандартной ситуации может
стать слишком высокой.
Рассказали мне как-то про одну real-time систему
для телефонии, которая пишется в Motorola. У них
там сервера по миллиону за штуку, система полного
дублирования; когда нужно пропатчить софт,
заливают его на зеркало, первый сервер глушат,
второй поднимают. И на это все равно требуется 10
минут.
Собираются продать систему полиции, но с этим у
них проблемы - прикиньте что они будут говорить -
извиняйте ребята, сегодня с 12:00 по 12:10 вся
ваша связь не будет работать из-за заливания софта.
И пофигу тут становятся всяческие рюшечки с
типизацией, доказательностью и корректностью по
построению.
[Думаю динамический объектный subj им тут помог бы
;-)]
SZ> Второе - старый неоконченый спор насчет
преимуществ Smalltalk продолжить
SZ> не желаешь? Мы остановились в районе
безымянных функций и полиморфизма.
Особо времени нет. Да к тому же повторяются одни и
те же аргументы.
SZ> Кстати, является ли безымянный блок кода
объектом, и какие собщения
SZ> он умеет обрабатывать?
Является (в случае Smalltalk этот вопрос неуместен
:-)).
Конструкция [...] как и число/строка является
литералом - экземпляром объекта BlockClosure. Т.е.
все методы этого класса доступны, его можно
расширять, соответственно все замыкания получат
новую функциональность, например - #callCC, #fork,
#ensure:, #repeat.
Структура этого объекта:
* Ссылается на локальные переменные родительских
контекстов.
* Держит ссылку на корневой родительский контекст
для нелокального возврата.
* Хранит метод реализующий код замыкания. Вызов
этого метода осуществляется сообщением #value,
#value:, ... #value:[value:]+ в зависимости от
количества параметров. Тут инициализация контекста
вызова работает немного по-другому - self
указывает не на объект-замыкание, вместо этого
берется self из родительского контекста.
Объект-замыкание выглядит простовато, но это из-за
того, что его уже достаточно для всех случаев жизни.
В Java например есть анонимные классы, в которым
можно объявлять любые методы.
Аналог блока выглядел бы так:
new BlockClosure()
{ Object value() { ... } }
Но имеется куча проблем - анонимный класс не
является полноценным классом, т.к. такой объект
является экземпляром Class (опять непонятный
частный случай) а не того который указан после new
(там вроде всегда интерфейсы задаются), параметры
придется через Object прогонять, return локальный
и т.д.
Т.е. если нет полноценных замыканий, то уже ничем
не сможешь их заменить.
SZ> Serguey Zefirov.
Uladzimir Liashkevich
AK> Привет,
AK> "Uladzimir Liashkevich" <u...@atwss.com>
сообщил/сообщила в новостях
AK> следующее:
AK> ...
AK>> Теоретический аспект я понимаю. В этом вопросе я
AK>> спрашивал про практику. Можно ли разработать свою
AK>> библиотеку generic-функций, скомпилировать ее в
AK>> некоторое бинарное представление и распространять
AK>> ее как это делается в случае dll,
com-объектов или
AK>> jar-файлов. Чтобы другие приложения могли ее
AK>> использовать, причем имея всю ту же статическую
AK>> валидацию как и при наличии исходников.
AK> Позднее связывание? IDispatch?
Угу, причем для
fmap :: (a -> b) -> (f a -> f b)
:-)
AK> Пока.
--
Владимир.
Uladzimir Liashkevich
SZ> Hello Victor,
SZ> Tuesday, August 26, 2003, 9:44:32 AM, you wrote:
SZ>>> А вот какой алгоритм возведения числа в
степень ты знаешь?
SZ>>>
SZ>>> Я, например, такой, в котором коллекция
битов показателя степени была бы
SZ>>> не лишней.
VM>> Извини, но это опять не царское дело.
SZ> И все же: какой алгоритм возведения в числа в
целую степень ты знаешь?
VM>> На это специальные люди есть,
VM>> которые виртуальные машины пишут. Вот они и
занимаются подобными вопросами.
SZ> И что, виртуальная машина должна поддерживать
все алгоритмы, в которых может
SZ> потребоваться обращаться к индивидуальным
битам числа?
Можно реализовать с успехом любые алгоритмы
работающие с битами. Integer>>bitAnd: и прочее у
тебя в наличии.
Другое дело зачем тебе эти биты. Если для Win32
API вызовов, то нет проблем. Если для скорости
возведения в степень, то эта скорость тебе может
не понадобится (результаты профайлов есть?), а
если понадобится, то можно портировать алгоритм на
C (или какие-то его части которые с битами
работают и тормозят) или лучше взять готовую
библиотеку.
В Squeak вообще интересно сделано - пишешь plugin
на Smalltalk, потом прогоняешь его через SLang
translator, который генерит C-код, компилируешь,
подлинковываешь, и у тебя готов быстрый код
нужного алгоритма.
--
Владимир.
Alexander Kobets
...
> AK> Позднее связывание? IDispatch?
>
> Угу, причем для
> fmap :: (a -> b) -> (f a -> f b)
> :-)
Не в курсе. А библиотека работы с интерфейсом COM не обеспечивает такую
типизацию?
Пока.
--
Victor Metelitsa
Uladzimir Liashkevich wrote:
[...]
>
> Можно реализовать с успехом любые алгоритмы
> работающие с битами. Integer>>bitAnd: и прочее у
> тебя в наличии.
просит, а чтобы число было коллекцией битов, биты были объектами и им
можно было посылать сообщения и т.д., и чтобы впридачу это было быстро.
В противном случае ОО (ST)-подход объявляется негодным по эффективности.
> Другое дело зачем тебе эти биты. Если для Win32
> API вызовов, то нет проблем. Если для скорости
> возведения в степень, то эта скорость тебе может
> не понадобится (результаты профайлов есть?), а
> если понадобится, то можно портировать алгоритм на
> C (или какие-то его части которые с битами
> работают и тормозят) или лучше взять готовую
> библиотеку.
А если для того, чтобы знания алгоритмов продемонстрировать? ;-)
PS
[Я, конечно, мог бы пошариться у себя на забитых книжных полках, где
кроме всего прочего есть и Кнут, и Вирт, и Дейкстра, чтобы вспомнить за
полной ненадобностью забытый хлам типа возведения в степень (даже
вычисление случайных чисел и сортировки намного актуальнее), но для чего?].
--
Andrei N. Sobchuck
>> Можно реализовать с успехом любые алгоритмы
>> работающие с битами. Integer>>bitAnd: и прочее у
>> тебя в наличии.
VM> просит, а чтобы число было коллекцией битов, биты были объектами и им
VM> можно было посылать сообщения и т.д., и чтобы впридачу это было быстро.
VM> В противном случае ОО (ST)-подход объявляется негодным по эффективности.
Сложностей никаких. Строка в ST уже является простой коллекцией [букв].
Другое дело, что как не крути, а меньше байта у тебя ничего занимать не
будет. Значит "коллекционный" байт займёт 8 "обычных" байтов.
А если все биты упаковать, то получим то, что есть сейчас. А именно - битовые
операции есть, а битов нет.
Кстати, ничего не мешает добавить поддержку интерфейса коллекций к Целым.
Кстати2, в С числа, это отнюдь не коллекции битов, а алгоритм
возведения в степень есть - парадокс?
--
Андрей Собчук
and...@itware.com.ua
Anton Moscal
AM>> Haskell препочитают считать это ошибкой)
UL> Теоретический аспект я понимаю. В этом вопросе я
UL> спрашивал про практику. Можно ли разработать свою
UL> библиотеку generic-функций, скомпилировать ее в
UL> некоторое бинарное представление и распространять
UL> ее как это делается в случае dll, com-объектов или
UL> jar-файлов. Чтобы другие приложения могли ее
UL> использовать, причем имея всю ту же статическую
UL> валидацию как и при наличии исходников.
Можно. Cобственно исходники для этого и не используются используются
.hi-файлы. Более того - насколько я понимаю в JDK 1.5 это просто есть. В
generic версии .NET тоже можно. Ну и в Caml, где generic'и несколько другие,
тоже можно.
Причем, по крайней мере в O'Caml интерфейсная часть модуля, необходимая для
компиляции кода, который ее использует отделена от реализационной и информация
о реализации в момент компиляции просто отсуствует.
На самом-то деле ничего сложного в этом нет.
Антон
Serguey Zefirov
UL>>> заканчивается ООшность?
UL>>> Это как рекурсия или индукция. Есть база, с
UL>>> которой все начинается. ОО это не технология для
UL>>> машин, а технология для людей. Поэтому ОО-шность
UL>>> начинается там, где начинается работа
UL>>> программиста. А как внутри машины это устроено -
UL>>> проблема инженеров и создателей компиляторов.
SZ>> Первое - все технологии создаются для людей.
UL> Едва ли.
UL> Могу перечислить какие признаки говорят что
UL> технология не для людей:
UL> * Говоришь - примитивные типы все усложняют, тебе
UL> отвечают - а иначе тормоза.
UL> * Если нарушается принцип 7+-2 даже в простейших
UL> случаях.
UL> * Если для того чтобы увидеть результат простейшей
UL> операции нужно проделать множество действий.
Простейшее действие - получить программу для ADSP2181, точнее, для
EZ-KIT Lite, которая мигает светодиодом с полупериодом в секунду.
Каковы ваши действия для выбранной вами "самой человечной" платформы?
А вот у меня есть тестовая программка, которое именно это и делает.
А также ассемблер и линкер для ADSP21xx. Другое дело, что ваять редактор
эл. цепей я на нем не возьмусь.
(чтобы стало понятно, зачем это может понадобиться - см., например,
http://www.ti.com, у них на сайте есть недавний отчет о 2003Q3. Указывается
оборот в $3*10^9, из которых значительная часть (~30%) приходится на DSP.
ADSP - это Analog Devices, который, почему-то, сильно популярен в России)
UL> Smalltalk старается минизировать количество
UL> артефактов на пути от идеи до получения результата.
UL> Он и создавался уникальным образом, я не знаю
UL> других таких случаев.
Forth.
UL> В общем было 5 больших итераций создания языка, по
UL> годам - 72, 74, 76, 78, 80. Hа каждом этапе
UL> разрабатывался детальный дизайн языка на основе
UL> каких-то предположений и практических результатов.
UL> Потом язык проходил тестирование в реальных
UL> условиях на реальных задачах.
UL> Причем основной упор делался на работу с детьми в
UL> возрасте 10-12 лет. У них мышление не зашорено
UL> никакими предпочтениями и с их помощью можно четко
UL> увидеть какие подходы предпочтительны с точки
UL> зрения обучения и эффективности использования
UL> человеком.
Только - не человеком, а ребенком. И не реальные проекты, в которых
работают реальные люди с большими животами.
UL> После этого шла следующая итерация создания языка
UL> с учетом всей собранной информации.
UL> [Я видел видео, на котором 14-летний школьник в
UL> 76-ом году демонстрировал графический редактор
UL> электрических схем, написанный самостоятельно
UL> (выглядел отлично между прочим - с drag&drop,
UL> редактированием - как Visio). Спустя годы
UL> защищались диссертации с программами похуже этой.]
Мне интересно, куда затем пошел этот редактор. Каково было его развитие.
UL> Отсюда видно, что сам процесс создания языка
UL> подпадает все под те же принципы ООП -
UL> динамическое эволюционное развитие.
Прошу ограничить количество принципов. Перечисли их все заранее.
UL> Многие другие технологии делают упор на
UL> надежность. Это как в случае с web-серверами -
UL> 100% up-time. Hо цель недостижима и это всем
UL> известно. Вместо этого Smalltalk смещает упор на
UL> recoverability и adaptability - насколько ты
UL> быстро можешь приспособиться к меняющимся условиям
UL> и восстановиться после сбоя. Статические
UL> технологии в погоне за 100% надежности (в
UL> действительности 99.9%) теряют гибкость в
UL> результате чего цена нестандартной ситуации может
UL> стать слишком высокой.
Ты с какими технологиями сравниваешь?
UL> Рассказали мне как-то про одну real-time систему
UL> для телефонии, которая пишется в Motorola. У них
UL> там сервера по миллиону за штуку, система полного
UL> дублирования; когда нужно пропатчить софт,
UL> заливают его на зеркало, первый сервер глушат,
UL> второй поднимают. И на это все равно требуется 10
UL> минут.
UL> Собираются продать систему полиции, но с этим у
UL> них проблемы - прикиньте что они будут говорить -
UL> извиняйте ребята, сегодня с 12:00 по 12:10 вся
UL> ваша связь не будет работать из-за заливания софта.
UL> И пофигу тут становятся всяческие рюшечки с
UL> типизацией, доказательностью и корректностью по
UL> построению.
UL> [Думаю динамический объектный subj им тут помог бы
UL> ;-)]
- Динамический объектный Maybe Erlang is OO after all? им бы тут помог, -
прочитал шизоидный я.
Действительно, Erlang используется в телефонии.
SZ>> Второе - старый неоконченый спор насчет
UL> преимуществ Smalltalk продолжить
SZ>> не желаешь? Мы остановились в районе
UL> безымянных функций и полиморфизма.
UL> Особо времени нет. Да к тому же повторяются одни и
UL> те же аргументы.
Почему? Мы тогда начали сдвигаться с места. Например, обнаружили,
что не только в Smalltalk и Lisp (динамических языках) есть лямбды.
И что одна из сильных сторон Smalltalk именно в них и заложена.
SZ>> Кстати, является ли безымянный блок кода
UL> объектом, и какие собщения
SZ>> он умеет обрабатывать?
UL> Является (в случае Smalltalk этот вопрос неуместен
UL> :-)).
Почему? Уместен.
UL> Конструкция [...] как и число/строка является
UL> литералом - экземпляром объекта BlockClosure. Т.е.
UL> все методы этого класса доступны, его можно
UL> расширять, соответственно все замыкания получат
UL> новую функциональность, например - #callCC, #fork,
UL> #ensure:, #repeat.
UL> Структура этого объекта:
UL> * Ссылается на локальные переменные родительских
UL> контекстов.
UL> * Держит ссылку на корневой родительский контекст
UL> для нелокального возврата.
UL> * Хранит метод реализующий код замыкания. Вызов
UL> этого метода осуществляется сообщением #value,
UL> #value:, ... #value:[value:]+ в зависимости от
UL> количества параметров. Тут инициализация контекста
UL> вызова работает немного по-другому - self
UL> указывает не на объект-замыкание, вместо этого
UL> берется self из родительского контекста.
А объект-контекст как выглядит? А как происходит вызов метода, а какие события
имеет объект "стек конекстов", и можно ли завести два таких объекта, а вернуть
управление из метода через второй, а что после этого будет и тр и пр.
sz
Serguey Zefirov
VM>>> Hа это специальные люди есть,
VM>>> которые виртуальные машины пишут. Вот они и
UL> занимаются подобными вопросами.
SZ>> И что, виртуальная машина должна поддерживать
UL> все алгоритмы, в которых может
SZ>> потребоваться обращаться к индивидуальным
UL> битам числа?
UL> Можно реализовать с успехом любые алгоритмы
UL> работающие с битами. Integer>>bitAnd: и прочее у
UL> тебя в наличии.
UL> Другое дело зачем тебе эти биты. Если для Win32
UL> API вызовов, то нет проблем. Если для скорости
UL> возведения в степень, то эта скорость тебе может
UL> не понадобится (результаты профайлов есть?), а
UL> если понадобится, то можно портировать алгоритм на
UL> C (или какие-то его части которые с битами
UL> работают и тормозят) или лучше взять готовую
UL> библиотеку.
Да я помогал, однажды, делать криптожелезку. Там были и ассиметричные
алгоритмы. И скорость возведения в степень 512-битных чисел на клоне 8051
была ну ой как важна. Да она не только на ней нужна.
Но мы говорим об удобстве программирования. А в этом случае это лучше
делается через список значений битов показателя степени. Понятно, что
через тестирование отдельных битов можно сделать, но все же...
Или еще пример из все той же криптографии: для DES используются перестановки
бит - начальная, оконечная и внутри цикла. Идеально было бы пользоваться
именно коллекцией битов, не так ли? Нечто типа этого:
out[i]:=lastround[outperm[i]].
Такая же вещь используется при помехоустойчивом кодировании, например, в
стримерах (я принимал участие в попытке создания видеостримера).
UL> В Squeak вообще интересно сделано - пишешь plugin
UL> на Smalltalk, потом прогоняешь его через SLang
UL> translator, который генерит C-код, компилируешь,
UL> подлинковываешь, и у тебя готов быстрый код
UL> нужного алгоритма.
Здорово.
sz
Serguey Zefirov
>>
>> Можно реализовать с успехом любые алгоритмы
>> работающие с битами. Integer>>bitAnd: и прочее у
>> тебя в наличии.
VM> Я же говорил - битовые операции есть, а битов нет. Он ведь не это
VM> просит, а чтобы число было коллекцией битов, биты были объектами и им
VM> можно было посылать сообщения и т.д., и чтобы впридачу это было быстро.
VM> В противном случае ОО (ST)-подход объявляется негодным по эффективности.
В общем - да.
>> Другое дело зачем тебе эти биты. Если для Win32
>> API вызовов, то нет проблем. Если для скорости
>> возведения в степень, то эта скорость тебе может
>> не понадобится (результаты профайлов есть?), а
>> если понадобится, то можно портировать алгоритм на
>> C (или какие-то его части которые с битами
>> работают и тормозят) или лучше взять готовую
>> библиотеку.
VM> А если для того, чтобы знания алгоритмов продемонстрировать? ;-)
Или заставить оппонента подумать в нужном направлении, сбив его поисками
алгоритма (с последующим обдумыванием) с его устоявшейся мысленной позиции.
Это будет ближе. ;)
VM> PS
VM> [Я, конечно, мог бы пошариться у себя на забитых книжных полках, где
VM> кроме всего прочего есть и Кнут, и Вирт, и Дейкстра, чтобы вспомнить за
VM> полной ненадобностью забытый хлам типа возведения в степень (даже
VM> вычисление случайных чисел и сортировки намного актуальнее), но для
VM> чего?].
To demonstrate good will.
sz
Serguey Zefirov
ANS> Сложностей никаких. Строка в ST уже является простой коллекцией [букв].
ANS> Другое дело, что как не крути, а меньше байта у тебя ничего занимать не
ANS> будет. Значит "коллекционный" байт займёт 8 "обычных" байтов.
Гыгы. У нас есть тэг, параметр 1 (указатель на следующий элемент в коллекции),
параметр 2 - указатель на элемент. Сам элемент - это тэг, параметр 1 (номер
бита?? или сам бит), и, в зависимости от реализации, еще
и указатель на число. Итого - не менее пяти машинных слов.
sz
Uladzimir Liashkevich
UL>>>> заканчивается ООшность?
UL>>>> Это как рекурсия или индукция. Есть база, с
UL>>>> которой все начинается. ОО это не
технология для
UL>>>> машин, а технология для людей. Поэтому
ОО-шность
UL>>>> начинается там, где начинается работа
UL>>>> программиста. А как внутри машины это
устроено -
UL>>>> проблема инженеров и создателей компиляторов.
SZ>>> Первое - все технологии создаются для людей.
UL>> Едва ли.
UL>> Могу перечислить какие признаки говорят что
UL>> технология не для людей:
UL>> * Говоришь - примитивные типы все усложняют, тебе
UL>> отвечают - а иначе тормоза.
UL>> * Если нарушается принцип 7+-2 даже в простейших
UL>> случаях.
UL>> * Если для того чтобы увидеть результат
простейшей
UL>> операции нужно проделать множество действий.
SZ> Простейшее действие - получить программу для
ADSP2181, точнее, для
SZ> EZ-KIT Lite, которая мигает светодиодом с
полупериодом в секунду.
SZ> Каковы ваши действия для выбранной вами "самой
человечной" платформы?
Примерно как и везде - взять нужный компилятор
(еще в 80-х активно использовался Embedded
Smalltalk - сейчас не в курсе, также имеется
Pocket Smalltalk), взять нужные либы, написать
нужный код. Только вот отличие, что в Smalltalk ты
мигание светодиода получишь быстрее чем на многих
других платформах.
SZ> А вот у меня есть тестовая программка, которое
именно это и делает.
SZ> А также ассемблер и линкер для ADSP21xx.
Другое дело, что ваять редактор
Поздравляю. А мне это не нужно.
SZ> эл. цепей я на нем не возьмусь.
SZ> (чтобы стало понятно, зачем это может
понадобиться - см., например,
SZ> http://www.ti.com, у них на сайте есть
недавний отчет о 2003Q3. Указывается
SZ> оборот в $3*10^9, из которых значительная
часть (~30%) приходится на DSP.
SZ> ADSP - это Analog Devices, который, почему-то,
сильно популярен в России)
Да пожалуйста. Я также слышал статистику, что
рынок электронной коммерции равен по объему рынку
средств увеличения груди. Так что, всем кидать
свою никчемную сферу деятельности? ;-)
UL>> Smalltalk старается минизировать количество
UL>> артефактов на пути от идеи до получения
результата.
UL>> Он и создавался уникальным образом, я не знаю
UL>> других таких случаев.
SZ> Forth.
UL>> В общем было 5 больших итераций создания
языка, по
UL>> годам - 72, 74, 76, 78, 80. Hа каждом этапе
UL>> разрабатывался детальный дизайн языка на основе
UL>> каких-то предположений и практических
результатов.
UL>> Потом язык проходил тестирование в реальных
UL>> условиях на реальных задачах.
UL>> Причем основной упор делался на работу с детьми в
UL>> возрасте 10-12 лет. У них мышление не зашорено
UL>> никакими предпочтениями и с их помощью можно
четко
UL>> увидеть какие подходы предпочтительны с точки
UL>> зрения обучения и эффективности использования
UL>> человеком.
SZ> Только - не человеком, а ребенком. И не
реальные проекты, в которых
SZ> работают реальные люди с большими животами.
Дети дают представление о learning curve и какие
есть затыки при освоении технологии человеком.
А сам язык не дети же писали.
UL>> После этого шла следующая итерация создания языка
UL>> с учетом всей собранной информации.
UL>> [Я видел видео, на котором 14-летний школьник в
UL>> 76-ом году демонстрировал графический редактор
UL>> электрических схем, написанный самостоятельно
UL>> (выглядел отлично между прочим - с drag&drop,
UL>> редактированием - как Visio). Спустя годы
UL>> защищались диссертации с программами похуже
этой.]
SZ> Мне интересно, куда затем пошел этот редактор.
Каково было его развитие.
Для школьника это было просто интересно. Видимо
потом он пошел в университет, где ему промыли мозг
"правильными" технологиями. :-)
UL>> Отсюда видно, что сам процесс создания языка
UL>> подпадает все под те же принципы ООП -
UL>> динамическое эволюционное развитие.
SZ> Прошу ограничить количество принципов.
Перечисли их все заранее.
Ты их уже все слышал. Объект, состояние,
последовательное его изменение, посылка сообщения,
рекурсивный дизайн.
UL>> Многие другие технологии делают упор на
UL>> надежность. Это как в случае с web-серверами -
UL>> 100% up-time. Hо цель недостижима и это всем
UL>> известно. Вместо этого Smalltalk смещает упор на
UL>> recoverability и adaptability - насколько ты
UL>> быстро можешь приспособиться к меняющимся
условиям
UL>> и восстановиться после сбоя. Статические
UL>> технологии в погоне за 100% надежности (в
UL>> действительности 99.9%) теряют гибкость в
UL>> результате чего цена нестандартной ситуации может
UL>> стать слишком высокой.
SZ> Ты с какими технологиями сравниваешь?
Со статическими. Где небольшие изменения системы
порой даются с большими усилиями.
UL>> Рассказали мне как-то про одну real-time систему
UL>> для телефонии, которая пишется в Motorola. У них
UL>> там сервера по миллиону за штуку, система полного
UL>> дублирования; когда нужно пропатчить софт,
UL>> заливают его на зеркало, первый сервер глушат,
UL>> второй поднимают. И на это все равно требуется 10
UL>> минут.
UL>> Собираются продать систему полиции, но с этим у
UL>> них проблемы - прикиньте что они будут говорить -
UL>> извиняйте ребята, сегодня с 12:00 по 12:10 вся
UL>> ваша связь не будет работать из-за заливания
софта.
UL>> И пофигу тут становятся всяческие рюшечки с
UL>> типизацией, доказательностью и корректностью по
UL>> построению.
UL>> [Думаю динамический объектный subj им тут
помог бы
UL>> ;-)]
SZ> - Динамический объектный Maybe Erlang is OO
after all? им бы тут помог, -
SZ> прочитал шизоидный я.
SZ> Действительно, Erlang используется в телефонии.
Я про него и говорил, а ты что подумал?
SZ>>> Второе - старый неоконченый спор насчет
UL>> преимуществ Smalltalk продолжить
SZ>>> не желаешь? Мы остановились в районе
UL>> безымянных функций и полиморфизма.
UL>> Особо времени нет. Да к тому же повторяются
одни и
UL>> те же аргументы.
SZ> Почему? Мы тогда начали сдвигаться с места.
Например, обнаружили,
SZ> что не только в Smalltalk и Lisp (динамических
языках) есть лямбды.
SZ> И что одна из сильных сторон Smalltalk именно
в них и заложена.
Да, они дают порядочный кусок эффективности.
Но основное - это непосредственное манипулирование
объектами через посылку сообщений, и хорошие
инструменты которые все это упрощают.
SZ>>> Кстати, является ли безымянный блок кода
UL>> объектом, и какие собщения
SZ>>> он умеет обрабатывать?
UL>> Является (в случае Smalltalk этот вопрос
неуместен
UL>> :-)).
SZ> Почему? Уместен.
Вспомни его лозунг - в мире нет ничего кроме
объектов. :-)
http://www.whysmalltalk.com/graphics/graphicimages/Smalltalkbaby.jpg
UL>> Конструкция [...] как и число/строка является
UL>> литералом - экземпляром объекта BlockClosure.
Т.е.
UL>> все методы этого класса доступны, его можно
UL>> расширять, соответственно все замыкания получат
UL>> новую функциональность, например - #callCC,
#fork,
UL>> #ensure:, #repeat.
UL>> Структура этого объекта:
UL>> * Ссылается на локальные переменные родительских
UL>> контекстов.
UL>> * Держит ссылку на корневой родительский контекст
UL>> для нелокального возврата.
UL>> * Хранит метод реализующий код замыкания. Вызов
UL>> этого метода осуществляется сообщением #value,
UL>> #value:, ... #value:[value:]+ в зависимости от
UL>> количества параметров. Тут инициализация
контекста
UL>> вызова работает немного по-другому - self
UL>> указывает не на объект-замыкание, вместо этого
UL>> берется self из родительского контекста.
SZ> А объект-контекст как выглядит? А как
происходит вызов метода, а какие события
SZ> имеет объект "стек конекстов", и можно ли
завести два таких объекта, а вернуть
SZ> управление из метода через второй, а что после
этого будет и тр и пр.
Почитай
http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_imp_toc.html
(особенно глава 27 - Objects Use by Interpreter)
Это главы из классической Blue Book рассказывающие
о реализации виртуальной машины Smalltalk-80.
Сразу скажу, что там реализованы неполные
замыкания, которые становятся невалидными после
завершения метода-родителя. Практически все
современные реализации уже имеют full closures. А
также схемы отображения объектов-контекстов на
стек и другие продвинутые трюки.
SZ> sz
Andrei N. Sobchuck
UL>> В Squeak вообще интересно сделано - пишешь plugin
UL>> на Smalltalk, потом прогоняешь его через SLang
UL>> translator, который генерит C-код, компилируешь,
UL>> подлинковываешь, и у тебя готов быстрый код
UL>> нужного алгоритма.
SZ> Здорово.
Но есть ограничения на используемые конструкции.
--
Андрей Собчук
and...@itware.com.ua
Andrei N. Sobchuck
SZ> Гыгы. У нас есть тэг, параметр 1 (указатель на следующий элемент в коллекции),
SZ> параметр 2 - указатель на элемент. Сам элемент - это тэг, параметр 1 (номер
SZ> бита?? или сам бит), и, в зависимости от реализации, еще
SZ> и указатель на число. Итого - не менее пяти машинных слов.
Не совсем так. Но это *абсолютно* не принципиально
Serguey Zefirov
Wednesday, August 27, 2003, 7:47:09 AM, you wrote:
SZ>> Простейшее действие - получить программу для
UL> ADSP2181, точнее, для
SZ>> EZ-KIT Lite, которая мигает светодиодом с
UL> полупериодом в секунду.
SZ>> Каковы ваши действия для выбранной вами "самой
UL> человечной" платформы?
UL> Примерно как и везде - взять нужный компилятор
UL> (еще в 80-х активно использовался Embedded
UL> Smalltalk - сейчас не в курсе, также имеется
UL> Pocket Smalltalk), взять нужные либы, написать
UL> нужный код. Только вот отличие, что в Smalltalk ты
UL> мигание светодиода получишь быстрее чем на многих
UL> других платформах.
Слабо верится. Причем чем больше ищу, тем слабее.
Pocket Smalltalk - это для хандхелдов, причем только для пальмов.
Embedded Smalltalk - часто это Smalltalk, встроенный в HTML. Максимум - это
PIC/Smalltalk.
Будь добр, дай ссылку поточнее. А пока - Smalltalk не может работать с
ADSP2181, даже в качестве кросскомпилятора. И для простейшей задачи мне
понадобиться что? Правильно, совершать кучу ненужных действий. Например,
пристегивать g21 - gcc для adsp21xx. А у него код такой, что задержку в
секунду подобрать вряд ли получится. ;)
UL> Да пожалуйста. Я также слышал статистику, что
UL> рынок электронной коммерции равен по объему рынку
UL> средств увеличения груди. Так что, всем кидать
UL> свою никчемную сферу деятельности? ;-)
Знать о том, что существуют другие. Не менее денежные.
UL>>> В общем было 5 больших итераций создания
UL> языка, по
UL>>> годам - 72, 74, 76, 78, 80. Hа каждом этапе
UL>>> разрабатывался детальный дизайн языка на основе
UL>>> каких-то предположений и практических
UL> результатов.
UL>>> Потом язык проходил тестирование в реальных
UL>>> условиях на реальных задачах.
UL>>> Причем основной упор делался на работу с детьми в
UL>>> возрасте 10-12 лет. У них мышление не зашорено
UL>>> никакими предпочтениями и с их помощью можно
UL> четко
UL>>> увидеть какие подходы предпочтительны с точки
UL>>> зрения обучения и эффективности использования
UL>>> человеком.
SZ>> Только - не человеком, а ребенком. И не
UL> реальные проекты, в которых
SZ>> работают реальные люди с большими животами.
UL> Дети дают представление о learning curve и какие
UL> есть затыки при освоении технологии человеком.
UL> А сам язык не дети же писали.
Дети не будут возиться с блокирующими устройствами, как, например, диспенсер
фирмы Сименс, который блокирует выполнение на время выдачи денег клиенту.
Автоматом возникают нитки, возможности дедлока... И все это - в отсутствие
человека, способного разрулить дедлоки и в присутствии клиента, карточка
которого все еще в банкомате.
"Первой моей задачей по окончании колледжа было: прочитать и понять
фортрановскую программу в 100,000 строк и увеличить скорость ее работы в два
раза." (C) Настоящие Программисты Не Используют Паскаль
UL>>> Отсюда видно, что сам процесс создания языка
UL>>> подпадает все под те же принципы ООП -
UL>>> динамическое эволюционное развитие.
SZ>> Прошу ограничить количество принципов.
UL> Перечисли их все заранее.
UL> Ты их уже все слышал. Объект, состояние,
UL> последовательное его изменение, посылка сообщения,
UL> рекурсивный дизайн.
А выше добавилось "динамическое эволюционное развитие". Почему не перечислил?
Обмануть хочешь?
SZ>> Почему? Мы тогда начали сдвигаться с места.
UL> Например, обнаружили,
SZ>> что не только в Smalltalk и Lisp (динамических
UL> языках) есть лямбды.
SZ>> И что одна из сильных сторон Smalltalk именно
UL> в них и заложена.
UL> Да, они дают порядочный кусок эффективности.
UL> Но основное - это непосредственное манипулирование
UL> объектами через посылку сообщений, и хорошие
UL> инструменты которые все это упрощают.
Вот отсюда и начнем. Вот расскажи мне, как ты будешь предотвращать дедлоки в
программе с нитками? (больная тема;)
SZ>>>> Кстати, является ли безымянный блок кода
UL>>> объектом, и какие собщения
SZ>>>> он умеет обрабатывать?
UL>>> Является (в случае Smalltalk этот вопрос
UL> неуместен
UL>>> :-)).
SZ>> Почему? Уместен.
UL> Вспомни его лозунг - в мире нет ничего кроме
UL> объектов. :-)
UL> http://www.whysmalltalk.com/graphics/graphicimages/Smalltalkbaby.jpg
А это бессмысленный лозунг. У каждого объекта (набора взаимодействующих
объектов) есть семантика, и, в конце-концов, именно с ней человек и
взаимодействует. А вовсе не с объектами.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Serguey Zefirov
Wednesday, August 27, 2003, 8:21:49 AM, you wrote:
ANS> UL>> В Squeak вообще интересно сделано - пишешь plugin
ANS> UL>> на Smalltalk, потом прогоняешь его через SLang
ANS> UL>> translator, который генерит C-код, компилируешь,
ANS> UL>> подлинковываешь, и у тебя готов быстрый код
ANS> UL>> нужного алгоритма.
ANS> SZ> Здорово.
ANS> Но есть ограничения на используемые конструкции.
Да это я знаю.
Кстати:
--------------------
Using inlined C code
make sure you have a working gcc (or mingw) setup
get the critlib distribution and unpack [3]
create a test script called "three.tcl" with the following contents:
lappend auto_path .
package require critcl
critcl::cproc triple {int i} int {
return i * 3; /* this is C code */
}
puts "three times 123 is [triple 123]"
run the above script (using tclsh, tclkit, whatever), e.g.
tclkit three.tcl
that's it - you should see the result of compiled C code
--------------------
http://mini.net/tcl/2523
По кульности сравнится? ;)
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Uladzimir Liashkevich
SZ> Hello Uladzimir,
SZ> Wednesday, August 27, 2003, 7:47:09 AM, you wrote:
SZ>>> Простейшее действие - получить программу для
UL>> ADSP2181, точнее, для
SZ>>> EZ-KIT Lite, которая мигает светодиодом с
UL>> полупериодом в секунду.
SZ>>> Каковы ваши действия для выбранной вами "самой
UL>> человечной" платформы?
UL>> Примерно как и везде - взять нужный компилятор
UL>> (еще в 80-х активно использовался Embedded
UL>> Smalltalk - сейчас не в курсе, также имеется
UL>> Pocket Smalltalk), взять нужные либы, написать
UL>> нужный код. Только вот отличие, что в
Smalltalk ты
UL>> мигание светодиода получишь быстрее чем на многих
UL>> других платформах.
SZ> Слабо верится. Причем чем больше ищу, тем слабее.
SZ> Pocket Smalltalk - это для хандхелдов, причем
только для пальмов.
SZ> Embedded Smalltalk - часто это Smalltalk,
встроенный в HTML. Максимум - это
SZ> PIC/Smalltalk.
Точно был Embedded Smalltalk, делала его Tektronix
(оттуда пришли Kent Beck и Ward Cunningham).
Похоже уже кануло в лету.
===
Tektronix was our first customer for embedded
Smalltalk, developed as a joint project between
OTI, Digitalk and Tektronix and the Canadian
Department of National Defense. The shipping of a
family of oscilloscopes was a testimony to the
flexibility of the technology and to the
excellence of the Tektronix engineering team...
===
SZ> Будь добр, дай ссылку поточнее. А пока -
Smalltalk не может работать с
SZ> ADSP2181, даже в качестве кросскомпилятора. И
для простейшей задачи мне
SZ> понадобиться что? Правильно, совершать кучу
ненужных действий. Например,
SZ> пристегивать g21 - gcc для adsp21xx. А у него
код такой, что задержку в
SZ> секунду подобрать вряд ли получится. ;)
Вообще есть принцип use the right tool. И если
Smalltalk им в данной задаче не является, я его не
использую. Но в очень большом количестве задач он
является самым что ни на есть the right tool.
Контрпримеры, есс-но, ничего не доказывают.
UL>> Да пожалуйста. Я также слышал статистику, что
UL>> рынок электронной коммерции равен по объему рынку
UL>> средств увеличения груди. Так что, всем кидать
UL>> свою никчемную сферу деятельности? ;-)
SZ> Знать о том, что существуют другие. Не менее
денежные.
Наслышаны.
UL>>>> В общем было 5 больших итераций создания
UL>> языка, по
UL>>>> годам - 72, 74, 76, 78, 80. Hа каждом этапе
UL>>>> разрабатывался детальный дизайн языка на основе
UL>>>> каких-то предположений и практических
UL>> результатов.
UL>>>> Потом язык проходил тестирование в реальных
UL>>>> условиях на реальных задачах.
UL>>>> Причем основной упор делался на работу с
детьми в
UL>>>> возрасте 10-12 лет. У них мышление не зашорено
UL>>>> никакими предпочтениями и с их помощью можно
UL>> четко
UL>>>> увидеть какие подходы предпочтительны с точки
UL>>>> зрения обучения и эффективности использования
UL>>>> человеком.
SZ>>> Только - не человеком, а ребенком. И не
UL>> реальные проекты, в которых
SZ>>> работают реальные люди с большими животами.
UL>> Дети дают представление о learning curve и какие
UL>> есть затыки при освоении технологии человеком.
UL>> А сам язык не дети же писали.
SZ> Дети не будут возиться с блокирующими
устройствами, как, например, диспенсер
SZ> фирмы Сименс, который блокирует выполнение на
время выдачи денег клиенту.
SZ> Автоматом возникают нитки, возможности
дедлока... И все это - в отсутствие
SZ> человека, способного разрулить дедлоки и в
присутствии клиента, карточка
SZ> которого все еще в банкомате.
Принцип use the right tool работает везде. Если уж
выбирать какую-то мифическую область, то нужно
искать средство, где есть хотя бы базовые вещи,
решающие задачу. Даже если это Fortran или Cobol.
А если брать http, servlets, web services,
databases и прочую попсу, то уже критерий отбора
другой - тут уже можно разговаривать о
продуктивности языков.
SZ> "Первой моей задачей по окончании колледжа
было: прочитать и понять
SZ> фортрановскую программу в 100,000 строк и
увеличить скорость ее работы в два
SZ> раза." (C) Настоящие Программисты Не
Используют Паскаль
UL>>>> Отсюда видно, что сам процесс создания языка
UL>>>> подпадает все под те же принципы ООП -
UL>>>> динамическое эволюционное развитие.
SZ>>> Прошу ограничить количество принципов.
UL>> Перечисли их все заранее.
UL>> Ты их уже все слышал. Объект, состояние,
UL>> последовательное его изменение, посылка
сообщения,
UL>> рекурсивный дизайн.
SZ> А выше добавилось "динамическое эволюционное
развитие". Почему не перечислил?
SZ> Обмануть хочешь?
Динамическое - очевидное следствие того, что
объекту можно послать любое сообщение, а он сам
решает как ему быть.
Таким образом можно систему можно динамически
подвергать последовательным изменениям для
достижения нужно результата - вот и эволюционное
развитие.
SZ>>> Почему? Мы тогда начали сдвигаться с места.
UL>> Например, обнаружили,
SZ>>> что не только в Smalltalk и Lisp (динамических
UL>> языках) есть лямбды.
SZ>>> И что одна из сильных сторон Smalltalk именно
UL>> в них и заложена.
UL>> Да, они дают порядочный кусок эффективности.
UL>> Но основное - это непосредственное
манипулирование
UL>> объектами через посылку сообщений, и хорошие
UL>> инструменты которые все это упрощают.
SZ> Вот отсюда и начнем. Вот расскажи мне, как ты
будешь предотвращать дедлоки в
SZ> программе с нитками? (больная тема;)
Это уже проблема concurrent programming, что
ортогонально ОО. Смотри Erlang. ;-)
SZ>>>>> Кстати, является ли безымянный блок кода
UL>>>> объектом, и какие собщения
SZ>>>>> он умеет обрабатывать?
UL>>>> Является (в случае Smalltalk этот вопрос
UL>> неуместен
UL>>>> :-)).
SZ>>> Почему? Уместен.
UL>> Вспомни его лозунг - в мире нет ничего кроме
UL>> объектов. :-)
UL>>
http://www.whysmalltalk.com/graphics/graphicimages/Smalltalkbaby.jpg
SZ> А это бессмысленный лозунг. У каждого объекта
(набора взаимодействующих
SZ> объектов) есть семантика, и, в конце-концов,
именно с ней человек и
SZ> взаимодействует. А вовсе не с объектами.
Абсолютно верно. В ОО нет никакой конкретной
семантики (кроме посылки сообщения). Оно только
задает способ построения.
Как тебе уже как-то рассказывали, с помощью
операции посылки сообщения можно задавать
различную семантику.
Хоть реляционную алгебру в случае с OR-mapping.
И в этой гибкости вся ее мощь.
--
Владимир.
Serguey Zefirov
Wednesday, August 27, 2003, 10:31:34 AM, you wrote:
SZ>> Слабо верится. Причем чем больше ищу, тем слабее.
SZ>> Pocket Smalltalk - это для хандхелдов, причем
UL> только для пальмов.
SZ>> Embedded Smalltalk - часто это Smalltalk,
UL> встроенный в HTML. Максимум - это
SZ>> PIC/Smalltalk.
UL> Точно был Embedded Smalltalk, делала его Tektronix
UL> (оттуда пришли Kent Beck и Ward Cunningham).
UL> Похоже уже кануло в лету.
Значит, это не райт тул для этих задач.
SZ>> Будь добр, дай ссылку поточнее. А пока -
UL> Smalltalk не может работать с
SZ>> ADSP2181, даже в качестве кросскомпилятора. И
UL> для простейшей задачи мне
SZ>> понадобиться что? Правильно, совершать кучу
UL> ненужных действий. Например,
SZ>> пристегивать g21 - gcc для adsp21xx. А у него
UL> код такой, что задержку в
SZ>> секунду подобрать вряд ли получится. ;)
UL> Вообще есть принцип use the right tool. И если
UL> Smalltalk им в данной задаче не является, я его не
UL> использую. Но в очень большом количестве задач он
UL> является самым что ни на есть the right tool.
UL> Контрпримеры, есс-но, ничего не доказывают.
Заявление было что Smalltalk - технология с человеческим лицом, причем без
указания области применения.
Контрпримеры позволяют очертить границы области, где технология еще сохраняет
свое лицо.
Но все технологии делаются для людей. Даже технологии фирмы Rational.
UL>>>>> В общем было 5 больших итераций создания
UL>>> языка, по
UL>>>>> годам - 72, 74, 76, 78, 80. Hа каждом этапе
UL>>>>> разрабатывался детальный дизайн языка на основе
UL>>>>> каких-то предположений и практических
UL>>> результатов.
UL>>>>> Потом язык проходил тестирование в реальных
UL>>>>> условиях на реальных задачах.
UL>>>>> Причем основной упор делался на работу с
UL> детьми в
UL>>>>> возрасте 10-12 лет. У них мышление не зашорено
UL>>>>> никакими предпочтениями и с их помощью можно
UL>>> четко
UL>>>>> увидеть какие подходы предпочтительны с точки
UL>>>>> зрения обучения и эффективности использования
UL>>>>> человеком.
SZ>>>> Только - не человеком, а ребенком. И не
UL>>> реальные проекты, в которых
SZ>>>> работают реальные люди с большими животами.
UL>>> Дети дают представление о learning curve и какие
UL>>> есть затыки при освоении технологии человеком.
UL>>> А сам язык не дети же писали.
SZ>> Дети не будут возиться с блокирующими
UL> устройствами, как, например, диспенсер
SZ>> фирмы Сименс, который блокирует выполнение на
UL> время выдачи денег клиенту.
SZ>> Автоматом возникают нитки, возможности
UL> дедлока... И все это - в отсутствие
SZ>> человека, способного разрулить дедлоки и в
UL> присутствии клиента, карточка
SZ>> которого все еще в банкомате.
UL> Принцип use the right tool работает везде. Если уж
UL> выбирать какую-то мифическую область, то нужно
UL> искать средство, где есть хотя бы базовые вещи,
UL> решающие задачу. Даже если это Fortran или Cobol.
UL> А если брать http, servlets, web services,
UL> databases и прочую попсу, то уже критерий отбора
UL> другой - тут уже можно разговаривать о
UL> продуктивности языков.
Забавный перекос.
SZ>>>> Прошу ограничить количество принципов.
UL>>> Перечисли их все заранее.
UL>>> Ты их уже все слышал. Объект, состояние,
UL>>> последовательное его изменение, посылка
UL> сообщения,
UL>>> рекурсивный дизайн.
SZ>> А выше добавилось "динамическое эволюционное
UL> развитие". Почему не перечислил?
SZ>> Обмануть хочешь?
UL> Динамическое - очевидное следствие того, что
UL> объекту можно послать любое сообщение, а он сам
UL> решает как ему быть.
UL> Таким образом можно систему можно динамически
UL> подвергать последовательным изменениям для
UL> достижения нужно результата - вот и эволюционное
UL> развитие.
А, так это следствие. А было дадено, как принцип.
SZ>> Вот отсюда и начнем. Вот расскажи мне, как ты
UL> будешь предотвращать дедлоки в
SZ>> программе с нитками? (больная тема;)
UL> Это уже проблема concurrent programming, что
UL> ортогонально ОО. Смотри Erlang. ;-)
Нет уж. Как, воспользовавшись всей мощью посылки сообщений, ты будешь
предотвращать дедлоки?
SZ>>>>>> Кстати, является ли безымянный блок кода
UL>>>>> объектом, и какие собщения
SZ>>>>>> он умеет обрабатывать?
UL>>>>> Является (в случае Smalltalk этот вопрос
UL>>> неуместен
UL>>>>> :-)).
SZ>>>> Почему? Уместен.
UL>>> Вспомни его лозунг - в мире нет ничего кроме
UL>>> объектов. :-)
UL>>>
UL> http://www.whysmalltalk.com/graphics/graphicimages/Smalltalkbaby.jpg
SZ>> А это бессмысленный лозунг. У каждого объекта
UL> (набора взаимодействующих
SZ>> объектов) есть семантика, и, в конце-концов,
UL> именно с ней человек и
SZ>> взаимодействует. А вовсе не с объектами.
UL> Абсолютно верно. В ОО нет никакой конкретной
UL> семантики (кроме посылки сообщения). Оно только
UL> задает способ построения.
Вообще-то, должны быть константы для какой-то базы.
UL> Как тебе уже как-то рассказывали, с помощью
UL> операции посылки сообщения можно задавать
UL> различную семантику.
Замечательно. Как указать, что при синхронном вызове нитки A из нитки B оная
нитка А не должна вызывать нитку B?
UL> Хоть реляционную алгебру в случае с OR-mapping.
UL> И в этой гибкости вся ее мощь.
Это-то не беда, что мощно. Беда в том, что непонятно, что с этой мощностью
делать, как с ней обращаться.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N. Sobchuck
SZ> PIC/Smalltalk.
http://wiki.eranova.si/esug/OOVM
--
Андрей Собчук
and...@itware.com.ua
Alexander Kobets
"Serguey Zefirov" <s...@uc.ru> сообщил следующее:
...
> UL> Хоть реляционную алгебру в случае с OR-mapping.
> UL> И в этой гибкости вся ее мощь.
>
> Это-то не беда, что мощно. Беда в том, что непонятно, что с этой мощностью
> делать, как с ней обращаться.
Доходчиво это объяснено в книге Гради Буч "Объектно-ориентированный анализ и
проектирование с примерами приложений на С++"
Пока.
--
Serguey Zefirov
Thursday, August 28, 2003, 1:29:10 AM, you wrote:
>> UL> Хоть реляционную алгебру в случае с OR-mapping.
>> UL> И в этой гибкости вся ее мощь.
>>
>> Это-то не беда, что мощно. Беда в том, что непонятно, что с этой мощностью
>> делать, как с ней обращаться.
AK> Доходчиво это объяснено в книге Гради Буч "Объектно-ориентированный анализ и
AK> проектирование с примерами приложений на С++"
C++ - не объектно-ориентированый язык. Это я уже выучил.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Serguey Zefirov
Thursday, August 28, 2003, 1:22:30 AM, you wrote:
ANS> Serguey Zefirov <s...@uc.ru> wrote:
ANS> SZ> PIC/Smalltalk.
ANS> http://wiki.eranova.si/esug/OOVM
Нет.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Nick Ivanych Kovaliov
> http://www.whysmalltalk.com/graphics/graphicimages/Smalltalkbaby.jpg
Кроме объектов и морфизмов между ними ;))
"Everithing is a category, if you look enough long".
Вот только что бы сказал ребёнок ...
До встречи, всего наилучшего !
Alexander Kobets
анализ и
> AK> проектирование с примерами приложений на С++"
>
> C++ - не объектно-ориентированый язык. Это я уже выучил.
Там не про C++.
Пока.
--
Vadim Radionov
28 авг 03 10:33, Serguey Zefirov wrote to Uladzimir Liashkevich:
UL>> Как тебе уже как-то рассказывали, с помощью
UL>> операции посылки сообщения можно задавать
UL>> различную семантику.
SZ> Замечательно. Как указать, что при синхронном вызове нитки A из нитки B
SZ> оная нитка А не должна вызывать нитку B?
Кстати, я когда-то делал рекурсию между двумя процессами без дедлока.
Это я к тому, что меры предотвращения от дедлока не обязательно должны
запрещать
рекурсию между нитями/процессами.
Vadim
Nikita V. Belenki
>> Можно реализовать с успехом любые алгоритмы
>> работающие с битами. Integer>>bitAnd: и прочее у
>> тебя в наличии.
VM> Я же говорил - битовые операции есть, а битов нет.
То есть как это "нет"? А что же именно тогда делают битовые операции?
Hет объектов "бит", а сами биты вполне есть.
VM> Он ведь не это просит, а чтобы число было коллекцией битов, биты были
VM> объектами и им можно было посылать сообщения и т.д., и чтобы впридачу
VM> это было быстро. В противном случае ОО (ST)-подход
VM> объявляется негодным по эффективности.
Я так понял, что он просил либо предъявить, как с битами в ST можно работать
как с объектами (посылая им сообщения и добавляя их в коллекции), либо
перестать одновременно утверждать, что ОО-язык -- это тот, в котором всё --
объекты, и что ST -- это ОО-язык.
Kit.
Andrei N. Sobchuck
NVB> Я так понял, что он просил либо предъявить, как с битами в ST можно работать
NVB> как с объектами (посылая им сообщения и добавляя их в коллекции), либо
Достаточным ли будет добавление поддержки интерфейса коллекций к классу Целых
и добавление класса Бит?
NVB> перестать одновременно утверждать, что ОО-язык -- это тот, в котором всё --
Всё - это широкое понятие. Чем ограничевается твоё "всё"?
NVB> объекты, и что ST -- это ОО-язык.
--
Андрей Собчук
and...@itware.com.ua
Serguey Zefirov
Thursday, August 28, 2003, 4:43:44 AM, you wrote:
ANS> NVB> Я так понял, что он просил либо предъявить, как с битами в ST можно работать
ANS> NVB> как с объектами (посылая им сообщения и добавляя их в коллекции), либо
ANS> Достаточным ли будет добавление поддержки интерфейса коллекций к классу Целых
ANS> и добавление класса Бит?
Да, это будет достаточным.
ANS> NVB> перестать одновременно утверждать, что ОО-язык -- это тот, в котором всё --
ANS> Всё - это широкое понятие. Чем ограничевается твоё "всё"?
Вот. Вот уже опять ограничения. ;)
ANS> NVB> объекты, и что ST -- это ОО-язык.
--
Best regards,
Serguey mailto:s...@uc.ru
PS
- А какие сообщения принимают команды виртуальной машины? - продолжал
глумиться Сергей Зефиров.
Andrei N. Sobchuck
ANS>> Достаточным ли будет добавление поддержки интерфейса коллекций к классу Целых
ANS>> и добавление класса Бит?
SZ> Да, это будет достаточным.
Так это возможно. Демонстрировать? Как?
Кстати, а с чего ты взял, что это невозможно?
ANS>> NVB> перестать одновременно утверждать, что ОО-язык -- это тот, в котором всё --
ANS>> Всё - это широкое понятие. Чем ограничевается твоё "всё"?
SZ> Вот. Вот уже опять ограничения. ;)
Я тебя огорошу - в *VW* ST нету не то что битов, там нет и байтов!
И машинных слов нету. Нету так же и слов в обиходном смысле.
Нет предложений, и, вообще, там много чего нет.
Точнее нет классов, которые всё это представляют. Но ничто не мешает эти
классы при необходимости добавить.
--
Андрей Собчук
and...@itware.com.ua
Nikita V. Belenki
NVB>> Я так понял, что он просил либо предъявить, как с битами в ST можно
NVB>> работать как с объектами (посылая им сообщения и добавляя их в
NVB>> коллекции), либо
ANS> Достаточным ли будет добавление поддержки интерфейса коллекций к классу
ANS> Целых и добавление класса Бит?
По вопросу "необъектности" конкретно битов -- видимо, да.
NVB>> перестать одновременно утверждать, что ОО-язык -- это тот, в котором
NVB>> всё --
ANS> Всё - это широкое понятие. Чем ограничевается твоё "всё"?
Это не моё "всё". Это "всё" тех, кто пытается определить "ОО-язык". Если они
хотят его как-то ограничить -- пусть расскажут.
Kit.
Victor Metelitsa
Nikita V. Belenki wrote:
> Wed Aug 27 2003 15:48, Victor Metelitsa wrote to Uladzimir Liashkevich:
>
> >> Можно реализовать с успехом любые алгоритмы
> >> работающие с битами. Integer>>bitAnd: и прочее у
> >> тебя в наличии.
> VM> Я же говорил - битовые операции есть, а битов нет.
>
> То есть как это "нет"? А что же именно тогда делают битовые операции?
>
> Hет объектов "бит", а сами биты вполне есть.
Не знаю ни про какие биты. Например,
1 bitAnd: 1 вернет 1,
1 bitAnd: 2 вернет 0,
1 bitAnd: 3 вернет 1 и так далее. Вы скажете, что это работа с битами? А
я скажу, "нет, это просто работа с неким алгоритмом, использующим
остатки от деления". Или "нет, это результат просмотра справочника, где
(1 1) соотв. 1, (1 2) соотв. 0 и так далее".
Иными словами, нет необходимости прибегать к понятию бита для
мспользования этих операций.
Конечно, понятие бита в ST можно ввести, а collection protocol на
Integer навернуть. И не только теоретически, но и реально, без особых
проблем, и, скорее всего, на любом диалекте. Вот только возведение в
степень (очевидно, оптимизированное для натуральных чисел в натуральную
степень), использующее это, по скорости (по сравнению с C-решением)
наверняка будет плохо. Но низменные вещи пусть идут в VM, там им самое
место.
--
Serguey Zefirov
Thursday, August 28, 2003, 5:16:53 AM, you wrote:
ANS>>> Достаточным ли будет добавление поддержки интерфейса коллекций к классу Целых
ANS>>> и добавление класса Бит?
ANS> SZ> Да, это будет достаточным.
ANS> Так это возможно. Демонстрировать? Как?
ANS> Кстати, а с чего ты взял, что это невозможно?
Да возможно, возможно. Другое дело, что оверхед будет - мама не горюй.
ANS>>> NVB> перестать одновременно утверждать, что ОО-язык -- это тот, в котором всё --
ANS>>> Всё - это широкое понятие. Чем ограничевается твоё "всё"?
ANS> SZ> Вот. Вот уже опять ограничения. ;)
ANS> Я тебя огорошу - в *VW* ST нету не то что битов, там нет и байтов!
ANS> И машинных слов нету. Нету так же и слов в обиходном смысле.
ANS> Нет предложений, и, вообще, там много чего нет.
ANS> Точнее нет классов, которые всё это представляют. Но ничто не мешает эти
ANS> классы при необходимости добавить.
Замечательно. А что с этими классами делать?
Мне на данный момент не очень симпатична идея, что вы хвастаетесь возможностью
_неограниченного_ создания, тогда, как в обычной работе желательно _вводить
полезные ограничения_, и, затем, автоматически их _поддерживать_. Например,
надо уметь запрещать (в идеале) дедлок при взаимных синхронных передачах
сообщений между процессами. Желательно - до запуска программы.
Хотя - можно жить и так. И современное состояние дел именно такое.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Alexander Kobets
Сам просил.
> Мне на данный момент не очень симпатична идея, что вы хвастаетесь
возможностью
> _неограниченного_ создания, тогда, как в обычной работе желательно
_вводить
> полезные ограничения_, и, затем, автоматически их _поддерживать_.
Например,
> надо уметь запрещать (в идеале) дедлок при взаимных синхронных передачах
> сообщений между процессами. Желательно - до запуска программы.
>
> Хотя - можно жить и так. И современное состояние дел именно такое.
Это ты описываешь С++ вариант, где ОО является только лишь концепцией. Ни
кто не мешает сделать и использовать ОО языки с поддержкой синхронизации
взаимодействия. К стати - Single Threaded COM объект, самое то.
Пока.
--
Nikita V. Belenki
>> >> Можно реализовать с успехом любые алгоритмы
>> >> работающие с битами. Integer>>bitAnd: и прочее у
>> >> тебя в наличии.
>> VM> Я же говорил - битовые операции есть, а битов нет.
>> То есть как это "нет"? А что же именно тогда делают битовые операции?
>> Hет объектов "бит", а сами биты вполне есть.
VM> Hе знаю ни про какие биты. Hапример,
VM> 1 bitAnd: 1 вернет 1,
VM> 1 bitAnd: 2 вернет 0,
VM> 1 bitAnd: 3 вернет 1 и так далее.
VM> Вы скажете, что это работа с битами? А
VM> я скажу, "нет, это просто работа с неким алгоритмом, использующим
VM> остатки от деления". Или "нет, это результат просмотра справочника, где
VM> (1 1) соотв. 1, (1 2) соотв. 0 и так далее".
Ага. А программа на языке Си -- это просто сообщение, посылаемое объекту
"компилятор". Вывод: Си -- чистый ОО-язык?
VM> Иными словами, нет необходимости прибегать к понятию бита для
VM> мспользования этих операций.
Отнюдь. Выше ты ни слова не сказал об _использовании_ этих операций. А для
использования надо знать, чем именно отличается "a bitOr: b" от "a bitXor b",
и что именно возвращает "a bitAt: n" (и как это связано с возвращаемым "a at:
m").
Kit.
Andrei N. Sobchuck
SZ> Мне на данный момент не очень симпатична идея, что вы хвастаетесь возможностью
SZ> _неограниченного_ создания, тогда, как в обычной работе желательно _вводить
SZ> полезные ограничения_, и, затем, автоматически их _поддерживать_. Например,
SZ> надо уметь запрещать (в идеале) дедлок при взаимных синхронных передачах
SZ> сообщений между процессами. Желательно - до запуска программы.
А где это возможно (я про дедлок)?
Во-вторых, ограничения то не должны мешать.
Кстати, а ты не знаешь какое было обоснование создать Erlang именно с
динамической типизацией?
--
Андрей Собчук
and...@itware.com.ua
Andrei N. Sobchuck
NVB> "компилятор". Вывод: Си -- чистый ОО-язык?
Нет. Вывод мир - это объектная система ;)
--
Андрей Собчук
and...@itware.com.ua
Nick Ivanych Kovaliov
> создать Erlang именно с динамической типизацией ?
Тоже очень интересно.
Где-то либо у этой эхе, либо в ru.programming.languages
кто-то говорил, что разработчики жалеют,
что сделали типизацию динамической.
Но вот ссылок там, вроде, не было.
И кто это сообщил, не помню.
Откликнитесь, кто такое сказал ! ;)
Alexey Desyatnik
28 авг 03 17:23, Andrei N. Sobchuck стучал(а) по клавишам для "Nikita V.
Belenki":
NVB>> Ага. А программа на языке Си -- это просто сообщение, посылаемое
NVB>> объекту "компилятор". Вывод: Си -- чистый ОО-язык?
AS> Hет. Вывод мир - это объектная система ;)
Поспешишь - людей насмешишь ;)
Мир _можно_ рассматривать как объектную систему. Что характерно, о
_возможности_ никто и не спорит. Вопрос в целесообразности такого подхода в
целом и в каждом конкретном случае. Область применимости, в общем.
WBR, AD
... Это вам не ежиков лохматить...
Anton Moscal
You wrote to Andrei N. Sobchuck on Fri, 29 Aug 2003 06:42:31 +0000 (UTC):
NIK> Где-то либо у этой эхе, либо в ru.programming.languages
NIK> кто-то говорил, что разработчики жалеют,
NIK> что сделали типизацию динамической.
NIK> Но вот ссылок там, вроде, не было.
NIK> И кто это сообщил, не помню.
NIK> Откликнитесь, кто такое сказал ! ;)
Я когда-то говорил. Я в какой-то из статей разработчиков это читал (кажется
в Development of Erlang)
Я прошу прощения, что в эхе, но твой сервер пал жертвой идиотской затеи
osirussoft'a (они закрыли свой blacklist весьма оригинальным способом -
занеся туда все адреса)
---------------------------------------
<Ni...@ivanych.com>: host ivanych.com[195.12.74.98] said: 591 your host
[195.9.10.14] is blacklisted by inputs.relays.osirusoft.com. Send your
questions to blackli...@urm.ru
-----------------------------
Anton
Denis Fedotov
Tue, 26 Aug 2003 20:33:59 +0600, Sergey P. Derevyago писал к Anton
Moscal:
SPD> Anton Moscal wrote:
>> конфликтов имен - там где С++ предлгает правило разрешения
>> конфликта, авторы Haskell препочитают считать это ошибкой)
SPD> Можно содержательный пример?
Там всё просто как плинтус, как я понимаю. ad-hoc полиморфизм
называется. Если
компилятор видит a+b, то на типы a и b как-бы накладывается ограничение,
что они должны "реализовывать" Num. В с++ это ИМХО называется словом
"концепция". Я немного поимпровизирую - набросок функции Int add(Int&
a,Int& b):
template <class T>
struct TypeClass
{};
struct Num
{
template <class T> static T add(T&,T&);
typedef int implementsNum;
};
template <class T>
T add(T& a, T& b)
{
typedef typename T::TypeClass::implementsNum check;
return T::TypeClass::add(a,b);
}
struct Int
{
int val;
typedef TypeClass<Int> TypeClass;
};
template <>
struct TypeClass<Int> : Num
{
static Int add(Int& a, Int& b)
{Int ret; ret.val=a.val+b.val; return ret;}
};
int main(int argc, char* argv[])
{
Int a; a.val=1;
Int b; b.val=1;
Int c = add(a,b);
printf("%i",c.val);
}
Denis.
Vadim Radionov
31 авг 03 16:52, Denis Fedotov wrote to Sergey P. Derevyago:
SPD>> Anton Moscal wrote:
>>> конфликтов имен - там где С++ предлгает правило разрешения
>>> конфликта, авторы Haskell препочитают считать это ошибкой)
SPD>> Можно содержательный пример?
DF> Там всё просто как плинтус, как я понимаю. ad-hoc полиморфизм
DF> называется. Если
DF> компилятор видит a+b, то на типы a и b как-бы накладывается ограничение,
DF> что они должны "реализовывать" Num. В с++ это ИМХО называется словом
DF> "концепция".
И правда, ты все упростил. Hо там несколько сложнее:
class (Eq a, Show a) => Num a where
...
Т.е. Если 'a' число, то она также относится к классам Eq и Show.
DF> struct Int
DF> {
DF> int val;
DF> typedef TypeClass<Int> TypeClass;
DF> };
Вот и отрази этот факт, например, c помощью TypeList (a-la Loki от
Александреску) ;)
А потом еще изобрази аналог следующей штучки:
class (Show a) => Show (Tree a) where
...
Расшифровывается это так:
Если 'a' можно изобразить (напечетать), то и (Tree a) тоже можно напечатать.
Vadim
Victor Metelitsa
Nikita V. Belenki wrote:
[...]
>
> VM> Иными словами, нет необходимости прибегать к понятию бита для
> VM> мспользования этих операций.
>
> Отнюдь. Выше ты ни слова не сказал об _использовании_ этих операций. А для
> использования надо знать, чем именно отличается "a bitOr: b" от "a bitXor b",
> и что именно возвращает "a bitAt: n" (и как это связано с возвращаемым "a at:
> m").
Такие вопросы постоянно возникают, когда мы работаем со внешним миром.
Виджеты, файловая система, sql-сервера... Напр., ST посылает sql-серверу
строчку с 'UPDATE someTable SET ...', тот что-то делает и возвращает
какой-то результат (код ошибки, число измененных строк...). ST и знать
не знает, что произошло, и чем 'UPDATE someTable ...' отличается от
'DELETE someTable...', и таблица как объект для него не существует. Про
таблицу и смысл запросов знает sql-сервер. ST послал сообщение, получил
ответ. Таким же образом отнесемся и к битам - это чужое (а лучше
битовых операций вообще не было бы; как и sql-серверов ;-) ).
Uladzimir Liashkevich
SZ> Hello Andrei,
SZ> Thursday, August 28, 2003, 5:16:53 AM, you wrote:
SZ> ANS>>> Достаточным ли будет добавление
поддержки интерфейса коллекций к классу Целых
SZ> ANS>>> и добавление класса Бит?
SZ> ANS> SZ> Да, это будет достаточным.
SZ> ANS> Так это возможно. Демонстрировать? Как?
SZ> ANS> Кстати, а с чего ты взял, что это невозможно?
SZ> Да возможно, возможно. Другое дело, что
оверхед будет - мама не горюй.
Из опыта таких дискуссий могу сказать, что в 90%
случаев все сводится к - но это будет медленно. :-)
SZ> ANS>>> NVB> перестать одновременно
утверждать, что ОО-язык -- это тот, в котором всё --
SZ> ANS>>> Всё - это широкое понятие. Чем
ограничевается твоё "всё"?
SZ> ANS> SZ> Вот. Вот уже опять ограничения. ;)
SZ> ANS> Я тебя огорошу - в *VW* ST нету не то что
битов, там нет и байтов!
SZ> ANS> И машинных слов нету. Нету так же и слов
в обиходном смысле.
SZ> ANS> Нет предложений, и, вообще, там много
чего нет.
SZ> ANS> Точнее нет классов, которые всё это
представляют. Но ничто не мешает эти
SZ> ANS> классы при необходимости добавить.
SZ> Замечательно. А что с этими классами делать?
SZ> Мне на данный момент не очень симпатична идея,
что вы хвастаетесь возможностью
SZ> _неограниченного_ создания, тогда, как в
обычной работе желательно _вводить
SZ> полезные ограничения_, и, затем, автоматически
их _поддерживать_. Например,
SZ> надо уметь запрещать (в идеале) дедлок при
взаимных синхронных передачах
SZ> сообщений между процессами. Желательно - до
запуска программы.
Скажем так проверка "до запуска" это не совсем
объектный подход. Объектная программа до запуска
как бы и не существует. Там сплошной рантайм. И
целью является адаптивность и возможность быстрого
восстановления. Соответственно и методы там
динамические - например контекст выполнения тащит
список, куда ему запрещено делать синхронные
вызовы. При конфликте ловится традиционное
исключение и разруливается на этапе тестирования.
В некоторых случаях проверку "до запуска" можно
попытаться получить с помощью глобальных
типо-выводителей и верификаторов, но видимо кому
это действительно нужно сидят в статическом мире,
поэтому эти методы не развиваются.
SZ> Хотя - можно жить и так. И современное
состояние дел именно такое.
--
Владимир.
Nikita V. Belenki
>> VM> Иными словами, нет необходимости прибегать к понятию бита для
>> VM> мспользования этих операций.
>> Отнюдь. Выше ты ни слова не сказал об _использовании_ этих операций. А для
>> использования надо знать, чем именно отличается "a bitOr: b" от "a bitXor
>> b", и что именно возвращает "a bitAt: n" (и как это связано с
>> возвращаемым "a at: m").
VM> Такие вопросы постоянно возникают, когда мы работаем со внешним миром.
VM> Виджеты, файловая система, sql-сервера... Hапр., ST посылает sql-серверу
VM> строчку с 'UPDATE someTable SET ...', тот что-то делает и возвращает
VM> какой-то результат (код ошибки, число измененных строк...). ST и знать
VM> не знает, что произошло, и чем 'UPDATE someTable ...' отличается от
VM> 'DELETE someTable...', и таблица как объект для него не существует. Про
VM> таблицу и смысл запросов знает sql-сервер. ST послал сообщение, получил
VM> ответ. Таким же образом отнесемся и к битам - это чужое (а лучше
VM> битовых операций вообще не было бы; как и sql-серверов ;-) ).
Hу то есть ты согласен, что любой язык можно назвать ОО, если всё, что не
вписывается в объекты и сообщения, обозвать "внешним миром" (как биты в ST)?
Kit.
Vadim Radionov
01 сен 03 08:42, I wrote to you:
VR> А потом еще изобрази аналог следующей штучки:
VR> class (Show a) => Show (Tree a) where
В смысле ^^^^^ instance
VR> Расшифровывается это так:
VR> Если 'a' можно изобразить (напечетать), то и (Tree a) тоже можно
VR> напечатать.
Vadim
Serguey Zefirov
Thursday, August 28, 2003, 6:34:02 AM, you wrote:
AK> ...
>> Замечательно. А что с этими классами делать?
AK> Сам просил.
Грешен. Каюсь.
>> Мне на данный момент не очень симпатична идея, что вы хвастаетесь
AK> возможностью
>> _неограниченного_ создания, тогда, как в обычной работе желательно
AK> _вводить
>> полезные ограничения_, и, затем, автоматически их _поддерживать_.
AK> Например,
>> надо уметь запрещать (в идеале) дедлок при взаимных синхронных передачах
>> сообщений между процессами. Желательно - до запуска программы.
>>
>> Хотя - можно жить и так. И современное состояние дел именно такое.
AK> Это ты описываешь С++ вариант, где ОО является только лишь концепцией.
В Smalltalk - тоже самое.
AK> К стати - Single Threaded COM объект, самое то.
Шо це такэ? (sorry my humble spelling)
Еслия правильно понимаю, то эта штука сообщения принимает асинхронно. А мне
надо синхронно.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Serguey Zefirov
Thursday, August 28, 2003, 7:22:33 AM, you wrote:
ANS> Serguey Zefirov <s...@uc.ru> wrote:
ANS> SZ> Мне на данный момент не очень симпатична идея, что вы хвастаетесь возможностью
ANS> SZ> _неограниченного_ создания, тогда, как в обычной работе желательно _вводить
ANS> SZ> полезные ограничения_, и, затем, автоматически их _поддерживать_. Например,
ANS> SZ> надо уметь запрещать (в идеале) дедлок при взаимных синхронных передачах
ANS> SZ> сообщений между процессами. Желательно - до запуска программы.
ANS> А где это возможно (я про дедлок)?
CQual.
Many abstract interfaces have implicit requirements about the state in which
certain functions can be called. For example, if a function that acquires lock
l is called twice in a particular thread without an intervening call to
release l, a deadlock will result. We can find this kind of potential deadlock
by adding locked and unlocked qualifiers to record the last action on a lock
within a single thread. Using this technique we found several potential
deadlocks in the Linux kernel, including deadlocks spread across multiple
function invocations.
http://www.cs.berkeley.edu/~jfoster/cqual/
Экспериментировали на довольно большой кошке - ядре линукса.
ANS> Во-вторых, ограничения то не должны мешать.
ANS> Кстати, а ты не знаешь какое было обоснование создать Erlang именно с
ANS> динамической типизацией?
Erlang начинался как еще один Пролог - был написан на Прологе, и синтаксис
имел Прологовский. А потом им стало лень, насколько я понимаю. ;)
Serguey Zefirov
Thursday, August 28, 2003, 7:23:04 AM, you wrote:
ANS> Nikita V. Belenki <fi...@kits.net> wrote:
ANS> NVB> Ага. А программа на языке Си -- это просто сообщение, посылаемое объекту
ANS> NVB> "компилятор". Вывод: Си -- чистый ОО-язык?
ANS> Нет. Вывод мир - это объектная система ;)
Smalltalk - это квантовая система, где принципиально все взаимодействуют со
всеми. Опровергнешь?
--
Best regards,
Serguey mailto:s...@uc.ru
PS
К стати. (C) Что такое "вывод мир"?
Serguey Zefirov
Monday, September 01, 2003, 1:41:01 AM, you wrote:
SZ>> Да возможно, возможно. Другое дело, что
UL> оверхед будет - мама не горюй.
UL> Из опыта таких дискуссий могу сказать, что в 90%
UL> случаев все сводится к - но это будет медленно. :-)
А что ты хотел? Ты же не решаешь все проблемы через SAT решатель, который
может почти все, но очень долго.
SZ>> ANS>>> NVB> перестать одновременно
UL> утверждать, что ОО-язык -- это тот, в котором всё --
SZ>> ANS>>> Всё - это широкое понятие. Чем
UL> ограничевается твоё "всё"?
SZ>> ANS> SZ> Вот. Вот уже опять ограничения. ;)
SZ>> ANS> Я тебя огорошу - в *VW* ST нету не то что
UL> битов, там нет и байтов!
SZ>> ANS> И машинных слов нету. Нету так же и слов
UL> в обиходном смысле.
SZ>> ANS> Нет предложений, и, вообще, там много
UL> чего нет.
SZ>> ANS> Точнее нет классов, которые всё это
UL> представляют. Но ничто не мешает эти
SZ>> ANS> классы при необходимости добавить.
SZ>> Замечательно. А что с этими классами делать?
SZ>> Мне на данный момент не очень симпатична идея,
UL> что вы хвастаетесь возможностью
SZ>> _неограниченного_ создания, тогда, как в
UL> обычной работе желательно _вводить
SZ>> полезные ограничения_, и, затем, автоматически
UL> их _поддерживать_. Например,
SZ>> надо уметь запрещать (в идеале) дедлок при
UL> взаимных синхронных передачах
SZ>> сообщений между процессами. Желательно - до
UL> запуска программы.
UL> Скажем так проверка "до запуска" это не совсем
UL> объектный подход.
Это сказал ты, или Alan Kay?
UL> Объектная программа до запуска
UL> как бы и не существует. Там сплошной рантайм. И
UL> целью является адаптивность и возможность быстрого
UL> восстановления.
При этом выполнение поставленых целей, похоже, никого не интересует.
Типа:
- Да у тебя на твоем клоне Quake на St FPS 3.14!!!
- Зато, ты бы видел, как он быстро восстанавливается после падения!
UL> Соответственно и методы там
UL> динамические - например контекст выполнения тащит
UL> список, куда ему запрещено делать синхронные
UL> вызовы. При конфликте ловится традиционное
UL> исключение и разруливается на этапе тестирования.
UL> В некоторых случаях проверку "до запуска" можно
UL> попытаться получить с помощью глобальных
UL> типо-выводителей и верификаторов, но видимо кому
UL> это действительно нужно сидят в статическом мире,
UL> поэтому эти методы не развиваются.
Пример?
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N. Sobchuck
SZ> Smalltalk - это квантовая система, где принципиально все взаимодействуют со
SZ> всеми. Опровергнешь?
Там нет концепции кванта ;)
--
Андрей Собчук
and...@itware.com.ua
Serguey Zefirov
Tuesday, September 02, 2003, 1:59:41 AM, you wrote:
ANS> SZ> Smalltalk - это квантовая система, где принципиально все взаимодействуют со
ANS> SZ> всеми. Опровергнешь?
ANS> Там нет концепции кванта ;)
То есть, в твоем понимании ее там нет. Или в понимании Alan Kay? Или как?
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N. Sobchuck
ANS>> А где это возможно (я про дедлок)?
SZ> CQual.
Там требуется "преобразование типа" залочено/незалочено.
И производится анализ возможных потоков выполнения.
Мултитредовые программы в пролёте. А вопрос *у тебя* был
про два треда.
В ST такое реализуется при помощи классов ЗалоченныйЛок и
НезалоченныйЛок. У залоченного лока должна быть переменная,
содержащая процес, который получил лок.
Вообще, у меня сложилось впечатление, что идеальным будет
язык, который выдаст результат выполнения программы в момент
компиляции :)
Locking: Small Example
The lower left pane contains the original program, and the lower right pane contains the program with qualifier annotations.
In this example, the functions spin_lock and spin_unlock, which contain magic assembly code (omitted), are called to acquire and release a lock, respectively. The main function first acquires and then releases rtc_lock.
In the lower right pane we've added qualifiers $locked and $unlocked indicating that spin_lock and spin_unlock require their arguments be in the correct state. We've also added change_type statements to capture the effect of the assembly code. The expression change_type(x, type) is treated exactly like an assignment to x, except rather than giving an expression for the right-hand side you only need to supply the type of the right-hand side. We also declare that in the initial environment, rtc_lock is $unlocked.
void spin_lock($unlocked spinlock_t *lock) {
/* assembly code */
change_type(*lock, $locked spinlock_t);
}
void spin_unlock($locked spinlock_t *lock) {
/* assembly code */
change_type(*lock, $unlocked spinlock_t);
}
$unlocked spinlock_t rtc_lock;
int main(void)
{
rtc_lock;
spin_lock(&rtc_lock);
rtc_lock;
spin_unlock(&rtc_lock);
rtc_lock;
}
--
Андрей Собчук
and...@itware.com.ua
Andrei N. Sobchuck
SZ> Hello Andrei,
ANS>> SZ> Smalltalk - это квантовая система, где принципиально все взаимодействуют со
ANS>> SZ> всеми. Опровергнешь?
ANS>> Там нет концепции кванта ;)
SZ> То есть, в твоем понимании ее там нет. Или в понимании Alan Kay? Или как?
"Я хозяин своего слова. Оно обозначает то, что я захочу,
и ничего больше" (с) Шалтай-Болтай (где-то так по смыслу).
Давай определим дифиниции. Что есть "квант", "квантовая система"?
Может я и соглашусь с тобой.
--
Андрей Собчук
and...@itware.com.ua
Alexander Kobets
>
> Шо це такэ? (sorry my humble spelling)
У COM есть понятие Threading Model. В Single Threaded model при обмене
сообщениями, поток получателя синхронизируется с потоком отправителя, как
если бы они работали в одном потоке.
> Еслия правильно понимаю, то эта штука сообщения принимает асинхронно. А
мне
> надо синхронно.
Это и есть полезное ограничение. Всё просто - если объект не расчитан на
многопотоковую работу, то в многопотоковой среде дедлок не избежен, только
если система не будет эмулировать однопотоковость, как Single Threaded COM.
Пока.
--
Victor Metelitsa
Не знаю. Слишком сложный для меня вопрос. Например, что поменяется, если
SQL-сервер написан на самом ST и находится в том же имидже (и для пущей
"чистоты" не обращается к внешнему миру, напр., к дискам, реализован in
memory).
Alexey Desyatnik
02 сен 03 11:59, Andrei N. Sobchuck стучал(а) по клавишам для Serguey Zefirov:
SZ>> Smalltalk - это квантовая система, где принципиально все
SZ>> взаимодействуют со всеми. Опровергнешь?
AS> Там нет концепции кванта ;)
Есть, хотя и неявная. Деление объекта на составные части не бесконечно.
Hекоторые вещи просто необходимо выводить за пределы смоллтолковского мира,
делая их непрозрачными и оставляя лишь рычаги, за которые можно подёргать. Это
образно говоря :)
WBR, AD
... скажи мне, кто твой друг, и я скажу ему, кто ты!
Andrei N. Sobchuck
AD> делая их непрозрачными и оставляя лишь рычаги, за которые можно подёргать. Это
Кстати, кто-то предлагал реализацию чисел ввиде функций. Напомните, как выглядело
бы число 4, и подскажите, как его напечатать в десятичном формате.
--
Андрей Собчук
and...@itware.com.ua
Vadim Radionov
03 сен 03 16:05, Andrei N. Sobchuck wrote to Alexey Desyatnik:
ANS> Alexey Desyatnik <Alexey.D...@p10.f147.n5080.z2.fidonet.org> wrote:
AD>> делая их непрозрачными и оставляя лишь рычаги, за которые можно
AD>> подёргать. Это
ANS> Кстати, кто-то предлагал реализацию чисел ввиде функций.
Hикто не предлагал. Речь шла о возможности представить ряд лямбда-абстракций,
удовлетворяющий аксиомам чисел Пеано.
ANS> Hапомните, как
ANS> выглядело бы число 4, и подскажите, как его напечатать в десятичном
ANS> формате.
number_2 = \f x -> f (f x)
a `add` b = \f x -> a f (b f x)
print_num num = print (head (num tail raster))
where
raster = ["0","1","2","3","4", "5"]
main = print_num (number_2 `add` number_2)
Vadim
Anton Moscal
AD>> делая их непрозрачными и оставляя лишь рычаги, за которые можно
AD>> подёргать. Это
ANS> Кстати, кто-то предлагал реализацию чисел ввиде функций. Hапомните, как
ANS> выглядело бы число 4, и подскажите, как его напечатать в десятичном
ANS> формате.
В лямбда-исчислении, после некоторого количества определений (вводимых
средствами чистого исчисления) как S (S (S (S Z))) (десятичную систему тоже
никто не запрещает - ну будет что-то вроде
(mul_add n100 n2 (mul_add n10 n3 n9)) вместо 239.
Что до печати - то за отсуствием в чистых лямбдах ввода вывода и строк -
никак, но при расширении ее потребными - вполне обычно.
Как ни смешно, но единственная синтаксическая кривь лямбда-исчисления -
префиксная запись.
Vadim Radionov
03 сен 03 21:29, Anton Moscal wrote to Andrei N. Sobchuck:
AM> В лямбда-исчислении, после некоторого количества определений (вводимых
AM> средствами чистого исчисления) как S (S (S (S Z)))
AM> (десятичную систему
AM> тоже никто не запрещает - ну будет что-то вроде (mul_add n100 n2
AM> (mul_add n10 n3 n9)) вместо 239.
Hезависимо от внутреннего представления чисел,
алгоритм получения десятичных цифр не меняется: младшая цифра
определяется остатком от деления числа на n10, потом отбрасывается делением
на n10. И так повторяется до получения всех цифр.
Все что нам нужно: это определить zero, one (через функции), add, mul, div,
rem,
iszero. Получать по цифрам (представленным функцией) строковое представление мы
уже умеем (предыдущий мой постинг).
Vadim
Andrei N. Sobchuck
VR> Hикто не предлагал. Речь шла о возможности представить ряд лямбда-абстракций,
VR> удовлетворяющий аксиомам чисел Пеано.
А отрицательные числа как?
--
Андрей Собчук
and...@itware.com.ua
Andrei N. Sobchuck
SZ> http://mini.net/tcl/2523
SZ> По кульности сравнится? ;)
Кстати, в тикле очень активно используется семантика
передачи сообщений.
И не только на уровне компонент. Как результат - гибкость.
Вплоть до возможности определить присваивание через "=".
--
Андрей Собчук
and...@itware.com.ua
Serguey Zefirov
Wednesday, September 03, 2003, 9:39:54 PM, you wrote:
ANS> SZ> http://mini.net/tcl/2523
ANS> SZ> По кульности сравнится? ;)
ANS> Кстати, в тикле очень активно используется семантика
ANS> передачи сообщений.
ANS> И не только на уровне компонент. Как результат - гибкость.
ANS> Вплоть до возможности определить присваивание через "=".
Интересно было бы узнать поподробнее. А то пользуюсь им вот уже полтора года и
довольно активно, а про это не слышал. Поэтому, мне кажется, что ты
передергиваешь.
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N. Sobchuck
ANS>> Кстати, в тикле очень активно используется семантика
ANS>> передачи сообщений.
ANS>> И не только на уровне компонент. Как результат - гибкость.
ANS>> Вплоть до возможности определить присваивание через "=".
SZ> Интересно было бы узнать поподробнее. А то пользуюсь им вот уже полтора года и
SZ> довольно активно, а про это не слышал. Поэтому, мне кажется, что ты
Ты о присваивании? Я порылся в интернете, но сходу не нашел. Но идея в том,
что бы переопределить процедуру "unknown"
Пример:
% proc unknown {n1 n2 n3} {eval set ::$n1 $n3}
% a = 10
10
% puts $a
10
%
Ясно, что это не готовое решение, но идея, думаю, понятна
SZ> передергиваешь.
По поводу сообщений других возражений нет?
--
Андрей Собчук
and...@itware.com.ua
Vadim Radionov
04 сен 03 08:20, Andrei N. Sobchuck wrote to me:
ANS> Vadim Radionov <Vadim.R...@p8.f88.n4616.z2.fidonet.org> wrote:
VR>> Hикто не предлагал. Речь шла о возможности представить ряд
VR>> лямбда-абстракций, удовлетворяющий аксиомам чисел Пеано.
ANS> А отрицательные числа как?
Знак отдельно, модуль отдельно:
positive = \f x y -> f x -- он же булевское True, oн же селектор пары
negative = \f x y -> f y -- он же булевское False, он же селектор пары
make_int sign mod = \f -> f sign mod -- он же конструктор пары
get_sign i = i positive
get_mod i = i negative
one = \f x -> f x
minus_one = make_int negative one
Далее следует определить операции с учетом знака через операции над
натуральными
числами:
...
(в общем эта задачка для пятикласника)
:)
Vadim
Serguey Zefirov
Thursday, September 04, 2003, 2:51:22 AM, you wrote:
ANS>>> Кстати, в тикле очень активно используется семантика
ANS>>> передачи сообщений.
ANS>>> И не только на уровне компонент. Как результат - гибкость.
ANS>>> Вплоть до возможности определить присваивание через "=".
ANS> SZ> Интересно было бы узнать поподробнее. А то пользуюсь им вот уже полтора года и
ANS> SZ> довольно активно, а про это не слышал. Поэтому, мне кажется, что ты
ANS> Ты о присваивании?
Нет, я о семантике сообщений в тикле.
ANS> Я порылся в интернете, но сходу не нашел. Но идея в том,
ANS> что бы переопределить процедуру "unknown"
ANS> Пример:
ANS> % proc unknown {n1 n2 n3} {eval set ::$n1 $n3}
ANS> % a = 10
ANS> 10
ANS> % puts $a
ANS> 10
ANS> %
ANS> Ясно, что это не готовое решение, но идея, думаю, понятна
А ты ее целиком реши, вот тогда и будем говорить (про это есть на mini.net,
требует смены синтаксиса - командой считается второе слово и еще несколько
исключений).
ANS> SZ> передергиваешь.
ANS> По поводу сообщений других возражений нет?
А это - не семантика посылки сообщений. Нет в голом тикле сообщений, вообще.
Что я по этому поводу думаю: посылка сообщений столь же мощна, как и машина
Тьюринга. Поэтому она может все то же самое, что и любая другая модель, и ее
можно увидеть где угодно - например, в посылке сообщения вызова процедуры оной
процедуре. Жизнь она не улучшает и не ухудшает. Поэтому не стоит радоваться
тому, что разглядел эротику в изображении дельфинов (*).
--
Best regards,
Serguey mailto:s...@uc.ru
*
http://uue.nm.ru/Merphology/030901.htm
PS
Описанная тобой техника с использованием unknown применяется только для
автоматической подгрузки исходных текстов команд, чтобы места много не
занимали.
Andrei N. Sobchuck
SZ> А это - не семантика посылки сообщений. Нет в голом тикле сообщений, вообще.
Вот так вот, сообщений нет, а семантика есть. Прям как биты и битовые
операции ;)
--
Андрей Собчук
and...@itware.com.ua
Serguey Zefirov
Thursday, September 04, 2003, 4:46:13 AM, you wrote:
ANS> Serguey Zefirov <s...@uc.ru> wrote:
ANS> SZ> А это - не семантика посылки сообщений. Нет в голом тикле сообщений, вообще.
ANS> Вот так вот, сообщений нет, а семантика есть. Прям как биты и битовые
ANS> операции ;)
Хорошо. Что ты с этим будешь делать?
--
Best regards,
Serguey mailto:s...@uc.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru