за каким языком программирования будущее

[monrus]

Мой братишка решил изучать Delphi, но ему сказали, что Delphi устаревает и что лучше изучать Java и что все переходят на него. Хотелось бы узнать за каким языком программирования будущее. Что лучше изучать на перспективу, чтобы в будущем не остаться без работы?

[Alf]

Будущее - за тем языком, который придумают в будущем.

За недолгую (в сравнении с другими науками порядка полвека - юный возраст) историю информатики нам поочередно обещали, что в этот раз дадут истинно универсальный инструмент, на котором будет делаться все - от бухгалтерии до искусственного интеллекта. В моде поочередно побывали FORTRAN, COBOL, Algol, Pascal, Modula-2, C, C++... Большие авансы раздавал Prolog. Подобно эпидемии чумы пронесся FORTH (и подобно чуме, кажется, ныне побежден практически повсюду). (Вроде никого вниманием не обошел?) И, открывая учебник очередного языка, программисты радостно улыбались, что теперь-то уж точно учатся в последний раз.

Сегодня в моде Java и C#. Первый мобилен, всеяден и в настоящий момент свободен от влияния Microsoft (что немаловажно в глазах тех, кто страдает этой фобией). Второй выразительнее в некоторых аспектах и, помимо этого, опирается на многообещающую платформу .NET. Ближайшие несколько лет пройдут, видимо, под знаком конкуренции этих довольно близких по идеологии языков. Что будет дальше, не скажет даже Нострадамус.

Если парень хочет действительно стать профессионалом в программировании, ему не следует зацикливаться на каком-либо языке. Во-первых, профессионал владеет несколькими и может для данной задачи выбрать более подходящий язык (ибо действительно универсального языка до сих пор не придумали, как бы ни старались в этом убедить рекламные лозунги). Во-вторых, в основном различие между многими (но не всеми) языками стирается, и ни один не имеет подавляющего превосходства на другими. Поэтому понравился ему Delphi - пусть его и учит. В конце концов Вирт для того и придумал Pascal, чтобы учить информатике, а уж его школа не из слабых.

Единственное, что действительно можно изучить на перспективу, - это теория. Владение математическим аппаратом и знание базовых алгоритмов сослужит программисту добрую службу на долгое время, каким бы инструментом он не пользовался в данный момент. Недавно на форуме обсуждалась подобная тема, там npak привел практически полный перечень знаний, к обладанию которыми следует стремиться профессионалу.

[npak]

monrus,

пусть учит язык той области, в которой хочет работать.  А ещё лучше -- несколько языков Насколько я понимаю, сейчас в коммерческом программировании в Росси используются Java, C#, C++, Delphi, Visual Basic.

Помимо языков стоит освоить методы их применения. Сейчас в фаворе объектно-ориентированные языки, поэтому необходимо учиться объектно-ориентированному проектированию. Какой язык использовать -- вопрос второй (если выбирать из предложенной выше обоймы языков, то я рекомендовал бы Java -- стройность языка, встроенная сборка мусора и очень богатый  набор библиотек существенно облегчат учёбу, ИМХО).

Помимо языков есть ещё технологические платформы, такие как COM/DCOM, CORBA, EJB, .NET.  Работа с базами данных широко встречается в коммерческом программировании (ODBC/OLE/ADO). Много-потоковое и программирование тоже встречается довольно часто.  Знание, что такое XML, и как с ним работать также приветствуются.

Для общей грамотности квалифицированному программисту стоит знать, что такое операционная система, файловая система, как работает сеть и основные протоколы сетевого обмена (хотя бы на уровне знания что такое протоколы с установлением соединения и без установления соединения). 

В этом посте я хотел донести мысль, что современное программирование строится вокруг идей, платформ и средств.  Идеи и средства приблизительно равноценно представлены в современных языках, поэтому выбирать надо из соображений удобства изучения идей. 

Если бы я сейчас начинал учиться программированию, то выбрал бы Java, по множеству причин (на самом деле я бы выбрал бы Ada, но это от большого ума ). 

Что касается Delphi, то складывается впечатление, что Delphi потихоньку вытесняется C#, но это процесс не быстрый.

[xelos]

хотелось бы добавить: в коммерческом программирование требуется знание архитектур бизнес-приложений. Архитектуры типа n-tiers и в целом распределнные приложения, не стоит забывать и объектное моделирование - UML. На данный момент очень большим спросом пользуется Java, причем J2EE, однако C# и VB.NET их догоняют достаточно быстро (по уровню спроса). Все что для платформы .НЕТ идет в связке с ASP.NET (это в основном для поддержки Web Services).

В общем, заключение такое, что сейчас требуются специалисты, способные писать бизнес-приложения. Просто программисты, например под винду, на С++ пользуются намного меньшим спросом чем 4-5 лет назад. Однако появляется спрос на програмистов, способных переписать приложение с VC++ на C#.

Без знания платформ и архитектур программист уже не считается программистом

[LP]

Недавно на форуме обсуждалась подобная тема, там npak привел практически полный перечень знаний, к обладанию которыми следует стремиться профессионалу.

npak, был бы очень признателен если бы ты еще раз повторил этот список или
дал ссылку на ту тему (если с ней ничего не случилось).

извините что вмешался   

[Гром]

Хотелось бы уточнить, что

архитектур бизнес-приложений. Архитектуры типа n-tiers и в целом распределнные приложения, не стоит забывать и объектное моделирование 

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

Как по мне, так учите Ассемблер - всегда будет актуален, спросите какой - отвечу учите принцип - диррективы будут меняться - а людей понимающих различие между add в 32 и 64 битных системах все меньше и меньше...

[xelos]

ГРОМ, согласен, я просто хотел указать, что сейчас спросом требуются программисты которые владеют языками программирования и архитектурами. Причем последнее - обязательное требование.
Дискуссию по поводу конкретного языка программирования для какой-то платформы/архитектуры - отдельный топик.

Кстати, если знаешь только ассемблер - востребованность, имхо, не такая уж и высокая. К тому же ассемлер не позволяет абстрагироваться от платформы. С/С++ - много больше выигрывают в этом плане, можно писать код как для микроконтроллера, так и для проца компутера, dsp без особых изменений. Чего не скажешь об асме.

