Re[38]: Оберон круче всех!
От: samius Япония http://sams-tricks.blogspot.com
Дата: 24.07.12 19:57
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


S>>Ты сам ввел этот контекст. Цитата наверху этого сообщения.


V>Для меня вся выделенная ветка — один контекст. Скажем так, чтобы сосредоточиться на какой-то совсем отдельной ветке — это мне надо перечитать конкретную ветку заново. А это нереально, сорри. Поэтому любые новые ответы я даю с учетом уже прозвучавших аргументов со всех сторон.

Тогда тем более странно что ты в одном контексте даешь такие "разносторонние" ответы. В том смысле что они по логике должны были бы принадлежать разным сторонам.


S>>А вот это уже психоанализом пахнет. Если тебе виднее, на что я срефлексировал, то пусть так и останется.


V>Т.е. это не ты писал?

V>

V>Ждём мобилу с оберон-осью Как выйдет и захватит рынок, тогда поубавится смысл обсуждать тормозные среды исполнения.

Это я писал. И не надеялся что это послужит поводом к психоанализу.

V>>>Начал не я... просто вижу резкие необъяснимые рефлексии, как на мозоль наступили... Дык, наш клиент. )))

S>>А я-то что вижу... но оставлю при себе.

V>Дык поделись, фигли уже...

Ничего оригинального, чего бы в этой ветке не было написано в твой адрес.

S>>Я никаких аргументов не приводил. Я всего лишь написал что будем ждать когда оберон станет настолько популярным и востребованным что можно будет не обсуждать тормоза дотнета и андройда.


V>Еще раз крупным по белому, вопрос был в том, какой смысл обсуждать тормозные среды исполнения здесь, в этом топике. Логичнее было бы обсуждать среды, построеные на аналогичном принципе. И да, таких сред гораздо больше, чем две обсужденные шт: Оберон vs Сингулярити. Вот если бы ты привел для обсуждения еще одну подобную или высказался по одной из уже упомянутых — мне это было бы интереснее. Вот и всё что я сказал. Может я и не так подробно высказал своё желание. Ну сорри и так много букв сюда пишу. Но отмахиваться от Лиспа, Эрланга, Виндовса и прочего нерелевантного обсуждению бреда мне категорически надоело. Если перечитаешь тему целиком — поймешь почему.

А твоим оппонентам надоело отмахиваться от оберона. Тут не надо даже тему перечитывать что бы понять причину.
Давай лучше вместь приведения еще одной среды я подкину мысль что ось-среда/JM(или CLR) вероятно имела бы больший успех, чем оберон-ось. До кучи еще одна мысль, что если бы оно реально надо было кому-то, то оно бы уже было.
Re[7]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 20:01
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


А если я и так знаю? Да и ты и так знаешь, что я итак знаю и к чему тогда спрашивать? ))) Так надо. Кто-то несогласен "категорически", а кто по-существу. Будучи немного внимательным ты увидишь оставленное пространство для маневра практически в каждом посте по этой теме, даже в самых провокационных.
Re[6]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 20:10
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ужас то какой. Ну расскажи тогда, как в православном ООП 21 века следует разруливать такие ситуации: есть некое значение, которое может быть представлено следующим образом: как строка, как поток и как объектная ссылка? Будем руками везде дискриминант анализировать без какого либо контроля? Или городить над 3 вариантами визитор?


Это ты всерьез спросил или как все? ))

При наличии инструмента инкапсуляции ей можно не пользоваться. А когда инкапсуляции нет, то попользоваться ей при нужде не выйдет. Это ответ на то, что ты хотел спросить?

А на то, что ты не хотел спросить, я бы предпочел увидеть основные операции по этому значению, прежде чем что-то советовать. Визитор — это же развитие ф-сти объекта вне объекта. Может там будет подходящий сценарий упрятать ф-сть в самом объекте? А этот вариант ты мне на выбор не предоставил. А может удобней будет протянуть сразу "замкнутый" типизированный алгоритм на нужную струткуру данных? Зачастую многократно и удобнейи эффективней, чем упаковывать значние конкретного типа в абстрактное и распаковывать затем на паттерн-матчинге или визиторе. Вариантов даже больше 4-х, кароч, а никак не 2.
Re[7]: Оберон круче всех!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.07.12 20:20
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Это ты всерьез спросил или как все? ))


