Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет?
Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
Здравствуйте, ValeraI, Вы писали:
VI>Не ради флейма, а ради выслушивания разных мнений
VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет? VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
VI>>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет? VI>>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
SH>Китайский
ответ не оригинальный и к сожалению не на мой вопрос
VI>Не ради флейма, а ради выслушивания разных мнений
VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет? VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
Nemerle
А если серьезно — скорее всего императивный язык с большим количеством "сахара", который сейчас присутствует лишь в функциональных языках — функции высшего порядка, замыкания, сопоставление с образцом, list comprehensions (как они по-русски, кстати?). То есть, Немерле
Ну и, мне кажется, будут облегчаться принципы и приемы разработки многопоточных приложений (возможно — в сторону чего-то, похожего на Эрланг).
M>А если серьезно — скорее всего императивный язык с большим количеством "сахара", который сейчас присутствует лишь в функциональных языках — функции высшего порядка, замыкания, сопоставление с образцом, list comprehensions (как они по-русски, кстати?). То есть, Немерле
M>Ну и, мне кажется, будут облегчаться принципы и приемы разработки многопоточных приложений (возможно — в сторону чего-то, похожего на Эрланг).
Не соглашусь, думаю единого языка не будет, также как и сейчас. Всёже специфика очень влияет
Тот же Эрланг для гуя ну не тот инструмент.
Здравствуйте, ValeraI, Вы писали:
VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет?
Тот который поддержит какой-нить гигант, типа микрософт.
VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
Боюсь, что знание языка для того чтобы быть высокооплачиваемым — далеко не самая главная вещь.
Здравствуйте, ValeraI, Вы писали:
SH>>Китайский
VI>ответ не оригинальный и к сожалению не на мой вопрос
Вопрос примерно такой же оригинальный. А как оведут до ума голосовое управление и прочий искуственный интеллект, так и программировать на нём можно будет.
L>>Боюсь, что знание языка для того чтобы быть высокооплачиваемым — далеко не самая главная вещь
VI>Само собой... Но если знаешь ни кому не нужный язык очень хорошо то что?.
Ничего страшного, главное чтобы человек был хороший (с головой дружил), а все остальное придожится.
P.S. А какой по-твоему самый восстребованый язык сейчас?
H>Вопрос примерно такой же оригинальный. А как оведут до ума голосовое управление и прочий искуственный интеллект, так и программировать на нём можно будет
Здравствуйте, ValeraI, Вы писали:
VI>Само собой... Но если знаешь ни кому не нужный язык очень хорошо то что?.
Не существует "никому не нужных языков". Вопрос в размере рынка. И это палка о двух концах — рынок большой — легко устроиться на работу — но тебя и заменить не сложно, второй парень с улицы тоже пишет на этом языке. Может и похуже, но тем не менее.
Рынок маленький — узкая специализация, но зато ты такой один
H>Не существует "никому не нужных языков". Вопрос в размере рынка. И это палка о двух концах — рынок большой — легко устроиться на работу — но тебя и заменить не сложно, второй парень с улицы тоже пишет на этом языке. Может и похуже, но тем не менее.
SH>Рынок маленький — узкая специализация, но зато ты такой один
Это всё понятно, но мне всеголишь нужны Ваши ответы на мои вопросы...
Здравствуйте, ValeraI, Вы писали:
VI>Не ради флейма, а ради выслушивания разных мнений
VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет? VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
Если бы можно было это узнать, мы бы всей планетой дружно этим бы языком и занялись .
Нельзя так твёрдо решать. Задачи разные, средства разные.... В будущем разнообразие задач, думаю, увеличится. Так что для начала Вы определитесь в какой области хотите развиваться. Программирование оно тоже разным может быть.
Здравствуйте, ValeraI, Вы писали:
VI>Не ради флейма, а ради выслушивания разных мнений
VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет?
Java, C#, C++, возможно что-нибудь немного экзотическое, типа Nemerle.
VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
Java
А если серьёзно: самыми востебоваными и высокооплачиваемыми специалистами будут те, которые будут программировать на ещё не созданных языках и приэтом с опытом работы от 2-х лет именно на этом языке.
Думаю, через несколько лет появится что-то немного необычное — уже пора, и все сразу на это бросятся. А вот на какой платформе это будет? На Windows наверное и .NET... Ну или Sun что-то придумает.
Здравствуйте, Udjine, Вы писали:
U>Здравствуйте, ValeraI, Вы писали:
VI>>Не ради флейма, а ради выслушивания разных мнений
VI>>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет? VI>>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
U>Если бы можно было это узнать, мы бы всей планетой дружно этим бы языком и занялись .
U>Нельзя так твёрдо решать. Задачи разные, средства разные.... В будущем разнообразие задач, думаю, увеличится. Так что для начала Вы определитесь в какой области хотите развиваться. Программирование оно тоже разным может быть.
U>А главное — будте здоровы!
и Вам того же
Всегда любил людей которые отвечают на собой же придуманные вопросы....
Здравствуйте, Mamut, Вы писали:
M>Ну и, мне кажется, будут облегчаться принципы и приемы разработки многопоточных приложений (возможно — в сторону чего-то, похожего на Эрланг).
Эрэнгом мы займемся после интеграции Немерле в Студию. Точнее попробуем реализовать похожую на него идеологию параллелизма. Правда для гибридных языков наверно вместо процесса разумнее будет использовать идеологию активных объектов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ValeraI, Вы писали:
К>>Не соглашусь, думаю единого языка не будет, также как и сейчас. Всёже специфика очень влияет К>>Тот же Эрланг для гуя ну не тот инструмент.
VI>Уточню: я не настаиваю на одном языке можно несколько
На самом деле тебе действительно назвали самые перспективные языки. Не факт, что именно они станут популярными в будуещм. Но 95% того что будет в популярном языке будущего в них уже есть сейчас. Причем Немерле это представитель статически-типизированного языка (правда с компонентной базой), а Эрлэнг динамически-типизированного (другими словами скрипта). Так что как раз охватишь два лагеря которые будут бадаться между собой еще довольно долго.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Эрэнгом мы займемся после интеграции Немерле в Студию. Точнее попробуем реализовать похожую на него идеологию параллелизма. Правда для гибридных языков наверно вместо процесса разумнее будет использовать идеологию активных объектов.
Уже занялся... (Мне для местного IDL лексер и понадобился) Прототипчик сделаю на немерле, а потом буду портировать на С++ и жабу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mamut, Вы писали:
M>>Ну и, мне кажется, будут облегчаться принципы и приемы разработки многопоточных приложений (возможно — в сторону чего-то, похожего на Эрланг).
VD>Эрэнгом мы займемся после интеграции Немерле в Студию. Точнее попробуем реализовать похожую на него идеологию параллелизма. Правда для гибридных языков наверно вместо процесса разумнее будет использовать идеологию активных объектов.
Простите, немого оффтопик. А что у него за за идеология параллелизма? (если есть нормальная ссылка, на русском или английском)
P.S. Если я правильно понимаю, идеология активных объектов подразумевает 1 поток на 1 объект. Это неудобно: фактически в этой идеологии перекрещиваются архитектура и совершенно технические особенности распараллеливания — это мешает. Лучше дать возможность определять зависимость по данным, может быть даже динамически. Т.е. что бы объекты сами определяли, что необходимо для выполнения их метода и автоматически ждали (и определяли) нужные события.
Здравствуйте, ValeraI, Вы писали:
VI>Не ради флейма, а ради выслушивания разных мнений VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет?
Языко-ориентированное программирование выглядит многообещающе. В то же время, приход таких языков сведет к минимуму потребность в програмиистах: значительная часть работы перейдет к экспертам в предметной области.
Одна из тем, которая постоянно всплывает в рассуждениях о языкоориентированном программировании — дать возможность непрофессионалам самим писать код. Всевозможные эксперты в различных предметных областях могли бы программировать, используя соответствующие DSL.
Впрочем, пока денежные монстры не уделят ЯОП должного внимания, рядовому программисту преждевременно дрожать за свое место.
На мой взгляд востребованность языков программирования через пару лет не потерпит каких-либо изменений. Однако сместится на требования, к этим языкам. Кроме DSL и метапропрограммирования, сейчас интерес представляет собой распараллеливание. Герб Саттер, например, активно работает для продвижения этих механизмов в стандарт С++. Вот тут можно посмотреть/послушать его лекцию на эту тему: The Free Lunch Is Over
Здравствуйте, ValeraI, Вы писали:
VI>Не ради флейма, а ради выслушивания разных мнений
VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет?
Гибридные функционально-ОО языки, с возможностями расширения (например, Nemerle,Scala).
Писал также здесь: Re[3]: Почему у Nemerle есть будущее :)
Ну и я думаю Java никуда не денется, ибо на ней уже очень много написано.
VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
От языка не зависит. Рядовые программисты вообще не высокооплачиваемые. Высокооплачиваемые — грамотные архитекторы, создатели алгоритмов
и специалисты в тех предметных областях, в которые идут активные инвестиции,(финансы, биотех) с навыками программирования.
Язык там уже второстепенную роль играет.
Здравствуйте, FDSC, Вы писали:
FDS>Простите, немого оффтопик. А что у него за за идеология параллелизма? (если есть нормальная ссылка, на русском или английском)
Поищи в Декларативном программировании.
FDS>P.S. Если я правильно понимаю, идеология активных объектов подразумевает 1 поток на 1 объект.
Не обязательно. Можно для каждого объекта создавать облегченный поток. Другими словами использовать кооперативный ражим. Эрланк вообще-то не ООЯ так что активный объект — это условно. Там это назвается не объектами, а процессами (хотя тут тоже будет путанница так как это виртуальные процессы и к процессам ОС они отношения не имеют). Между процессами обмен ведется только посредством сообщений. Память у каждого процесса иззалированная.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, SergH, Вы писали:
SH>Вопрос примерно такой же оригинальный. А как оведут до ума голосовое управление и прочий искуственный интеллект, так и программировать на нём можно будет.
Ну тогда сразу появится SkyNet и устроит массовую охоту на людей. Так что надо не тратить зря время, и начинать изучать автомат Калашникова и взрывное дело прямо сейчас
Здравствуйте, ValeraI, Вы писали:
VI>Не ради флейма, а ради выслушивания разных мнений
VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет? VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
Думаю все-таки рано или поздно это станет Nemerle или его подобие (Microsoft же известна любовью для всего делать свою версию). Его несомненное достоинство в этом плане, это то что на нем можно писать традиционно — серии простых команд, как на C#, он не делает старые учебные программы бесполезными — можно взять книжку по Паскалю 90-х годов и словарь-памятку Pascal->Nemerle и изучать программирование как обычно, при этом в будущем будет огромный простор для развития в пределах этого же языка.
Здравствуйте, ValeraI, Вы писали: VI>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет?
Несколько разных. VI>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет?
Языки не будут высокооплачиваемыми. Высокооплачиваемыми бывают программисты. При этом стать высокооплачиваемым при знании какого-то одного языка шансов у программиста нет. Потому, что высокооплачиваемость определяется не столько знанием языка, сколько умением правильно понять задачу, достаточно точно оценить срок ее реализвции и реализовать с хорошим качеством. Как пишет Спольски, надо быть "smart and get things done".
К сожалению, одного этого недостаточно. Очень уж немногие компании/руководители берут на себя заботу о том, чтобы все "smart and get things done" программисты были высокооплачиваемыми. Так что нужно еще и умение себя продавать. Примерно как здесь.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ValeraI, Вы писали:
L>>Ничего страшного, главное чтобы человек был хороший (с головой дружил), а все остальное придожится.
VI>Правильно приложится в том числе и правильный язык вот я о нём и спрашиваю
"Правильный язык" для решения какой задачи ?
... << RSDN@Home 1.1.4 PINK FLOYD — Shine On You Crazy Diamond (Part Two) >>
Здравствуйте, VladD2, Вы писали:
VD>Эрэнгом мы займемся после интеграции Немерле в Студию. Точнее попробуем реализовать похожую на него идеологию параллелизма. Правда для гибридных языков наверно вместо процесса разумнее будет использовать идеологию активных объектов.
В чём принципиальная разница? ООП-ориентация или как?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>Эрэнгом мы займемся после интеграции Немерле в Студию. Точнее попробуем реализовать похожую на него идеологию параллелизма. Правда для гибридных языков наверно вместо процесса разумнее будет использовать идеологию активных объектов. WH>Уже занялся... (Мне для местного IDL лексер и понадобился) Прототипчик сделаю на немерле, а потом буду портировать на С++ и жабу.
Для явовской машины уже есть реализация на Scala, о чём я писал тут.
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Здравствуйте, ValeraI, Вы писали:
VI>>Не ради флейма, а ради выслушивания разных мнений VI>>Как Вы считаете, какой язык программирования будет самым востребованным через несколько лет?
АК>Языко-ориентированное программирование выглядит многообещающе. В то же время, приход таких языков сведет к минимуму потребность в програмиистах: значительная часть работы перейдет к экспертам в предметной области.
Знаешь, это очень напоминает лозунги когда начали делать языки 4-го уровня, тот же SQL или ABAP/4 у сапа — речь шла ну в точности об этом, что запросы и т.п. будут делать сами бухгалтера, а не программисты. Результат, думаю, ты знаешь
VD>Эрэнгом мы займемся после интеграции Немерле в Студию. Точнее попробуем реализовать похожую на него идеологию параллелизма. Правда для гибридных языков наверно вместо процесса разумнее будет использовать идеологию активных объектов.
оффтоп полный, но...
Я не давно реализовал шаблонную библиотеку на С++ которая позволяет любой объект превратить в живой. Имеется три сферы обитания:
1. Отдельный поток для каждого объекта класса.
2. Все объекты одного типа живут в общем потоке.
3. Все объекты живут в главном потоке приложения.
Скоро напишу комментарии человеческие в коде и выложу
VI>>Как Вы считаете программисты знающие какой язык (языки) программирования будут самыми высокооплачевыеми через несколько лет? АХ>От языка не зависит. Рядовые программисты вообще не высокооплачиваемые. Высокооплачиваемые — грамотные архитекторы, создатели алгоритмов
Здравствуйте, gid_vvp, Вы писали:
_>Я не давно реализовал шаблонную библиотеку на С++ которая позволяет любой объект превратить в живой. Имеется три сферы обитания: _> 1. Отдельный поток для каждого объекта класса. _> 2. Все объекты одного типа живут в общем потоке. _> 3. Все объекты живут в главном потоке приложения.
_> Скоро напишу комментарии человеческие в коде и выложу
у меня чуть по скромнее и задачи немного наверно не такие решаются.
2100 примерно
Моя библиотека позволяет любой класс сделать живым (активным) т.е. его объекты будут полностью жить в отведённой им облости обитания (отдельном потоке, общем потоке для одного типа объектов, общем потоке для нескольких типов объектов, в главном потоке приложения ) и все действия с ними в том числе создание и уничтожение будет происходить в их собственной среде обитания, причём с наружи этим живым объектом можно пользоваться точно так же как и его прототипом (объектом класса который был сделан живым с помощю бидлиотеки), за исключением того что функции члены можновызывать в двух (пока) режимах в синхронном и асинхронном. Т.е. при синхронном использовании он неотличим от своего прототипа, за исключеним того что все функции ваполняются в области где живёт данный объект.
Для того чтобы обычный класс превратить в живой нужно очень мало усилий:
это класс который мы хотим сделать живым
class A
{
public:
A(int arg);
A(int arg1, int arg2);
int f1(std::string str);
void f2(int arg);
}
а это он же но живой
class Active
{
public:
Active(int arg)
: m_Active(arg)
{
}
Active(int arg1, int arg2)
: m_Active(arg1, arg2)
{
}
int f1(std::string str)
{
return m_Active.CallSync(&A::f1, str);//Cинхронный вызов
}
void f2(int arg)
{
m_Active.CallAsync(&A::f2, arg);//Асинхронный вызов
}
private:
AOTL::ActiveObjectProxy<A, AOTL::SharedThread<A, std::exception> > m_Active;// данный живой объект живёт в общем потоке
//AOTL::ActiveObjectProxy<A> m_Active;// данный живой объект живёт в своём отдельном потоке
}
использование
A a(1);//конструктор выполняется прямо тут
Active aa(1);//конструктор выполняется в области обитания живого объектаint i = a.f1("str");//выполняется прямо тут
i = aa.f1("str");//выполняется в области обитания живого объекта, а сюда возвращается результат (этот поток ждёт пока не придёт результат)
a.f2(1);//выполняется прямо тут
aa.f2(1);//выполняется асинхронно в области обитания живого объекта (этот поток не ждёт )
Здравствуйте, Курилка, Вы писали:
К>В чём принципиальная разница? ООП-ориентация или как?
В догмах. Точнее их отсуствии. Зачем изобретать дебильные вещи вроде словарей процесса (одна терминология чего стоит!), если можно просто позволить объявлять поля?
В Немерле нет догматов вроде "нельзя изменять перменные". Зато в нем есть классы и объекты. Так почему бы их не исползовать.
Данные можно передавать в виде вариантов и сериализуемых объектов. Синхронизацию обеспечить простой очередью. А легкие потоки организовать за самим. Будет ни хуже чем в Эрланге, но с полноценным компилтором и IDE. Кому хочется может писать чисто функциональные вещи не держа состояние в объекте. Кому не хочется может хранить состояние.
Конечно там много чего надо продумывать, и много проблем надо решать. Одна из главных пожалуй — это как отнимать управление у методов активного объекта? Ждать пока они завершат работу (чистый кооператив), или все же изобретать сложное переписывание кода а-ля продолжения (континюэшоны)? Но тем не менее все это решаемо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gid_vvp, Вы писали:
_>Я не давно реализовал шаблонную библиотеку на С++ которая позволяет любой объект превратить в живой. Имеется три сферы обитания: _> 1. Отдельный поток для каждого объекта класса. _> 2. Все объекты одного типа живут в общем потоке. _> 3. Все объекты живут в главном потоке приложения.
Примерно об этом и идет речь, но ты не гарантируешь что из твоего объекта кто-то не заполучит прямой доступ к другим. А тут это гарантируется. Плюс у тебя наверняка не решена проблема отема управления у методов активных объектов и возобновления их исполнения с того же места.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Знаешь, это очень напоминает лозунги когда начали делать языки 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 -- как и сейчас, если найдут работу с ними связанную.
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С тоже крутят не бухгалтеры, а особый тип людей — что-то между
программистами и бухгалтерами.
1.1.4 stable rev. 510