[Alf]

npak, был бы очень признателен если бы ты еще раз повторил этот список или
дал ссылку на ту тему (если с ней ничего не случилось).

извините что вмешался

Я, правда, не npak, однако мне на глаза попалась эта тема, решил кинуть ссылку на нее: https://forum.shelek.ru/index.php/topic,5584.0.html

[LEON]

Возможно меня сейчас запинают, но я могу добавить, что уже на сегодняшний день возможно построение готового решения, обходя стороной процесс кодирования, кто видел WebSphere поймет, о чем я говорю. По этому, как мне кажется, будущее не за языками программирования, а за их более высокими надстройками. Хотя, для того что бы заниматься разроботкой подобных решений широкий кругозор совсем не помешает. Не будет лишним, и все вышеперечисленные знания, принципы и технологии. Я еще не встречал, человека, который бы работал в области ИТ и говорил, что ему помешало изучение например Паскаля.

[Гром]

xelos - я собственно немного шутю или правильнее сказать утрирую

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

1. Программинг под Виндовс. (Включает в себя несколько подразделов)
а) программинг в средеVisual Studio (технологии .NET, ASP MSSQL )
б) программинг конкретно в VC++ когда разговор идет тоже не совсем о языке, хотя стандарты С++ в основе своей поддерживаются - пишешь в основном на API в синтакисисе С++.
в) программинг в среде сторонних фирм для Виндовс (Дельфи Ворланды и т.д.)

2. Программирование под настольные (Desktop) системы не от монстра.
В этом деле тоже куча API если речь идет о таких системах как Линукс - Юникс, в которых есть графическая среда или же речь идет ТОЛЬКО о С - С++ для которых есть бесплатные компиляторы типа gcc.

Для таких систем есть и Киликс, и скажут что можно писать и на Паскале, но если найдется смельчак утверждающий что знает Линукс (Юникс) и не знает С++ - боюсь что засмеют.

3. Программинг для систем типа Embeded - любогго типа - в данном случае я включаю сюда и Real-Time системы и черные коробки закрытого типа для любого предназнчения и просто работа с приборами не Real-Time хотя таких мало...

Все такие системы изначально поставляются с компиляторами и (или) средами для С С++. Не видел ни одного другого языка написанного для таких систем.

4. Программинг под системы BILLING и БД. Все они объединяются в систему - которая зависит от направления самой СУБД и реализации ODBC - точнее OEM от производителя...
Тут огромный простор для фантазии. Есть в употреблении и Оракл, и .NET  и SQL-и всякие - куча такого рода сред (языков управления данными или технологий) которые надо знать и с которыми уметь работать...

5. Отмирающие среды и языки - которые необходимы ЕЩЕ для поддержки старого программного обеспечения и переписывания его на новые рельсы.
Это системы таки фирм как Amdocs и (или) системы заводские, контроль над процессами включая системы Real-Time управления поточными линиями, на крупных предприятиях.
Там нужны такие языки и среды как ADABAS, PL/1, Фортран, Алгол и огромное множество других.

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

1. Майкрософт. Его направления и техноогии во всем мире будут в ближайшие 10-15 лет востребованы и в огромных колличествах. От С# до банального VB. Если выбирать это направление, то учить надо не столько (вернее не только) сам язык, сколько технологию в целом. Убеждался не раз, что человек вполне нормально работающий в крупной фирме под средой VB понятия не имеет о указателях и бинарных данных с которыми оперирует, для него все это скрыто.
Именно в этом направлении и есть возмрожность уйти от программирования как такового, и скоро вообще от написания кода в виде прямого создания алгоритма. Визарды и всякое подобное окрудение будет создавать нужный костяк приложения, а программист будет вставлять в нужные заранее указанные или определенные точки куски кода для выполнения действий. Если ЛЕОН о таком программинге, то да такое направление выражено очень четко....

2. Вторая часть программинга, ближе к работе железа, скорее даже не только железа, а к работе прибора в его индивидуальном назначении. При всей похожести систем реального времени и систем Embeddedd, в каждой из них есть свое отличие и некая изюминка.
Для таких систем, а так же для протоколов связи, робототехники, программирования для железа (драйвера от которых даже Майкрософту не уйти) для систем новых заводов и крупных предприятий, стоит учить С и С++. В этом случае даже не зная ОС на которой строится вся система, достаточно выучить API конкретной задачи или даже самому его написать, а язык для этой части систем не изменится....

Дополнение.
При всей своей любви к Паскалю в свое время и понимая, что в принципе любому языку такого уровня продуманности всегда найдется ниша, считаю направления Дельфи - Киликс, Борланд, и другие надстройки в другого типа языках оторванных от производителя ОС нерентабильными. Более того, предрекаю им не скорую, а долгую и мучительную жизнь с постепенным неотвратимым угасанием.

Мое личное мнение:

Очень коротко скажу, что жизнь в среде Майкрософт себе не мыслю. Поэтому все силы направляю в С++ С и всякие железяки.
Я не сказал об алгоритмизации, т.е. о математиках программистах, но не сказал преднамерено, ибо им все равно на чем писать.
Я не трогаю спец системы типа Матлаба, хоть и знаю об их существовании, так как они узкоприменяемы.
Исходя из своего опыта и мнения - не считаю тенологию от Майкрософт перспективной. Она ведет в тупик, причем тупик в котором скоро для написания программки для сложения двух чисел придется создавать многомегабайтное приложение, и понимание как числа складываются не нужно.
Это будет приводить к ошибкам типа сложения двух чисел long int с всеми 9-ками в разрядах, и непониманием почему неправильно получается ответ.

Несмотря на засилье Майкрософт никто не отменит драйверов, поддержки нового оборудования и многого другого.

[npak]

Alf, спасибо

