A>>Вот здесь небольшая загвозка. Что если мне не нужен результат прямо сейчас. Могу я не ждать возвращения результата, а продолжать исполнение до тех пор, пока где-то в будущем мне действительно не понадобится результат, и тогда я уже подожду если нужно (а может быть к тому времени он уже будет готов, и ждать не прийдётся)?
_>Да, такая возможность есть. Можно установить callback в который будет возвращёи результат, либо воспользоваться специальным классом который принимает отложенный результат и может сказать пришёл результат или ещё нет
Звучит как типичная асинхронная модель. Она плоха тем, что излишне трудоемка. Мне больше нравятся futures, которые в этом смысле гораздо легче использовать.
VD>Тогда должен понимать, меньше всего нужно надеяться на людей. Люди это самый ненадежный фактор.
Уже говорил если человек захочет что то сломать он это сделает, на любом языке.
<вырезано переливание из пустого в порожнее >
_>>Давай чтобы не быть голословным ты напишешь такой код который, будет корректно отменять или приостанавливать любой другой код? (конечно же на современном языке, на том на котором это элементарно делается )
VD>Я тебе лучше предложу поглядеть на то как рабатают итераторы (те что используют yield). Они позволяют в некоторой точке остановить управление (выйти из функции), а протом начать выполнение с того же места (вернуться в ту же функцию). Делается это путем переписывания кода в конечный автомат. Примерно так же можно создать более серьезное "продолжение".
Ну что ты заладил? Что по твоему этот yield?
_>>Полностью с тобой согласен Всё это элементарно делается, всего лишь надо написать свою ОС Да и зачем писать... Чем тебе процессы ОС не живые объекты
VD>Ты удивишся, но как минимум в двух языках это уже сделано. Один называется Эрлэнг, а второй Эктив Оберон. Думаю, что есть и другие реализации менее известные.
Чего тут удивлятся?
Думаю не мало сил было потрачено на эрланг...
_>>Вот видишь сколько ограничений приходится накладывать на код живого объекта
VD>Дык ограничения то будут остслеживаться автоматом. Ведь ты или будешь иметь ресурсы внутри активного объекта, или обращаться к другим активным объектам. Ошибиться туб невозможно.
_>>А там ниже ещё ограничения... Плюс у каждого активного объекта должен быть свой пул памяти и многие другие вещи.
VD>Не. Никакого пула не надо. Опять же если это не С++. В безопасных языках память испорчена быть не может. И лишние ссылки тоже невозможны. Так что можно сделать изолированный объект в разделяемой куче.
просто смех
пусть у тебя есть супер безопасный язык, но куча одна общая. как ни крути а память надо выделять пусть неявно, т.к. язык у нас супербезопасным и программисту этого делать низя. Итак гдето понадобилось выделить память, наш супербезопасный язык гдето в глубине своей безопасности обращается к куче ставит лок и всё баста приехали. Нужно чтоб этот супербезопасный язык поддерживал концепцию живых объектов иначе кина небудет А это другая история... То же что и написание ОС. А ещё можно для живых объектов сделать специальную среду выполнения в которую будет включатся интерпретатор специального языка на котором и будут писаться код этих живых объектов. А что тоже неплохой вариант, среда сможет всё контролировать и даже переписывать если надо
VD>Почитай про Сингулярити. Там как раз очень хорошо описана похожая концепция.
_>>Да, такая возможность есть. Можно установить callback в который будет возвращёи результат, либо воспользоваться специальным классом который принимает отложенный результат и может сказать пришёл результат или ещё нет
A>Звучит как типичная асинхронная модель. Она плоха тем, что излишне трудоемка. Мне больше нравятся futures, которые в этом смысле гораздо легче использовать.
Я тут немного посмотрел про futures, оказывается это тоже самое что и
либо воспользоваться специальным классом который принимает отложенный результат и может сказать пришёл результат или ещё нет
работает почти также
я офигиваю, который раз изобретаю то что уже изобретено
Здравствуйте, Sinclair, Вы писали:
S>Очень уж немногие компании/руководители берут на себя заботу о том, чтобы все "smart and get things done" программисты были высокооплачиваемыми. Так что нужно еще и умение себя продавать.
Это очень распространенное заблуждение, которое обычно проистекает от неумения менеджмента оценивать реальный ход работы в проектах. Потому что когда уходят недооплаченные хорошие специалисты, а остаются переоплаченные плохие — страдает от этого в первую очередь компания.
Здравствуйте, ValeraI, Вы писали:
VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет?
Востребованным где? Не бывает технологий, востребованных "вообще". Где-то, где совсем плохо — 1С очень востребован. Где-то — Java, в параллельном мире — C#. Ещё один мир, не пересекающийся ни с одним из перечисленных, и знать ничего не желает про существование языков, отличных от кастрированных диалектов Си и Форта — и в этом мире встраиваемых железяк крутятся огромные деньги, такие, что и не снились пописывающим на Жабе банкирам.
VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
Программисты, знающие язык математики. Все остальные языки — это жалкие, мелкие частности, не достойные упоминания.
Здравствуйте, Курилка, Вы писали:
К>Знаешь, это очень напоминает лозунги когда начали делать языки 4-го уровня, тот же SQL или ABAP/4 у сапа — речь шла ну в точности об этом, что запросы и т.п. будут делать сами бухгалтера, а не программисты. Результат, думаю, ты знаешь
Все знают результат. Сидят тысячи совсем нисколько не программистов, а вовсе даже бухгалтеров, и пишут под 1С или тот же ABAP.
Kolhoz wrote: > Все знают результат. Сидят тысячи совсем нисколько не программистов, а > вовсе даже бухгалтеров, и пишут под 1С или тот же ABAP.
Агащаззззз. В случае с SAP сидят десятки специалистов, которые знают в
каком файле с исходником стоит нужный комментарий на немецком
языке, который включает нужную опцию.
1С тоже крутят не бухгалтеры, а особый тип людей — что-то между
программистами и бухгалтерами.
>
Да и зачем писать... Чем тебе процессы ОС не живые объекты 