Ты хами хами. Совсем чуть чуть осталось.

V>При наличии инструмента инкапсуляции ей можно не пользоваться. А когда инкапсуляции нет, то попользоваться ей при нужде не выйдет. Это ответ на то, что ты хотел спросить?


Нет. Вопрос был вполне конкретный. Просьба продемонстрировать тру ООП решение 21 века. Show me your code.

V>А на то, что ты не хотел спросить, я бы предпочел увидеть основные операции по этому значению, прежде чем что-то советовать.


Основная операция ровно одна — потребление этого значения. Строка парсится, стрим выкачивается в память, объект используется как есть.

V>Может там будет подходящий сценарий упрятать ф-сть в самом объекте?


Нет, не подходящий. Объект это AST, согласно SRP нагружать лишним функционалом не надо.

V>Вариантов даже больше 4-х, кароч, а никак не 2.


Да хоть 10. Код покажи.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[42]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 21:12
Оценка:
Здравствуйте, novitk, Вы писали:


V>>На продолжениях она делается легко и обратное верно — при условии функциональной чистоты конкурентное програмирование доступно только на продолжениях.

N>Реальную (с вытеснением и МТ) конкурентную среду без синхронизации не сделать. Продолжения это костыль для людей, которые не имеют к ней доступа.

А ты и не имеешь доступа из юзверского кода к вытесняющей многозадачности. А любые попытки таки сделать вытесняющую из юзверского кода (напр. управление фиберами по таймеру), превратят всю затею в профанацию. Да и вообще, это обсуждение выросло из обсуждения рядом агентской среды (акторов), а в ней акторы сидят в ожидании и получают кванты на обработку преимущественно тогда, когда им есть что делать, то бишь готов ввод-вывод. И я уже писал тут более одного раза, что в этих самых условиях, когда агенты сидят постоянно на вводе/выводе особой разницы м/у кооперативной многозадачностью и вытесняющей нет. Разница есть только тогда, когда процессы всё-время что-то делают, а не сидят по большей части в ожидании сигналов.


V>>Просто в Хаскеле нет продложений. Ниасилили.

N>"что же это у вас, чего ни хватишься, ничего нет!" (c) M. Булгаков
N>Давай ты уже перестанешь комментировать язык о котором нифига не знаешь. http://en.wikibooks.org/wiki/Haskell/Continuation_passing_style

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

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

Вот есть входные события. Можно нарисовать обработчики событий по простой событийной схеме, то бишь совершая работу над мутабельным состоянием в ответ на каждое событие через конкретную ф-ию-обработчик. А можно иначе — иметь некий контекст вычислений, который читает из некоего пайпа (абстракция) и каждый вызов зачитки данных из пайпа с т.з. потока исполнения этого контекста вычислений как бы блокирующий. А извне всё наоборот — вызов на ожидание "изнутри" такой коротины на основе продолжения будет означать взврат из процедуры записи в пайп для внешнего кода, то бишь конец цикла диспетчеризации события. Т.е. это не две независимые нити общаются и не два фибера, а просто вывернутая наизнанку логика из того же самого потока (который из пула), примерно как в async/await в C#.


V>>Ну ОК, в исходном тезисе Хаскель не подходит, надо заменить слово "Хаскель" на "Схему". А сам Хаскель предать анафеме. )))

N>Опять двадцать пять. Теперь на схему зачем то наехал. http://docs.racket-lang.org/reference/concurrency.html

Странно, call/cc и коротины на нем в стандарте Схемы вижу, а то, что по ссылке — не вижу.
Re[3]: Оберон круче всех!
От: Cyberax Марс  
Дата: 24.07.12 21:56
Оценка:
Здравствуйте, VladD2, Вы писали:

C>>Это унылое дерьмо мамонта из 80-х годов.