Если немного распрячь фантазию, то можно увидеть, что визарды, шаблоны и другие костыли современных сред разработки служат для повышения уровня абстракции, сокрытия технических деталей реализации от собственно описания поведения.  Проблема современных костылей в том, что сами они остаются на низком уровне, на уровне языка программирования.  Сейчас набирает обороты (и Майкрософт здесь тоже в числе первых) концепция метапрограммирования, создания сред, в которых легко и быстро конструируется ЯЗЫК предметной области.  Не классы Java/C#/C++, а именно языковые конструкции, на которых удобно выражается бизнес-логика.  В этой области ещё копать и копать, особенно в плане совместимости языков из разных областей и их совместном использовании, причём копать как разработчикам, так и философам и методистам, но я уверен -- будущее за этим.  Будущее не за универсальными языками, а за метаязыками, средствами конструирования новых языков и понятий.

Правда, на исходный вопрос monrus о том, какой язык учить, это моё выступление ответить ответить не помогает Уж извините, так захотелось выступить.

[LEON]

Гром, здесь мне кажется, не только в Микрософт дело. На рынке больших систем, сейчас Микрософт не конкурирентоспособен. Его Axapta является по сути дела, промежутком, между новоявленной ERP системой 1С 8 и монстрами наподобии SAP,хотя при желании и буджет автоматизации предприятия на базе Axapta можно подтянуть до 3$ млн. http://www.cnews.ru/newcom/index.shtml?2005/02/22/175030

То что сейчас программы становятся все больше и больше это и так видно. А размер системы ограничен только затратами на ее разработку. И соответственно программирование под Windows или под другую ОС или технологию, это только часть работы. Напрмер сейчас я работаю в проекте автоматизации одной крупной Российской компании на базе WebSphere. И даже если чуть чуть представить себе объем работ, которые предстоит выполнить, то на решениях Microsoft ушло бы очень много времени, тут такая задача, что ее в принципе невозможно закодировать на C++ или С#. А в целом готовое решение включает в себя, услуги консалтинга, реинженеринга бизнесс процессов, поставка решения, и оборудования, обучение пользователей, внедрение и поддержка. И Microsoft во всем этом отводится не очень большая роль, а именно ОС, Офис и браузер, который входит в комплект поставки ОС. Все остальное, серверная ОС, СУБД, сервер приложений, WebServer это все входит в решение, и это все продукты других поставщиков.
Резюме, будет такое, что в больших и очень больших проектах, программистам (кодерам) отводится очень маленькая и совсем незавидная роль, и то что Microsoft не такой уж и большой гигант как ему кажется, "Голубой гигант" все таки больше, старше и мудрее.

[Гром]

npak- не согласен.
Абсолютно не согласен...
Как собственно и с Леоном.
Если присмотреться то вы говорите по сути об единообразной области применения программирования.
Т.е. крупные системы предметно зависимые или универсальные но о очень высокоуровневом программировании.

Давайте посмотрим на это с другой точки зрения...
В истории есть уже один хороший пример - был один из первых метаязыков - СУБД Clarion мне пришлось на нем даже поработать.
В то время DBase и FoxPro делали свои первые шаги, и кларион явился первенцем в абстрагировании задачи от конкретики.
Он имел визарды и прочие костыли и умела конструировал внутри себя новый метаязык обращений к базе, на котором уже после визуального планирования таблиц и генерации файлов с помощью костыликов, программировал сам процесс программер.

В результате этот подход умер и переродился в нынешнем Майкрософте.
Что далее... Попытка объять необъятное была номер 2. Это СОМ DCOM.
Если присмотреться то это была первая попытка создать платформонезависимую сетевую среду библиотек и преобразовать ее в метаязык программирования. Я понимаю насколько велика натяжка, но присмотритесь, тот же профиль - абстрагирование от платформы типов данных с которыми работает разработчик и более того, абстрагирование от самой концепции различия языков, создание общей сетевой платформы для кодинга.

Где этот проект - в жопе глубокой. От соновных концепций майкрософт не отказалось, но переродила это все в .NET платформу, где уже совершенно иной подход ко всему.

Где будущее дот НЕТ нам рассказал Леон и привел примеры гигантов....
Вот тут http://jobnet.co.il англоязычный сайт требований для новых программеров, т.е. вакансии списком....
Попробуйте - посмотрите все данные за 24 часа и сравните колличество запросов на работу в тех самых "гигантах". Проверьте - как веде нужен С++ и (или) сегодня .NET.

Кроме того все эти самые мета среды и метаязыки изначально пишутся сами на том же С++ пресловутом. И раз что-то можно решить на метаязыке Леон, то при условии его написания на С++ - эту эе задачу можно решить и на С++....

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

Конечно решение на С++ будет неоптимальным, НО утверждать что нельзя какую - то задачу решить на С++ - верх непонимания сути метаязыков и мета сред.

И еще одно. Уж коли вопрос стоит - что учить что бы без работы не остаться и иметь много вакансий повторю написанное выше.
1. ВСЕГДА будет железо на котором бежит программа и ОС.
Значит всегда нужны будут программеры для железа. А это С++ в первую очередь и С для драйверов.
2. В ближайшем будущем идет сильный уклон в торону небольших приборов, и такие приборы будут продолжать разрабатываться - все коммуникации всегда будет нужно обеспечивать новыми протоколами и поддержкой низкого уровня... Опять С++.
3. ВСЕГДА останется необходимость в программистах раельного времени - для отслеживания чего либо или для работы с датчиками. Никакой метаязык для крупных систем не будет в чистом виде работать с приемниками температуры с датчиками давления и т.д.
4. Всегда для разработки мета среды необходимы будут разработчики на С++ для ее собственного написания.

Итог - С++ на сегодня самый перспективный путь развития.

[LEON]

Насчет невозможности, это я погорячился, при очень большом желании это можно написать и на АСМ'е и в машинных кодах или еще ниже. Но невозможно с практической точки зрения, НИ одно предприятие, (конечно могут быть исключения например шизофреник султан Брунея, захочет что бы на его средства это реализовали),  не будет реализовывать проект подобный "Простоквашино" средствами С++, это возможно в теории, но не возможно с рациональной экономической точки зрения.

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

А вот ссылка именно на вакансии в одной из Российских ИТ компаний
http://www.topsbi.ru/pages/rus/work
Как мне кажется наиболее точно отражает потребность в специалистах в области ИТ сегодня.

