Здравствуйте, Курилка, Вы писали:
К>Знаешь, это очень напоминает лозунги когда начали делать языки 4-го уровня, тот же SQL или ABAP/4 у сапа — речь шла ну в точности об этом, что запросы и т.п. будут делать сами бухгалтера, а не программисты. Результат, думаю, ты знаешь
Что-то я не помню такого про 4-GL чтобы говорилось. А вот прикладных программистов на том же АБАП-е выидел. И как не странно они скорее были не программистами, а прикладниками кое-как освоевшими этот самый АБАП. За-то они спокойно воспринимали несуразности и странности АБАП-а так как не могли сравнить его с другими языками.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Примерно об этом и идет речь, но ты не гарантируешь что из твоего объекта кто-то не заполучит прямой доступ к другим. А тут это гарантируется.
Нет прямой доступ только из библиотечного кода
VD>Плюс у тебя наверняка не решена проблема отема управления у методов активных объектов и возобновления их исполнения с того же места.
Я считаю что бeз содействия со стороны кода живого объекта это невозможно сделать корректно в принципе. Т.к. ни кто не гарантирует в каком состояниии сейчас находится этот код, это похоже на SuspendThread которая на мой взгляд является одной из функций которую человек в здравом уме использовать не будет, за исключением такого варианта SuspendThread(GetCurrentThreadId());
Здравствуйте, gid_vvp, Вы писали:
VD>>Примерно об этом и идет речь, но ты не гарантируешь что из твоего объекта кто-то не заполучит прямой доступ к другим. А тут это гарантируется.
_>Нет прямой доступ только из библиотечного кода
На С++ я с легкостью получую доступ до всего что находится в этом же процессе ОС и может быть в принципе прочитано.
_>Я считаю что бeз содействия со стороны кода живого объекта это невозможно сделать корректно в принципе.
На С++ — да. В случае более гибких языков это возможно, но сложно.
_> Т.к. ни кто не гарантирует в каком состояниии сейчас находится этот код, это похоже на SuspendThread которая на мой взгляд является одной из функций которую человек в здравом уме использовать не будет, за исключением такого варианта SuspendThread(GetCurrentThreadId());
Ты ошибашся. Та же ОС прекрасно отнимает время у потоков без их ведома и проблем нет.
Проблема только в сложности реализации. Реально для таких вещей нужно переписывать код объекта в кон на конечных автоматах или сохранять состояние стека (возможно менять стэк) и объекта в неком хранилище.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_>>Нет прямой доступ только из библиотечного кода
VD>На С++ я с легкостью получую доступ до всего что находится в этом же процессе ОС и может быть в принципе прочитано.
Такой подход вне зависимости от языка программирования считаю не правильным. Т.к. если ты пытаешся и используешь что-то, что не предназначено для непосредственного иcпользования тобой то делаешь ты это только из-за своей глупости и на свой страх и риск Тебе даже может повезти и твой код будет работать... хотя это скорее больше похоже на невезение
_>>Я считаю что бeз содействия со стороны кода живого объекта это невозможно сделать корректно в принципе.
VD>На С++ — да. В случае более гибких языков это возможно, но сложно.
Ещё раз повторю, без помощи кода со стороны живого объекта этого сделать невозможно.
Простой пример будет ниже.
_>> Т.к. ни кто не гарантирует в каком состояниии сейчас находится этот код, это похоже на SuspendThread которая на мой взгляд является одной из функций которую человек в здравом уме использовать не будет, за исключением такого варианта SuspendThread(GetCurrentThreadId());
VD>Ты ошибашся. Та же ОС прекрасно отнимает время у потоков без их ведома и проблем нет.
Как ты дмаешь почему? Потому что эти потоки созданы в соответствии с правилами которые диктует ОС и потоки которые не придерживаются их просто не будут работать на данной ОС.
VD>Проблема только в сложности реализации. Реально для таких вещей нужно переписывать код объекта в кон на конечных автоматах
О чём я и говорил с самого начала:
"Я считаю что бeз содействия со стороны кода живого объекта это невозможно сделать корректно в принципе."
VD>или сохранять состояние стека (возможно менять стэк) и объекта в неком хранилище.
не поможет, смотри простой пример
пусть наш живой объект обращается к какому-то ресурсу с эксклюзивным доступом. Для того чтобы к нему обратится наш живой объект должен захватить например некий мютекс поработать с этим рескрсом и освободить его. Что произойдёт если мы прервём (или приостановим) его каким-то образом после захвата мютекса?
Итак повторю: для того чтобы корректно сделать приостановку или прекращение работы какого либо метода живого объекта необходимао что бы этот объект поддерживал такую возможность, например пользовался специальным API который будет предоставлять библиотека (например моя библиотека или API OC в твоём примере)
Здравствуйте, gid_vvp, Вы писали:
_>Такой подход вне зависимости от языка программирования считаю не правильным. Т.к. если ты пытаешся и используешь что-то, что не предназначено для непосредственного иcпользования тобой то делаешь ты это только из-за своей глупости и на свой страх и риск Тебе даже может повезти и твой код будет работать... хотя это скорее больше похоже на невезение
Извини за не стромный вопрос. Ты один программируешь? А ошибки делаешь?
VD>>На С++ — да. В случае более гибких языков это возможно, но сложно.
_>Ещё раз повторю, без помощи кода со стороны живого объекта этого сделать невозможно. _>Простой пример будет ниже.
Формулировка стала более раслывчатая.
_>Как ты дмаешь почему? Потому что эти потоки созданы в соответствии с правилами которые диктует ОС и потоки которые не придерживаются их просто не будут работать на данной ОС.
Единственно правило которому нжно придерживаться потоку — это синхронизировать доступ к глобальнрым данным. Идеология активных объектов как раз и устраняет эту необъодимость.
VD>>Проблема только в сложности реализации. Реально для таких вещей нужно переписывать код объекта в код на конечных автоматах
_>О чём я и говорил с самого начала: _>"Я считаю что бeз содействия со стороны кода живого объекта это невозможно сделать корректно в принципе."
Ты живешь в мире С++ (хотя и он на самом деле не так беден) в котором для тебя нет возможности вмешаваться в уже написанный код. Меж тем это возможно. Просто конкретно на С++ это чертовски сложно.
VD>>или сохранять состояние стека (возможно менять стэк) и объекта в неком хранилище.
_>не поможет, смотри простой пример
Я даже обсуждать это не хочу. То что это возможно подтверждает наличие потоков в ОС.
_>пусть наш живой объект обращается к какому-то ресурсу с эксклюзивным доступом.
Этого не может быть. На то он и атктивный объект чтобы обращаться на прямую только к инкапсулированных в нем же ресурсам. Разделяемые ресурсы должны быть инкапсулированы в других активных объектах и дополнительной синхранизация требовать не должны. Ведь досутп к самим объектам уже синхронизируется.
_> Для того чтобы к нему обратится наш живой объект должен захватить например некий мютекс поработать с этим рескрсом и освободить его. Что произойдёт если мы прервём (или приостановим) его каким-то образом после захвата мютекса?
Так что произойдет одно из двух. Или ты и такие как ты (ких миллионы) перестроишь свое сознание и перестанишь жить догмами современных (точнее устаревших) API и догмами C/C++, или ваши программы будут сплашным багодромом не способным серьезно маштабироваться на многопроцессорной технике.
_>Итак повторю: для того чтобы корректно сделать приостановку или прекращение работы какого либо метода живого объекта необходимао что бы этот объект поддерживал такую возможность, например пользовался специальным API который будет предоставлять библиотека (например моя библиотека или API OC в твоём примере)
Сами активные объекты обязаны общаться между собой ассинхронными сообщениями. Эти сообщения обязаны помещаться в очередь и извлекаться от туда последовательно. Обеспечить это должен код фрэймворка. Фрэймворк этот должен делать таких хайтек-вещи как переписывание кода активного объекта с целью скрытия событийной природы и возможности отема у него управления. Реальный код долфен выглядеть при этом практически как конечный автомат разбора очереди, но программист должен думать в терминах ООП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_>i = aa.f1("str");//выполняется в области обитания живого объекта, а сюда возвращается результат (этот поток ждёт пока не придёт результат)
_>
Вот здесь небольшая загвозка. Что если мне не нужен результат прямо сейчас. Могу я не ждать возвращения результата, а продолжать исполнение до тех пор, пока где-то в будущем мне действительно не понадобится результат, и тогда я уже подожду если нужно (а может быть к тому времени он уже будет готов, и ждать не прийдётся)?
Здравствуйте, VladD2, Вы писали:
VD>Так что произойдет одно из двух. Или ты и такие как ты (ких миллионы) перестроишь свое сознание и перестанишь жить догмами современных (точнее устаревших) API и догмами C/C++, или ваши программы будут сплашным багодромом не способным серьезно маштабироваться на многопроцессорной технике.
Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.
(Albert Einstein)
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>Знаешь, это очень напоминает лозунги когда начали делать языки 4-го уровня, тот же SQL или ABAP/4 у сапа — речь шла ну в точности об этом, что запросы и т.п. будут делать сами бухгалтера, а не программисты. Результат, думаю, ты знаешь
VD>Что-то я не помню такого про 4-GL чтобы говорилось. А вот прикладных программистов на том же АБАП-е выидел. И как не странно они скорее были не программистами, а прикладниками кое-как освоевшими этот самый АБАП. За-то они спокойно воспринимали несуразности и странности АБАП-а так как не могли сравнить его с другими языками.
Я тоже, если честно не помню, ну маленький я совсем был в годах так 80-х (а в 70-х вообще меня не было ), да и плюс это всё ещё больше было на западе (а с языками 5-го поколения в Японии мучались в 80-х), так что я речь об этом веду больше из "воспоминаний" более старого поколения. Да и тех же абаперов ты, я думаю, не в начале 80-х видел, так что не показательно
А так вообще развитие идёт по спирали, поэтому повторения некоторых тенденций закономерны.
A>Вот здесь небольшая загвозка. Что если мне не нужен результат прямо сейчас. Могу я не ждать возвращения результата, а продолжать исполнение до тех пор, пока где-то в будущем мне действительно не понадобится результат, и тогда я уже подожду если нужно (а может быть к тому времени он уже будет готов, и ждать не прийдётся)?
Да, такая возможность есть. Можно установить callback в который будет возвращёи результат, либо воспользоваться специальным классом который принимает отложенный результат и может сказать пришёл результат или ещё нет
_>>Такой подход вне зависимости от языка программирования считаю не правильным. Т.к. если ты пытаешся и используешь что-то, что не предназначено для непосредственного иcпользования тобой то делаешь ты это только из-за своей глупости и на свой страх и риск Тебе даже может повезти и твой код будет работать... хотя это скорее больше похоже на невезение
VD>Извини за не стромный вопрос. Ты один программируешь? А ошибки делаешь?
Не один. Делаю
Несовсем понятно к чему ты это спросил...
Хотя возможно ты считаешь что можно по ошибке написать код для обхода ограничений и получения того что не предназначено для тебя?
_>>Ещё раз повторю, без помощи кода со стороны живого объекта этого сделать невозможно. _>>Простой пример будет ниже.
VD>Формулировка стала более раслывчатая.
Ты меня совсем расстраиваешь
Вот моя начальная формулировка:
Я считаю что бeз содействия со стороны кода живого объекта это невозможно сделать корректно в принципе
И где ты увидел большую расплывчатость?
_>>Как ты дмаешь почему? Потому что эти потоки созданы в соответствии с правилами которые диктует ОС и потоки которые не придерживаются их просто не будут работать на данной ОС.
VD>Единственно правило которому нжно придерживаться потоку — это синхронизировать доступ к глобальнрым данным. Идеология активных объектов как раз и устраняет эту необъодимость.
Ты меня совсем не понял Я не о правилах хорошего тона Я о тех механизмах ОС которые делают возможной работу всех программ. О менеджере памяти, о планировщике задач, и т.д. и т.п. все эти механизмы работают для того чтоб было возможно в том числе и переключение задач, приостановка потоков и т.д.
И для того чтобы сделать отмену и приостановку придётся в полном объеме создать аналогичные механизмы, что по сути выльется в отдельную ОС
VD>Ты живешь в мире С++ (хотя и он на самом деле не так беден)
А кто считает что он беден
VD> в котором для тебя нет возможности вмешаваться в уже написанный код.
Как раз на С++ это возможно, но я уже раньше сказал своё мнени по этому поводу.
VD>Меж тем это возможно. Просто конкретно на С++ это чертовски сложно.
Давай чтобы не быть голословным ты напишешь такой код который, будет корректно отменять или приостанавливать любой другой код? (конечно же на современном языке, на том на котором это элементарно делается )
VD>Я даже обсуждать это не хочу. То что это возможно подтверждает наличие потоков в ОС.
Полностью с тобой согласен Всё это элементарно делается, всего лишь надо написать свою ОС Да и зачем писать... Чем тебе процессы ОС не живые объекты
VD>Этого не может быть. На то он и атктивный объект чтобы обращаться на прямую только к инкапсулированных в нем же ресурсам. Разделяемые ресурсы должны быть инкапсулированы в других активных объектах и дополнительной синхранизация требовать не должны. Ведь досутп к самим объектам уже синхронизируется.
Вот видишь сколько ограничений приходится накладывать на код живого объекта
А там ниже ещё ограничения... Плюс у каждого активного объекта должен быть свой пул памяти и многие другие вещи. Т.к. память вполне может быть тем разделяемым ресурсом который должен инкапсулироваться в активном объекте.
VD>Так что произойдет одно из двух. Или ты и такие как ты (ких миллионы) перестроишь свое сознание и перестанишь жить догмами современных (точнее устаревших) API и догмами C/C++, или ваши программы будут сплашным багодромом не способным серьезно маштабироваться на многопроцессорной технике.
Чего ругаешься?
_>>Итак повторю: для того чтобы корректно сделать приостановку или прекращение работы какого либо метода живого объекта необходимао что бы этот объект поддерживал такую возможность, например пользовался специальным API который будет предоставлять библиотека (например моя библиотека или API OC в твоём примере)
VD>Сами активные объекты обязаны общаться между собой ассинхронными сообщениями. Эти сообщения обязаны помещаться в очередь и извлекаться от туда последовательно. Обеспечить это должен код фрэймворка. Фрэймворк этот должен делать таких хайтек-вещи как переписывание кода активного объекта с целью скрытия событийной природы и возможности отема у него управления. Реальный код долфен выглядеть при этом практически как конечный автомат разбора очереди, но программист должен думать в терминах ООП.
А ты не замечаешь что ты говоришь о томже что и я но другими словами?
более того я с тобой соглашаюсь что в принципе это возможно, но эта работа по трудоёмкости сравнима с написанием не худшей из ОС. А это мне не по плечу и сомневаюсь что тебе по плечу даже если ты будешь для этого пользоваться перестроенным сознанием и неустаревшими языками
Здравствуйте, eao197, Вы писали:
VD>>Так что произойдет одно из двух. Или ты и такие как ты (ких миллионы) перестроишь свое сознание и перестанишь жить догмами современных (точнее устаревших) API и догмами C/C++, или ваши программы будут сплашным багодромом не способным серьезно маштабироваться на многопроцессорной технике.
E>
E>Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.
E>(Albert Einstein)
А по-русски эта фраза была бы менее значительна? Или просто всем сразу бы было понятно, что это плохо замаскеровванный наезд и та самая глупость?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Я тоже, если честно не помню, ну маленький я совсем был в годах так 80-х (а в 70-х вообще меня не было ), да и плюс это всё ещё больше было на западе (а с языками 5-го поколения в Японии мучались в 80-х),
А было оно это 5-е поколение? Ведь и 4-ое то было на самом деле скорее пиаром и тупиковой веткой. Реальная эволюция пошла из языков 3-его поколения и как теперь выясняется из того что в те времена считали чудачеством (это я про Лисп).
К> так что я речь об этом веду больше из "воспоминаний" более старого поколения.
Ну, я немного это дело застал. Хотя тоже скорее больше лицезрел угасание и смеялся над глупостью (в то время она была уже очевидна).
К> Да и тех же абаперов ты, я думаю, не в начале 80-х видел, так что не показательно
Я видел АБАП-3 (что ли) из R3. У меня до сих пор дома книжка по нему воляется.
К>А так вообще развитие идёт по спирали, поэтому повторения некоторых тенденций закономерны.
Не скажи. АБАП-ы были скорее тупиковой веткой. Но важные моменты в хтих 4-GL были. А именно заточенность на специфику решаемых проблем. В те времена это было полнейшее извращение. Теперь же заточенность принимает форму научного подхоща. И это правильно. В этом действительно можно усмотреть спиральное развитие.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>Я тоже, если честно не помню, ну маленький я совсем был в годах так 80-х (а в 70-х вообще меня не было ), да и плюс это всё ещё больше было на западе (а с языками 5-го поколения в Японии мучались в 80-х),
VD>А было оно это 5-е поколение? Ведь и 4-ое то было на самом деле скорее пиаром и тупиковой веткой. Реальная эволюция пошла из языков 3-его поколения и как теперь выясняется из того что в те времена считали чудачеством (это я про Лисп).
Я тебе о том и говорю — что был чисто пиар и лозунги
VD>Я видел АБАП-3 (что ли) из R3. У меня до сих пор дома книжка по нему воляется.
Он ещё в R/2 был уже ABAP/4, цифирка четыре как раз там по идее и обозначала что язык 4-го поколения. Ну можно это было...
А абап кстати хоть и тупиковая ветка, но ещё далеко не мёртвая, криво убого, но проекты с миллионными бюджетами крутятся на саповских серверах
Вот тут уж пиар до предела
Здравствуйте, gid_vvp, Вы писали:
_>>>Такой подход вне зависимости от языка программирования считаю не правильным. Т.к. если ты пытаешся и используешь что-то, что не предназначено для непосредственного иcпользования тобой то делаешь ты это только из-за своей глупости и на свой страх и риск Тебе даже может повезти и твой код будет работать... хотя это скорее больше похоже на невезение
VD>>Извини за не стромный вопрос. Ты один программируешь? А ошибки делаешь?
_>Не один. Делаю
Тогда должен понимать, меньше всего нужно надеяться на людей. Люди это самый ненадежный фактор.
_>Ты меня совсем не понял Я не о правилах хорошего тона Я о тех механизмах ОС которые делают возможной работу всех программ. О менеджере памяти, о планировщике задач, и т.д. и т.п. все эти механизмы работают для того чтоб было возможно в том числе и переключение задач, приостановка потоков и т.д.
Это все технические детали.
_>И для того чтобы сделать отмену и приостановку придётся в полном объеме создать аналогичные механизмы, что по сути выльется в отдельную ОС
Нет. У тебя же не процесс ОС, а всего один объект. С ним можно жить куда проще и куда эффективнее.
_>А кто считает что он беден
Ну, вообще-то он конечно бедноват.
VD>> в котором для тебя нет возможности вмешаваться в уже написанный код.
_>Как раз на С++ это возможно, но я уже раньше сказал своё мнени по этому поводу.
Очень слабо и очень неудобно.
_>Давай чтобы не быть голословным ты напишешь такой код который, будет корректно отменять или приостанавливать любой другой код? (конечно же на современном языке, на том на котором это элементарно делается )
Я тебе лучше предложу поглядеть на то как рабатают итераторы (те что используют yield). Они позволяют в некоторой точке остановить управление (выйти из функции), а протом начать выполнение с того же места (вернуться в ту же функцию). Делается это путем переписывания кода в конечный автомат. Примерно так же можно создать более серьезное "продолжение".
_>Полностью с тобой согласен Всё это элементарно делается, всего лишь надо написать свою ОС Да и зачем писать... Чем тебе процессы ОС не живые объекты
Ты удивишся, но как минимум в двух языках это уже сделано. Один называется Эрлэнг, а второй Эктив Оберон. Думаю, что есть и другие реализации менее известные.
_>Вот видишь сколько ограничений приходится накладывать на код живого объекта
Дык ограничения то будут остслеживаться автоматом. Ведь ты или будешь иметь ресурсы внутри активного объекта, или обращаться к другим активным объектам. Ошибиться туб невозможно.
_>А там ниже ещё ограничения... Плюс у каждого активного объекта должен быть свой пул памяти и многие другие вещи.
Не. Никакого пула не надо. Опять же если это не С++. В безопасных языках память испорчена быть не может. И лишние ссылки тоже невозможны. Так что можно сделать изолированный объект в разделяемой куче.
_> Т.к. память вполне может быть тем разделяемым ресурсом который должен инкапсулироваться в активном объекте.
Не не может. Опять же если это не С++ с его адресной арифметикой.
Почитай про Сингулярити. Там как раз очень хорошо описана похожая концепция.
VD>>Так что произойдет одно из двух. Или ты и такие как ты (ких миллионы) перестроишь свое сознание и перестанишь жить догмами современных (точнее устаревших) API и догмами C/C++, или ваши программы будут сплашным багодромом не способным серьезно маштабироваться на многопроцессорной технике.
_>Чего ругаешься?
Гду:
_>А ты не замечаешь что ты говоришь о томже что и я но другими словами?
Нет. Ведь я подразумеваю, что программисту использующему это дело не прийдется ничего контролировать врунчую. И ошибиться ему будет не где.
_>более того я с тобой соглашаюсь что в принципе это возможно, но эта работа по трудоёмкости сравнима с написанием не худшей из ОС.
Работа не простая. Но ты преувеличиваешь. Все же при наличии соотвествующих средств это вполне подемная задача. Вот только язык обязан быть безопасным и нужны мощьные средтсва метапрограммирования.
_> А это мне не по плечу и сомневаюсь что тебе по плечу даже если ты будешь для этого пользоваться перестроенным сознанием и неустаревшими языками
Ну, там поглядим...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ValeraI, Вы писали:
VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет?
Какая разница? Много лет назад самым востребованным был Фортран... Потом его сменил PL/I. Потом появился С, потом С++... А в России Турбопаскаль... А потом Object Pascal в составе Дельфей...
Так что — выводы делай сам... VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
Не... высоко оплачивается не знание языка... Я б сказал — общепрограммерская культура... Посмотри на Книта! Его общепрограммерская культура — чрезвычайно высока... Соответственно и опрлата...
Успехов в повышении собственной общепрограммерской культуры...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, ValeraI, Вы писали:
VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет?
Я думаю принципиально расстановка "сил" не изменится в ближайшие лет пять.
На Windows платформе основными языками будут как и сейчас C#, VB.NET и Java, свою нишу и
C++ будет иметь, вряд ли Nemerle получит первостепенное распространение, потому что, в отличие от перехода
(C++ & Java) --> C#, потребует более серьёзного переучивания для эффективной работы.
На Unix/Linux/*BSD платформе разнообразие гораздо сильнее и самым основным, наверное останется
C и C++, затем Python и остальных более-менее поровну: где Perl, где Ruby, Java, Mono(C#) и прочие. VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
Ассемблер, Lisp, Ada, Eiffel, Erlang -- как и сейчас, если найдут работу с ними связанную.