VD>В плане истории важно не то что в нем нет, а то что в нем появилось. К сожалению, я не могу вспомнить ничего.
А в нём ничего и не появилось нового, абсолютно.
Sapienti sat!
Re[8]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 22:04
Оценка:
Здравствуйте, AndrewVK, Вы писали:

V>>Это ты всерьез спросил или как все? ))

AVK>Ты хами хами. Совсем чуть чуть осталось.
Ну, т.е. это у тебя случайно вырвалось?

Ужас то какой. Ну расскажи тогда, как в православном ООП 21 ...

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


V>>А на то, что ты не хотел спросить, я бы предпочел увидеть основные операции по этому значению, прежде чем что-то советовать.

AVK>Основная операция ровно одна — потребление этого значения. Строка парсится, стрим выкачивается в память, объект используется как есть.

V>>Может там будет подходящий сценарий упрятать ф-сть в самом объекте?

AVK>Нет, не подходящий. Объект это AST, согласно SRP нагружать лишним функционалом не надо.

Это мне, как автору решения решать, сорри за тафтологию.

Зачем ты скипнул это?

А может удобней будет протянуть сразу "замкнутый" типизированный алгоритм на нужную струткуру данных?

В ней суть, т.к. принципиально варианты разделяются вокруг идеологии poll/push, тут даже ООП не при чем, а SRP тем более ортогональная характеристика решения. Предложенные тобой варанты визитора vs АлгТД это же одно и тоже фактически. С некоторой долей вероятности эти два решения, будучи приведенным компилятором в машинный код, могут даже выглядеть одинаково. В общем, это рантайм-полиморфизм, которым ты заведомо наградил один и тот же элемент дизайна... т.е. обсуждать техники этого полиморфизма на фоне принципиального решения в дизайне — это палочкой ковыряться...

ИМХО, тут всё очевидно. Если у тебя интерфейс в стиле poll, то ты вынужден делать возвращаемое значение абстрактным, если функциональность "Дай" может вернуть значения более чем одного конкретного типа:
SomeAbstractValue Дай(Context context);

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

Можно сделать интерфейс в стиле push:
void На(Context context, Listener listener);

В этом случае уже доступен выбор compile-time или runtime полиморфизма для Listener. Но гвоздь в том, что значения конкретных типов, которые получаются в конкретном месте, не надо заворачивать в абстрактные. Техника немного близка к визитору, но лишь ровно на половину, к тому же зачастую позволяет избегать дорогих вирутальных вызовов в Listener.

V>>Вариантов даже больше 4-х, кароч, а никак не 2.

AVK>Да хоть 10. Код покажи.

Основные отличия показал.
Писать сюда визитор, или реализацию Listener ес-но не буду, всё и так тебе понятно, я уверен. Единственный интерес в таком дизайне (я его называю — эффективным, оперативным) сидит в том, где у нас будут идти переходы poll<=>push. Таких переходов в дизайне может быть намного больше одного. И вот тут уже, сорри, надо чуть больше данных для принятия решений. Само решение принимается фактически механически и зависит напрямую от твоей задачи (от колв-а и дороговизны операций над бутылкой). Самих техник перехода poll<=> push больше одного, один из них я привел как цитирование себя в этом же посте. Другие способы — чередование обработки данных с построением графа конечного результата, в т.ч. через отправку данных для второй операции в другой поток.
Re[2]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 22:08
Оценка:
Здравствуйте, Kernan, Вы писали:

V>>Ну и такой момент, что за основу языка был взят синтаксис Паскаля, а наиболее популярны сейчас языки с Си-подобным синтаксисом... и, смотрю, некоторые считают возможным причислять "недопаскалистов" к неоспоримым нубам, так ведь? Но синтаксис, ИМХО, дело не то, что десятое, а даже сотое при сравнении возможностей языков.

K>Сергей Губанов, вы реинкарнировали в vdimas?

Окстись, я его похоже старше и еще не умер, чтобы в мой ник реаинкарнировать. )))
Re[2]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 22:08
Оценка:
Здравствуйте, Kernan, Вы писали:

K>Сергей Губанов, вы реинкарнировали в vdimas?


И да, ты произнес ключевое слово, теперь ты вне игры. Следующий.

))
Re[39]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 22:18
Оценка:
Здравствуйте, samius, Вы писали:

S>А твоим оппонентам надоело отмахиваться от оберона. Тут не надо даже тему перечитывать что бы понять причину.

S>Давай лучше вместь приведения еще одной среды я подкину мысль что ось-среда/JM(или CLR) вероятно имела бы больший успех, чем оберон-ось. До кучи еще одна мысль, что если бы оно реально надо было кому-то, то оно бы уже было.

Дык, а ты еще не понял? Мне надо. Не обязательно Оберон, но сам подход и все что связано. CLR/JM не подходят и близко. Скажем так, разница почти на порядок в эффективности по моим задачам. Я вообще расчитывал больше узнать, чем рассказать... бо сразу признался, что не изучал его настолько глубоко, как некоторые знаменитые здесь личности... Просто времена когда можно спросить и получить ответ на этом сайте давно прошли... оппонент "отрывает пятую точку" только когда с ним споришь.

Ну а что тут некоторые в мой адрес писали — вообще до фени. Это одни и те же личности, взаимные диспозиции с которыми определились еще до 2004-го. Ничего нового. Да и у меня тут много постов было за все годы, весьма разных. Каждый выбирает что ему нравится.
Re[9]: Оберон круче всех!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.07.12 22:18
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А попытки угрожать модерством в топике, в котором что-то пытаешься спорить по существу... это ж почти аргумет в споре.


Ты если еще не понял, это намек что ты в этом топике ведешь себя на грани допустимого. Сбавь обороты. К разговору со мной это отношения не имеет. И, коль ты уже личные нападки от безличных не отличаешь, дальнейшее обсуждение этого вопроса только на moderator@rsdn.ru

V>Зачем ты скипнул это?


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

V>SomeAbstractValue Дай(Context context);


Что такое SomeAbstractValue?

V>Можно сделать интерфейс в стиле push:

V>void На(Context context, Listener listener);

Опять ничего не понятно.

V>>>Вариантов даже больше 4-х, кароч, а никак не 2.

AVK>>Да хоть 10. Код покажи.

V>Основные отличия показал.


А код — не показал. Одна пустая болтовня, уж извини. Причем много.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[10]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 22:56
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>И, коль ты уже личные нападки от безличных не отличаешь, дальнейшее обсуждение этого вопроса только на moderator@rsdn.ru


Жаловаться в мыло все-равно не буду. А на обороты некоторые личности растолкали, это да... Впрочем, все сообщения на месте, всё видно...
Re[35]: Оберон круче всех!
От: Cyberax Марс  
Дата: 24.07.12 23:11
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Еще раз, для ЯВУ Оберона есть редакторы с полной подсветкой. Вот только что запустил линуховую виртуалку и открыл в ней среду Kate с нужными настройками:

Это обычная подсветка синтаксиса. Детский сад, короче говоря.

Вот ТАК выглядит реальная подсветка в современных редакторах:
Sapienti sat!
Re[10]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 23:15
Оценка:
Здравствуйте, AndrewVK, Вы писали:

V>>SomeAbstractValue Дай(Context context);


AVK>Что такое SomeAbstractValue?


Это тот самый абстрактный тип, который ты задал по условию. Это либо алгТД, либо ОО-интерфейс посещаемой стороны в визиторе. По тому факту, какой именно элемент ты наградил абстрактностью, я понял о каком общем виде дизайна идет речь.

(И можно я таки не буду писать сюда классического визитора или эмуляцию размеченного объединения и никто мне за это не скажет, что я с этим не справился?)

V>>Можно сделать интерфейс в стиле push:

V>>void На(Context context, Listener listener);

AVK>Опять ничего не понятно.


Полезная работа выполняется в процедуре/ф-ии/методе На, на вход которой поданы необходимые данные + некий callback. Внутри в конкретных ветках алоритма, там, где ты ранее создавал значения конкретных типов и упаковывал их в абстрактные типы, теперь ты вызываешь типизированные перегрузки методов listener.