[xelos]

насчет платформонезависимости COM и DCOM - не согласен, они так не позиционировались. COM исходно завязан на базе регистров Виндовз.

насчет dotNET - не берите язык C# изолированно, весь пакет предлагаемый мелкософтом смотрите (BizTalk Server, MS SQL, MS Exchange Server, etc). Это и есть замена WebSphere. С# - это просто язык, позволяющий легко комбинировать интегрированное решение, предлагаемое мелкософтом.

Насчет железа оно, конечно, верно, однако стоит посмотреть какие требования выдвигаются сейчас к ПО. Полностью интегрированное решение разработать без вспомогательных средств выйдет очень дорого. Сколько фирм-гигантов сейчас способны конкурировать на рынке? достаточно много, однако конечного клиента не так часто интересует их продукция. Возьмем банковскую сферу - банков намного больше чем гигантов-производителей мета-платформ. Однако банки не используют в чистом виде предлагаемые платформы (да и как их использовать? они слишком универсальны) - они требуют собственной разработки в кратчайшие сроки и с легким сопровождением.

программисты низкого уровня тоже нужны, но для меня они попадают в разряд электронщиков (к коим и сам отношусь). Все что real-time это микроконтроллер/процессор - где требуется знание не только программирования, но и электроники. Например - отработать нажатие кнопки с дребезгом - программер будет мучиться, удаляя дребезг програмно - скока времени он на это потратит? а электронщик поставит, например, триггер шмидта, и не будет мучиться с программой. Датчики - отличный пример, все что связано с обработкой сигнала - усилить, отфильтровать - можно делать в программе, а можно и "железно". Да и программирование real-time систем в целом это специфика - отслеживание параметров системы это частная задача, для которой шаблоны решений давно существуют.

в общем, опять все в одну кучу намешали, в Соц. опросе пытались же разобраться кого к программерам относить...

[RXL]

Т.к. мои текушие и да же будущии мысли уже высказаны, я буду писать их обрывки...

что немаловажно в глазах тех, кто страдает этой фобией

Alf, не важно кто впреди, - не должно быть монополии в любой области. Imgo, кончно.

Если бы я сейчас начинал учиться программированию, то выбрал бы ....

npak, это слишком личное Я бы выбрал perl, хотя за последние 10 лет популярность его упала на много порядков, да и изучать perl незная других языков очень сложно. Каждому свое...
Инструмент, который нравится программисту и инструмент более подходящий для требуемых работ, далеко не всегда совпадает.

Delphi и C-Builder, хороши именно GUI.

Как уже было подмечено, в программировании главное - понимающая в этом голова и желание в освоении нового.

Согласен с Громом: ассемблер - сила.
Xelos! По сему же поводу: именно глубокое понимание платформы и придает силу программированию на ассемблере. Если, конечно, он не нужен в работе. Если работа связана с микроконтроллерами и т.п нискоуровневым программированием, то понимание железа обязательно. Причем, если знаешь более одной железячной архитектуры, то понимание иных значительно облегчается - логика, как ее не извращай, остается логикой.
Далеко не для каждого МК имеет резон писать на C++...

---------

Кстати, господа профессионалы, - пока студент будет учиться, пока в нем проснется программист (если еще не проснулся), все в мире коммерческого пограммирования может сильно перемениться. Вам так не кажется?
В данном контексте стоит перечитатьать первый пост Alf-а в этой теме.

[Alf]

IMHO в данной теме роль ассемблера в формировании программиста несколько преувеличена.

Для начала не будем забывать, что не существует абстрактного ассемблера, есть ассемблер конкретного процессора (или семейства). И если кто-либо попытается доказать мне, что достаточно изучить один - и остальные пойдут как по маслу, отвечу словами Станиславского: "Не верю!". Роднит их лишь то, что решение практически любой задачи реальной сложности, если она не связана непосредственно с манипуляцией оборудованием и ячейками памяти, превращается в мучение. Причем результат редко стоит затраченных усилий, ибо современные оптимизирующие трансляторы могут потягаться с хорошим программистом по качеству производимого кода.

В свое время мне приходилось программировать (и помногу) на ассемблере PDP-11, VAX-11, Z80, Intel 8048/8051, Intel x86... Причем на PDP-11 и Z80 в таких количествах, что за кодами команд не приходилось лазить в справочник, отложились в голове, на остальных поменьше, но тоже изрядно. И должен сказать, что при очередной смене платформы каждый раз чувствовал себя новичком, накопленный опыт практически пропадал даром. Навыки хитроумной манипуляции регистрами общего назначения PDP-11 никоим образом не помогали при программировании Z80, в котором обращение к произвольному байту в памяти возможно лишь косвенно через регистровую пару, а привыкнув к трехадресной системе команд VAX-11, крайне трудно было переходить к убогой архитектуре x86, с которой Intel не в силах расстаться в угоду давно уже никому не нужной совместимости с PC XT. Про закидоны однокристальных микроЭВМ и микроконтроллеров и не говорю, там это вынужденная мера по причине дешевизны и технологичности.

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

Конечно, я не призываю к полному невежеству и обломовщине в том смысле, что географию учить не следует вовсе, поскольку ямщик (или компилятор) все равно довезет куда надо. Программист должен иметь представление об архитектуре аппаратуры, которую он использует. Однако время, необходимое для вызубривания особенностей применения каждого из регистров процессора, можно применить с гораздо большей пользой.

P.S. Лично я, если судьбе будет угодно пересадить меня с нынешнего Pentium-N на PowerPC, MIPS или что-то новое 64-разрядное, что нам сулят со дня на день, вряд ли первым делом примусь за новый ассемблер. Даже под угрозой прослыть ламером.

P.P.S. Разумеется, все вышесказанное относится к решению прикладных задач на стандартном вычислительном оборудовании. Разработчики уникальных девайсов и софта для них, не спешите кидать в меня тяжелые предметы. В этих областях ассемблер еще долго останется незаменимым, сколько бы нам ни обещали интеллектуальных кофемолок на Java или пылесосов под Windows CE.

[npak]

Гром, концепция "язык для задачи" родилась не сегодня, она родилась очень давно.  Sed, awk, make, bc, bash/sh/tcsh, tcl, PostScript, tex -- примеры языков, созданных под конкретные задачи, и эти языки блестяще работают в своих областях.  Можно написать на С++ (и даже на ассемблере) код, обрабатывающий строки во входном файле как sed, но гораздо проще и быстрее воспользоваться sed трансформации строк, чем ваять на С++.

Сила специализированных язков в том, что убирают с программиста избыточные трудности.  Слабость -- в том, что разработка языка -- сложное и дорогое удовольствие.  Использование необычного языка чревато проблемами совместимости и сопровождения. 

Метапрограммирование сильно поддержано в Lisp'e (там это называется embedded languages).  Правда, сам Lisp не очень широко распространён в индустриальном программировании.

[Гром]

xelos  - насчет СОМ ты прав, тут я погорячился немного.
Но вспомни кк позиционировались эти решения.
Любая ОС могла создать свою платформную поддержку СОМ объектов, и тогда использовать их подключение к себе по сетям по мере необходимости...

Другое дело, что дураков на это не нашлось

RXL - да вот опять пошел разговор - причем как мне кажется более предметно и более расширено. Вопрос и ответ на него ИМХО найден - выбирать надо под себя... Другое дело - как мы видим перспективу развития области - а это уже интереснее, ведь мы его сегодня создаем


Alf -

И если кто-либо попытается доказать мне, что достаточно изучить один - и остальные пойдут как по маслу, отвечу словами Станиславского: "Не верю!".

Удивил, честное слово удивил...
Дело не в том, что ты не прав, естественно каждый процессор со своей архитектурой, со своими регистрами, способами работы с памятью, инструкциями, IRQ и т.д.
Но дело в том, что идеология программирования на асме в основе своей держит неструктурный, не абстрактный набор понятий языка, а естественную структуру технологического решения процессоров.
Как бы ты не прыгал, но есть у всех процессоров pop push add и т.д. если не точно одинаковые - то по крайней мере похожие по структуре инструкции.
Есть тольк 32 битные комманды у одного, как и ПИКа все выравнены. Есть разномастные. Но все равно при входе в подпрограмму надо сохранять в стеке используемые регистры и вытягивать их оттудапо выходу.
Теоретические и практические навыки составления алгоритма сохраняются, видоизменяясь.

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


npak - и др.
Я попробую еще чуть чуть пояснить.

Давайте возьмем структуру любой программы.
Скажем написанно на С#.

1. Видимый уровень код на С#.
2. Внутренний уровень - код на С++ написанный МАйкрософтом и видимый им.
3. Результирующий код - ассемблер.
4. Исполняемый код - машинный код.

Я имел ввиду что меняются прослойки и надстройки но остается неизменным одно, все исполняется в машинных кодах, которые для каждой платформы свои, и все сводится к низому уровню инструкций ФИЗИЧЕСКИ.

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

Далее - если смотреть вперед, то системное программирование и его основные решения С С++ и асм - будут всегда, так как новые компиляторы писать придется и новое оборудование будет появляться. Как и новые ОС.

Далее - все языки высокого уровня - особенно спец языки под задачи, как СУБД, Пролог, и многие вышеназванные будут развиваться - если задачи для которых они написаны останутся актуальны.
Отсюда - примеры банков, еще 20 лет назад задача банковского биллинга в СССР не стояла.
Задачи с огромными распределнными сетевыми БД стали только 20 лет назад очень актуальны, так как сети до этого момента были в зачаточном состоянии и не могли рассматриваться как серьезные задачи.
Зато была проблема переноса БД с компутера на компутер, и решалась она с помощью технологии (увеличение флоппи дисков изобретение CD), программно ( с помощью программ разбиения исходных больших файлов на мелкие и сбора их на новом месте ).

Если сегодня посмотреть вперед, то основным направлением становятся
А) передача огромного колличества данных на расттояние очень быстро (видео)
Б) уменьшение размера систем (наладонники сотовые телефоны и т.д.)
Г) сети и их скорость. Раутинг, распределение нагрзки создание распределенных вычислений для систем типа google и для решения глобальных задач.
И т.д. и т.п.
Т.е. решения будут меняться и языки будут появляться новые.
Еще 5 лет назад VB позиционировался как универсальная среда разработки для MS SQL а сегодня решение это .NET где VB остался - но не играет решающей роли.

[Alf]

...
Удивил, честное слово удивил...
Дело не в том, что ты не прав, естественно каждый процессор со своей архитектурой, со своими регистрами, способами работы с памятью, инструкциями, IRQ и т.д....
Как бы ты не прыгал, но есть у всех процессоров pop push add и т.д. если не точно одинаковые - то по крайней мере похожие по структуре инструкции.
Есть тольк 32 битные комманды у одного, как и ПИКа все выравнены. Есть разномастные. Но все равно при входе в подпрограмму надо сохранять в стеке используемые регистры и вытягивать их оттудапо выходу.

Возможно, снова удивлю, однако придется...

Конечно, немного зная английский, можно догадаться, что делают некоторые инструкции (хотя попробуй угадать с трех раз, что делает команда Z80 LDIR, не прочитав руководство?). Однако та же интуитивно понятная команда ADD X1, X2 на процессорах Intel занесет сумму в X1, а на PDP-11 в X2, и никакая интуиция тут не поможет.

И POP с PUSH, как ни печально, есть не везде... В той же PDP-11 роль указателя стека выполняет регистр R6, и занесение в стек выглядит как

Код:

MOV X, -(R6)

, а снятие с верхушки стека -

Код:

MOV (R6)+, X

Мораль сей басни: поменял архитектуру - пожалуй снова за парту, былые заслуги порой не помогают, а лишь сбивают с толку, ибо внешне похожие операции делают фактически разные вещи.
 

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

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