Например:
// algorithm node 1
string s = MakeString(chars, offset, length);
listener.process(s);
..
// algorithm node 2
SomeObject o = MakeObject(data);
listener.process(o);
...


class Listener {
  public void process(string s);
  public void process(SomeObject o);
...
}


AVK>Одна пустая болтовня, уж извини. Причем много.


С учетом этого:

AVK>Опять ничего не понятно.

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

Еще я упоминал момент про замкнутый контекст, который переводит push опять в poll. Это примерно вот такая замена:
// algorithm node 2
SomeObject o = MakeObject(data);
astNodes.add((o)=>listener.process(o));

Это подходит для работы с конкретным Listener, когда над astNodes надо совершать всего одну операцию.

Если больше одной, то:
interface Listener {
...
}

class ListenerProxy : Listener {
  public void process(string s) { _proxee.process(s); }
...
  Listener _proxee;
}

Заметь, все эти poll-варианты являются вариациями, близкими к визитору по сути происходящего, но вдвое более скромными в плане поддержки, т.к. не требуют объявления и разработки интерфейса посещаемой стороны в визиторе, нужен только сам посетитель.
Re[13]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 23:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:

V>>А техника интерпретации какая была: p-код или работающее AST?


AVK>Второе.


Ну тогда предположу специфику — огромное кол-во типов узлов AST.
В обычном интерпретирующем языке кол-во типов узлов минимально, плюс обычно всего 2-4 базовых типа, и ф-сть самого интрепретатора меньше по объему, чем парсера.
Re[36]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 23:36
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вот ТАК выглядит реальная подсветка в современных редакторах:


Бррр... чуть глаза не сломал ))))
В современных редакторах это выглядит намного лучше:
Re[37]: Оберон круче всех!
От: Cyberax Марс  
Дата: 24.07.12 23:42
Оценка:
Здравствуйте, vdimas, Вы писали:

C>>Вот ТАК выглядит реальная подсветка в современных редакторах:

V>Бррр... чуть глаза не сломал ))))
Вопрос конкретных цветов и шрифтов — это исключительно вопрос вкуса и личных предпочтений. Только сейчас заметил, что на картинке не учтено, что у меня высокий DPI — на обычных мониторах текст будет выглядеть слишком большим.

А вот вопрос функциональности — это уже не вопрос вкуса. Современные IDE понимают семантику языка и делают соответствующую подсветку.

V>В современных редакторах это выглядит намного лучше:

Точно. А для Оберона — ниасилили.
Sapienti sat!
Re[38]: Оберон круче всех!
От: vdimas Россия  
Дата: 24.07.12 23:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

V>>В современных редакторах это выглядит намного лучше:

C>Точно. А для Оберона — ниасилили.

И не осилят...
У них компоненты миниатюрного размера. А подсветка рулит для разбора завалов исходников. В общем, наличие проблемы надо сначала осознать. Не осознают, увы, это же не Джава. ))
Re[35]: Оберон круче всех!
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.07.12 04:35
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>Это я свои реакции вообще-то анализировал. Как бэ право имею, да и реакции были на рекламу технических моментов.

Ваша психология тоже здесь никого не интересует. Как и то, почему вы воспринимаете технические обсуждения за рекламу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[49]: Оберон круче всех!
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.07.12 04:45
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:


S>>А кто проверяет эти security — артефакты, передаваемые в виде аргументов?


V>Легче спросить — откуда они берутся. Проверяет их пусть софт из того самого "пояса безопасности", организующего системное АПИ.

Ок, заодно расскажите, откуда они берутся. А то я, похоже, чего-то фундаментального не понимаю. Также, как и того, каким волшебным образом софт из "пояса безопасности" вдруг получит возможность что-то там проверить. Вот у меня "модуль" А вызывает метод объекта из "модуля" B. Допустим, это метод WebRequest.Send(). Как будет осуществляться проверка того, что модулю А можно разрешить эту операцию?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.