Например, теоретики любят умозрительные игры с машиной Тьюринга. Один из рецептов определения, принадлежит ли предложение данному языку, у них таков: по очереди перебирать все возможные комбинации символов и смотреть, не совпадет ли очередная с предложением. Теоретически не подкопаешься, только годится ли это в реальной жизни?.. Можно и прорабу, который просит экскаватор для фундамента, рассказать про графа Монте-Кристо, который столовой ложкой чуть ли не весь замок Иф перекопал, и предложить повторить этот подвиг. Только скоро ли ты поселишься в том доме?

...
Далее - если смотреть вперед, то системное программирование и его основные решения С С++ и асм - будут всегда, так как новые компиляторы писать придется и новое оборудование будет появляться. Как и новые ОС.

Я бы все же не валил в кучу ассемблер и С++. Все-таки это два полюса. С одной стороны - уровень ниже некуда, с другой - возможность реализации самых абстрактных конструкций. Да и компилятор я бы не взялся писать на ассемблере, пожалуй. И другим бы не посоветовал. Про операционные системы молчу - язык С как раз и обязан своим появлением Кернигану и Ритчи, которые наелись ассемблера досыта в процессе разработки именно операционных систем.

[Гром]

Возможно, снова удивлю, однако придется...

Странно - но не удивил.

На всамом деле ты говоришь правильно, но разве изучение языка - это изучение его комманд??? Ужас - если ты так думаешь...
Пример прост.
Переходя с паскаля 5.0 на С++ 3.1 убедился что 80% команд, совпадают, акромя некоторыхразличий. Понять что вместо {} надо писать begin end и наоборот - не составляет труда.
Но я с первого раза определяю с какого языка человек пришел на С - С++. Логика составления программы меняется.

Отсюда вывод - изучение языка программирования не заколючается в выяснении всех параметров функций writeln или printf а в понимании правильного программирования птимального построения кода средствами языка.
А то что ты говоришь о разнице пуш и поп комманд или реализацию стека на регистре, так ты извини, но это либо непонимание сути, либо ты прото не понял о чем я говорю.
Для того, что бы писать на ЛЮБОМ ассмблере достаточно знать один из них досконально и проникнуться логикой типа:
Для работы с экраном надо
а) занести в регистр Д0 значение маски битов экрана.
б) занести в регаистр А0 значение адреса в котогрую писать.
в) выполнить комманду addto
г) сделать рефреш.

Т.е. полностью пошаговую структуру комманд. А как там они будут называться в сущности не важно...

Теоретически не подкопаешься, только годится ли это в реальной жизни?.. Можно и прорабу, который просит экскаватор для фундамента, рассказать про графа Монте-Кристо, который столовой ложкой чуть ли не весь замок Иф перекопал, и предложить повторить этот подвиг. Только скоро ли ты поселишься в том доме?

Это писалось в ответ на фразу что что-то нельзя реализовать на С++ а можно только на супер мета языках.
Так что не спорю, ты прав

Я бы все же не валил в кучу ассемблер и С++.

Я бы не был так категоричен...
Тем более полюсами там и не пахнет.
С в чистом виде и асм очень близки.
С++ расширение в виде объектно-оринтированной структуры, доп операторов и приложений для работы с кучей нужных билиотек, это не совсем смысл языка.
Вспомни, что была такая неотъемлемая библиотека в MSDOS - egavga.bgi
В ней была куча функций - и кто ими счас пользуется??? Хотя в свое время считалась неотъемлемой частью С++.
Так и тут - вот обоснует кто - нибудь новую концепцию объектности и наследования. Докажет теоретически более лучшую труктуру и появится С+- который станет прямым продолжением С++ но в котором уже не будет ни class A public B ни virtual ни чего подобного, а будет совершенно другое и что мы будем писать по этому поводу???

По сути С++ - это над язык написанный на С для расширения его возможностей.

[xelos]

Как уже было подмечено, в программировании главное - понимающая в этом голова и желание в освоении нового.

по-моему это не только в программировании главное...

Согласен с Громом: ассемблер - сила.
Xelos! По сему же поводу: именно глубокое понимание платформы и придает силу программированию на ассемблере. Если, конечно, он не нужен в работе. Если работа связана с микроконтроллерами и т.п нискоуровневым программированием, то понимание железа обязательно. Причем, если знаешь более одной железячной архитектуры, то понимание иных значительно облегчается - логика, как ее не извращай, остается логикой.
Далеко не для каждого МК имеет резон писать на C++...

насчет платформы - отлично, что подразумевается под платформой? Если ОС типа виндовз, то тогда не вижу связи между пониманием работы платформы - как взаимодействуют менеджер памяти, менеджер безопасности, система ввода/вывода, управлением потоками и т.д. и ассемблером.

[xelos]

ИМХО, это дискуссия бесконечная, т.к. сюжет слишком большой - в чем-то одни правы, в чем-то другие... имхо, все валится в кучу.

[npak]

Djpdhfщаясь к исходному вопросу,

Пусть освоит объектно-ориентированное программирование в объёме С++/MFC

Затем возможны следующие способы устроиться на работу по разработке всяческих веб-приложений
1.  освоить Java + J2EE + базы данных + Servlet
2.  освоить С# + .NET + ADO.NET + WebServices
3.  освоить С++ + COM/ActiveX
4.  освоить Delphi + (не знаю, как в Delphi называются технологии доступа к базам данных и построения веб приложений)

Разумеется, возможны и другие способы зарабатывать деньги в России/Европе/Штатах

Набить своих шишек и, возможно, удасться стать профессионалом и перейти в другие ниши разработки.

[LEON]

Насчет того, что большое решение невозможно написать на С++ я поправился, это не не возможно в принципе, это не возможно с экономической точки зрения.

Далее - если смотреть вперед, то системное программирование и его основные решения С С++ и асм - будут всегда, так как новые компиляторы писать придется и новое оборудование будет появляться. Как и новые ОС.

Гром, а многои ли надо специалистов С++, которые будут писать ОС, компиляторы, трансляторы с метаязыков, ERP системы и т.п.? Даже если в IBM требуется 1000 программистов С++, я думаю, что если посчитать всех специалистов С++ в компаниях гигантах (а их я на вскидку могу насчитать штук шесть: SAP, IBM, Oracle, HP, SUN, MS ну и Cisco), то их наберется меньше 10%, а остальным 90% что делать?
Пользователю в конечном счете все равно, чье решение у него будет стоять SAP, MS или 1С, главное, что бы оно работало. Почему все эти компании не занимаются внедрением своих проектов, а отдают их в руки партнеров. наверное по тому что рынок слишком большой и даже им, с ним не справится. Например, для внедрения решения на базе SAP не требуется ни одного С++ программиста. Конечно знание С++ полезно, с точки зрения постановки мознов программиста, в нужную плоскость, и даже на С++ можно написать не очень большую программку. Но в то что будующее однозначно за С++ я не верю, скорее даже верю в обратное.

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

Gartner: прогнозы на ближайшее десятилетие
http://www.osp.ru/os/2005/01/004_1.htm

2005: ожидания, события, тенденции
http://www.osp.ru/os/2005/01/004_2.htm

Новое слово в корпоративных системах
http://www.osp.ru/os/2005/01/005_4.htm

Еще довольно интересный текст, от одного из менеджеров MS, который как обычно, красиво нам описывает радужное будующее мировой глобализации. Насколько ему следует доверять, я не знаю, но прочитать по моему, интересно.
http://www.osp.ru/os/2005/01/060.htm

Еще статья, про "гиганты", описывается, чем они жили в недавнем прошлом, чем живут сейчас, и немного, про их планы на будующее
http://www.cnews.ru/newcom/index.shtml?2005/02/15/174617


P.S.
Пока искал эти линки, наткнулся на еще одну интересную статью:
http://www.cnews.ru/newcom/index.shtml?2005/02/28/175208
Про интеграцию различных систем, масштаба государства 8)

[Гром]

Гром, а многои ли надо специалистов С++, которые будут писать ОС, компиляторы, трансляторы с метаязыков, ERP системы и т.п.? Даже если в IBM требуется 1000 программистов С++, я думаю, что если посчитать всех специалистов С++ в компаниях гигантах (а их я на вскидку могу насчитать штук шесть: SAP, IBM, Oracle, HP, SUN, MS ну и Cisco), то их наберется меньше 10%, а остальным 90% что делать?

Ой как все запущено

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

В мире все совершенно иначе.

1. С++ - написание ОС.
2. Написание драйверов для всех новых плат под эти самые ОС. Пока изобретается новая система Виндовс новые версии продуктов карточек и т.д. это будет нужно.
3. Все приборы - больницы кассовые аппарты системы слежения за тех процессом коммуникации сети протоколы TCP IP UDP  и все все все связанное с защитой данных VPN - это все С++
4. Embedded целиком и полностью И ТОЛЬКО С++.
5. Постоянный рост колличества работ под Юникс и Линукс изначально позиционирует ТОЛЬКО С++.
6. Работа на МАК - Основа - тот же С++.
7. Програмное обеспечение домашней техники - DVD и все что связано , все что обрастает программами + сотовыве телефоны (перспектива вилдефоны) работа сотовой связи сама как таковая - не учет звонков а роуминг раутинг звонков сервера бзовые...

И это 10%
Скорей БД - занимает процентов 25 программистского рынка.
Просто в России производителей как таковых практически нет УВЫ как не печально это писать - поэтому основа программ - суть программы потребительские для клиента либо совсем конечного типа банкомата с БД, да и тот чаще на С++ пишут. Либо для клиента корпорации (тот же банк система Сотовой связи и т.д. и т.п.)...

[Alf]

...разве изучение языка - это изучение его комманд??? Ужас - если ты так думаешь...

Слишком много у меня этих языков сменилось,чтобы я так думал. Да и статьи мои, полагаю, свидетельствуют о несколько другом подходе.

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

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

Переходя с паскаля 5.0 на С++ 3.1 убедился что 80% команд, совпадают, акромя некоторыхразличий. Понять что вместо {} надо писать begin end и наоборот - не составляет труда.

Парадокс, но отличий между Pascal и C (а тем более от одного производителя компилятора, в данном случае Borland) намного меньше, чем между ассемблерами двух процессоров с принципиально разными архитектурами. В первом случае замена операторных скобок текстовым редактором устраняет значительную часть различий, остается подрихтовать циклы да описания переменных - и дело почти готово.

Впрочем, это все бесплодные разговоры. Проверить проще простого. Дай небольшую программу на С программисту на Pascal или наоборот и попроси разобраться и переписать на свой язык. А потом тот же эксперимент предложи любителям ассемблера. Например, профи по ассемблеру Intel x86 дай фрагмент на ассемблере Alpha или PowerPC и попроси переработать на его платформу. Думаю, результат известен наперед. В первом случае общая эрудиция и опыт не подведут, во втором помогут мало, кроме общих навыков.

Но я с первого раза определяю с какого языка человек пришел на С - С++. Логика составления программы меняется.

Даже любопытно. Мое программистское прошлое сможешь определить по моему коду (его на форуме предостаточно, да и тебе фрагменты присылал, материал для анализа должен быть)?

...
А то что ты говоришь о разнице пуш и поп комманд или реализацию стека на регистре, так ты извини, но это либо непонимание сути, либо ты прото не понял о чем я говорю.
Для того, что бы писать на ЛЮБОМ ассмблере достаточно знать один из них досконально и проникнуться логикой типа:
Для работы с экраном надо
а) занести в регистр Д0 значение маски битов экрана.
б) занести в регаистр А0 значение адреса в котогрую писать.
в) выполнить комманду addto
г) сделать рефреш.

Т.е. полностью пошаговую структуру комманд. А как там они будут называться в сущности не важно...

Ну это скорее рецепт управления данным конкретным индикатором. Ничего специфического ассемблерного в этой логике нет.

То же самое про любой язык сказать можно. Например, чтобы найти среднее значение в массиве, нужно:
а) завести и обнулить переменную для суммы;
б) в цикле прибавить к переменной каждый элемент масива;
в) поделить полученную сумму на число элементов массива.

Да и не только про языки программирования. Примерно так же выглядит и кулинарный рецепт, и руководство начинающего диверсанта...

С в чистом виде и асм очень близки.

Первый не зависит от конкретной архитектуры, второй жестко к ней привязан.
Первый работает со структурированными данными, для второго вся память, включая коды команд, - одна большая свалка, в которой все допустимо.
Первый позволяет программировать структурно, во втором GOTO сидит на GOTO и GOTO погоняет.
Список "близостей" можно бесконечно продолжать. Упомянутый Pascal и впрямь на несколько порядков ближе.

С++ расширение в виде объектно-оринтированной структуры, доп операторов и приложений для работы с кучей нужных билиотек, это не совсем смысл языка.
...
По сути С++ - это над язык написанный на С для расширения его возможностей.

Скорее принципиально новый язык с новыми идеями, в котором синтаксис заимствован из С. Дабы не быть голословным, цитата из Страструпа:

Чем лучше программист знает С, тем труднее будет для него при программировании на С++ отойти от стиля программирования на С.  Так он теряет потенциальные преимущества С++.

Вот такое вот расширеньице, которое тем проще изучить, чем меньше знаешь о его предшественнике.

Вспомни, что была такая неотъемлемая библиотека в MSDOS - egavga.bgi
В ней была куча функций - и кто ими счас пользуется??? Хотя в свое время считалась неотъемлемой частью С++.

Это без комментариев... С каких пор "драйвер" конкретной видеоплаты стал частью многоплатформенного объектно-ориентированного языка? Тем более что с таким же успехом его можно считать "неотъемлемой" частью Pascal, к нему он также шел прицепом в поставке от Borland (то-то икнется Вирту от такого подарка).

Так и тут - вот обоснует кто - нибудь новую концепцию объектности и наследования. Докажет теоретически более лучшую труктуру и появится С+- который станет прямым продолжением С++ но в котором уже не будет ни class A public B ни virtual ни чего подобного, а будет совершенно другое и что мы будем писать по этому поводу???

Так честно и напишем автору темы - структура С+- лучше, учи его, не прогадаешь. В чем проблема-то?

[LEON]

В мире все совершенно иначе.

1. С++ - написание ОС.
2. Написание драйверов для всех новых плат под эти самые ОС. Пока изобретается новая система Виндовс новые версии продуктов карточек и т.д. это будет нужно.
3. Все приборы - больницы кассовые аппарты системы слежения за тех процессом коммуникации сети протоколы TCP IP UDP и все все все связанное с защитой данных VPN - это все С++
4. Embedded целиком и полностью И ТОЛЬКО С++.
5. Постоянный рост колличества работ под Юникс и Линукс изначально позиционирует ТОЛЬКО С++.
6. Работа на МАК - Основа - тот же С++.
7. Програмное обеспечение домашней техники - DVD и все что связано , все что обрастает программами + сотовыве телефоны (перспектива вилдефоны) работа сотовой связи сама как таковая - не учет звонков а роуминг раутинг звонков сервера бзовые...

1. Системное программирование
2. Системное программирование
3. Тут уже не согласен, все что касается технической реализации, это системное программирование, или под железо. Для разработки распределенной системы, мне не обязательно знать сетевые протоколы. Распределенная БД, можно ее реализовать, без знания тонкостей прохождения пакетов по каналам связи.
4. Под железо.
5. Системное. А если боее высокого кровня, то тут намного больши используется Java (см. работы SUN и IBM)
6. Тут не знаю, с МАК'ами не работал, если это опять относится к ОС, то это системное программирование, если на более высоком уровне, то я думаю, есть другие средства.
7. Тоже самое Embeded

Из всех этих примеров, не было ни одного где, бы требовалось высокоуровневое программирование.
Основная идей, по моему мнению. в том, что пока задача маленькая и с ней можно справится средствами с++ или подобными, то все в порядке, но как только задача разрастается, то тут подход, с точки зрения языков программирования, не оправдан.


На Cnews три, четыре месяца назад, проскакивала статья, об объединении АСУ ТП и ERP в единую систему, прогнозы делались на 4 года. Да, безусловно, С++ программистам будет занятие, в программировании маленьких задачек, и предоставлении интерфейсов, для более высокого уровня интеграции.

Сколько нас не пугают интеллектуальными тостерами с непосредственным управлениеv с сервера Microsoft, но до такого уровня интеграции еще далеко.

С++ был отличным решением, для своей задачи, а именно универсальным, платформонезависимым (изначально от Си) языком. Который из-за своих качеств стал очень распространным, и по старой памяти его продолжают и пихать во все дыры, даже сейчас, особенно в те, в которые он не справляется. Прошло время, изменились задачи, а соответственно должны менятся и средства их решения. По тем же аналитическим прогнозам Gartne,r ЯВУ, как таковые уходят, оставляя место другим, более современным средствам решения, других, более сложных типов задач.

Гром, рынок системного программирвания, сосвсем не такой большой. Рынок больших решений намного намного, больше, и это не только в России. Другое дело, можно ли называть различных ИТ специалистов, принимающих участив в разработке таких решений программистами?

[Finch]

Чтобы знать будушее, надо хорошо знать и настояшее и прошлое. Истинный флажок, который всегда указывает направление будушего это две веши: ЭГО человека создаюшего его (будушее) и деньги. Читайте экономические и политические газеты между строк. Смортрите куда пускают деньги большинство богатых людей. То и направление программ будет определять будушее. Теперь только стоит подумать об инструментах, всецело и полностью реализующих данные  направления. И вопля фокус покус, мы получим ответ на заданный вопрос. Но это перспектива ближайших двух лет. Дальше предсказать нельзя. Будут вмешиваться очень много постороних факторов. Даже наше предсказание будушего, уже является постороним фактором, который может изменить течение времени. Нострадамус, когда писал свои катрены иносказательным языком, понимал и видел как каждое его слово меняет будушее. И одно неверное движение руки, приводит к временному кольцу.

Источник не известен. Нашел в своем архиве.

[Гром]

Убегаю - отвечу утром завтра...
ИМХО  - редкий диалог на основании которого просыпается мывсль написать статью...
Есть смысл - ведь мы определяем само будещее...