[Aguinore]

0

Вопрос: Работаю программистом на Java. Есть ли смысл в свободное время изучать С++?

1. Да, знание двух языков - это круто и большой плюс к потенциальной зарплате		31	(63.27%)
2. Нет, лучше учить Java, тем более, знаешь ты ее не так чтобы очень глубоко, а зарплаты в ней тоже не маленькие		15	(30.61%)
3. Да, учить надо, но не С++, а напишу в комментах, что.		3	(6.12%)
Всего:		49

Comments

[Co0L]

Имхо, Java сейчас очень актуален, а C++ слишком необъятен) Как по мне, так лучше углубленнее изучать Java, а потом в случае чего знания можно будет перенести на C++, все-таки языки довольно похожи)

Зойчем джависту кресты с его костыльным ооп? Уровень пониже знать надо, но кресты это в первую очередь попытка смешать ужа с ежом, которую тяжело и со скрипом пытаются исправить в новых стандартах языка.
Алсо, какая джава? JavaEE?
Специфика-то различается, и даже не немного.

[Aguinore]

твой фаворит, в данный момент да, EE.

[Flex Ferrum]

твой фаворит, чувствуется глубокое знание предмета, особенно - C++.

Aguinore, изучить было бы полезно. Хотя бы по той причине, что Java родилась из C++ путём отрезания "всего ненужного" (по мнению авторов). Но изучать лучше современное состояние языка.

[Aguinore]

Flex Ferrum, время-то ограничено) И распыляться не хочется.

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

[Flex Ferrum]

Flex Ferrum, время-то ограничено) И распыляться не хочется.

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

Собственно, с новыми языками - так же.

[dixie_flatline]

Как профессиональный писатель на C++, рекомендую его изучать _только_ если он _действительно_ нужен. В опенсорсе, в геймдеве, в некоторых серверных разработках он ещё используется. Ради интереса на него даже смотреть не стоит - пустая трата времени и куча мусора в голове гарантированы.

[Flex Ferrum]

В опенсорсе, в геймдеве, в некоторых серверных разработках он ещё используется.

Угу. Угу.

[Co0L]

А вообще, Java - это здорово) Можно писать под Android) Сейчас мобильные игры и приложения настолько актуальны, что некоторые знакомые C++ программисты жалеют, что не взялись пару лет назад за Java или Objective-C)

[CD_Eater]

.umi, про мусор в голове метко сказано!
+1

[Flex Ferrum]

А вообще, Java - это здорово) Можно писать под Android) Сейчас мобильные игры и приложения настолько актуальны, что некоторые знакомые C++ программисты жалеют, что не взялись пару лет назад за Java или Objective-C)

Вообще говоря, под Android можно писать и на C++ (но это опционально), а Objective C/C++ - это тот же C/C++, но с некоторыми добавками.

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

Aguinore, так а почему именно C++? ЕЕ-шнику оно вообще особо никуда не падало, даже если в работе и будет какое-то легаси или просто зело быстрое приложение на крестах, то общаться с ним скорее всего придётся по сети.

[Flex Ferrum]

твой фаворит, а чего предметнее то? Парадигма ООП - она должна быть в первую очередь в голове программиста. Язык - это лишь средства её применения. То, что C++ позволяет программисту делать разные, гм, трюки ещё не означает, что а) этими возможностями надо непременно пользоваться, б) язык - плохой. То, что Java позволяет программисту разрабатывать код только с использованием классов и интерфейсов, обеспечивает ему сборку мусора, следит за использованием исключений и т. п. ещё не означает, что программист этим всем автоматически научается грамотно пользоваться. В общем, всё рано или поздно упирается в: а) знания принципов построения грамотной архитектуры, б) знание того, как нужно писать, а как не нужно. И, эммм...., это от языка не зависит.

[yulia_shabunio]

О боги.... учите!!! Учите всё! Учите чистый С для начала (и почитайте Шпольски, он лучше меня сказал, зачем). Учите С++, php, erlang, lisp, C#, ассемблер наконец! Для нормального программиста новый язык (не технология) - это недели две почитать в охотку + тестовый проект. Учите, чтобы поймать суть парадигмы, даже если в жизни не собираетесь потом иметь с ним дело. Учите, чтобы знать как оно работает, и чтобы просто учиться, чтобы отточить навык обучения и плавать в новой информации как рыба в воде.

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

Flex Ferrum, это всё как-то противоречит первому моему утверждению, что C++ - не лучший язык для изучения, если собственно писать на нём не собираешься? Куча костылей, подводных ям, "тем пользуйся, тем не пользуйся, тем не пользуйся ни в коем случае", и прочее прочее. Я сам писал на С++ до того, как уйти в embedded С, и прекрасно знаю о чём речь, более того, примеры тех самых ям разной степени подводности крестов на любой стадии, от проектирования (с учётом его особенностей) до реализации, может привести любой более-менее что-то видавший разработчик. И ты, думаю, не исключение
А, ну ещё крестопрограммисты любят считать себя уберквалифицированными банально из-за того, что знают как бороться со своим же языком, правда зачастую результатом этих сражений является то, что в других языках реализовано просто и по умолчанию.

[Flex Ferrum]

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

Flex Ferrum,

реализация вещей, связанных с ООП, в Java и в C++ особо не различаются.

серьёзно? Множественное наследование в крестах, отсутствие в них же понятия "интерфейс" (заменённое абстрактным классом с чисто виртуальными методами), куча волшебных операторов приведения типов (один легаси, один нихрена не учитывает, один - чудесный const_cast, и вот остаются только два оператора, пытающихся учесть иерархию классов), методы класса по умолчанию (в отличие от джавы) не являются виртуальными. Желающие да продолжат, суть не в этом, а в том, что отличия фундаментальны и их хватает. Конечно, если ограничить кресты каким-то подмножеством, то писать на них можно, но тогда получается то, о чём я и говорил - "тем пользуйся, тем не пользуйся, тем не пользуйся ни в коем случае.

С точки зрения проектирования - и подавно.

Тут особо растекаться мыслью по древу не буду - есть отличный пример: выше упомянутый const_cast и mutable. Страуструп в своей классической книге приводит пример использования того же mutable, после сам приводит пример более разумной архитектуры, позволяющей обойтись без него, но тем не менее упрямо вводит в язык ещё один способ выстрелить себе в ногу Только способов таких многовато накопилось, за что кресты и часто подвергаются нападкам разной степени аргументированности.
Хотя насчёт "проектирования" я пожалуй мимо - скорее больше будет разговор о реализации, именно тут могут проявляться забавные особенности и чересчур богатый выбор средств этого языка.

[dixie_flatline]

но тем не менее упрямо вводит в язык ещё один способ выстрелить себе в ногу

А ты не знаешь, почему? C++ - это продолжатель дела чистого C, такой высокоуровневый ассемблер. На нём можно сварганить всё, что угодно, от ядерного реактора до мерзкого мутанта с извивающимися щупальцами. Это в жабе или питоне есть хоть какие-то зачатки ограничения пользователя ради его блага, на плюсах можно сделать _всё_, полная свобода дадена в помощь скорости выполнения. И никого не волнует, что у неумелого программиста при этом получается жижа. Язык - полон (в основном из-за фич типа const_cast и mutable), использовать - никто не заставляет, что ж вы все возмущаетесь?

.umi,

И никого не волнует, что у неумелого программиста при этом получается жижа.

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

полная свобода дадена в помощь скорости выполнения.

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

использовать - никто не заставляет, что ж вы все возмущаетесь?

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

[dixie_flatline]

твой фаворит,

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

На самом деле влияет сильно. Вариантов различных оптимизаций и твиков - море. Но, в отличие от жаб и питонов, где они делаются магическим образом, в плюсах эти оптимизации более чем очевидны. Это такая плата за сложность языка, видимо. Баланс сил в ЯП.

А вот менеджеры, как раз, особенно в конторах десятилетней давности, предпочитают всё-таки C++ всем этим "хипстерским штучкам". Потому что быстрее. Почти прямая цитата. Лично мне плевать, я делаю, что скажут, никто не жалуется. В общем, кому что.

.umi,

На самом деле влияет сильно. Вариантов различных оптимизаций и твиков - море.

вообще стоило бы отличать опции компилятора и его же расширения с директивами препроцессора а-ля #pragma от стандартных операторов языка. Из тех самых стандартных операторов, которыми можно чота "соптимизировать" (ну или наоборот) я с разгону вспомню только inline, register да volatile. Первое используется повсеместно, правда обычно в неявном виде - компилятор обычно и сам замечательно видит "горячие" вызовы или просто маленькие функции, разворачивать которые смысл имеет. Но допускаю, что при особо хитрой логике явное обхявление с инлайном поможет что-то выгадать. Второе - с современными компиляторами смысла почти не несёт ибо с регистрами "что, куда, и как быстрее" компилятор знает гораздо лучше. Третье используется обычно в паре с ассемблерной вставкой (как для самого блока, так и для "неявно" задействованных переменных), хотя школяры несознательные личности, начитавшись туториалов, могут использовать его для задействованных в нескольких потоках переменных, дабы их не съел оптимизациями компилятор (и в большинстве случаев выстрелят себе в ногу неупорядоченным доступом к разделяемым данным). А что до ассемблерной вставки - обычно это инстант минус в карму непереносимым кодом, и нужно ооочень постараться, чтобы плюсы перевесили
А средства для оптимизации, которые предоставляет сам компилятор - так они в любом языке есть, и JVM можно очень тонко тюнинговать, и с пистоном что-то сотворить тоже вероятно можно. Так что не крестами едиными, которые быстрые банально потому, что собираются в натив и поддерживают совместимость с сишной кодовой базой (что даёт большой объём быстрого кода без всяких обёрток).
Что до менеджеров - можно просто посмотреть на тенденции, где ясно видно, что происходит отток из крестов в сисярп, причём уже происходит достаточно давно (sites.google.com/site/pydatalog/pypl/PyPL-Popul... , пообъективней TIOBE будет). Может когда новый стандарт устаканится в компиляторах то что-то и поменяется, но пока имеем что имеем.

[dixie_flatline]

твой фаворит,

вообще стоило бы отличать...

Странно, зачем ты это всё рассказывал, я, вроде, и без тебя знал. Но спасибо за лекцию, забавно вспомнить юность

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

[Flex Ferrum]

серьёзно? <...> отличия фундаментальны и их хватает.

твой фаворит,
Уверяю тебя, с точки зрения архитектора перечисленные отличия - отнюдь не фундаментальны. Собственно, "интерфейсов" в С++ нет по той простой причине, что тогда, когда C++ только зарождался, никому в голову не приходило, что "интерфейсы" надо выделять каким-то особенным образом. Интерфейсы (в Java/C#) и множественное наследование - это одни и те же яйца, только с разных профилей. Думаю, ты сам сможешь догадаться почему. Зачем ты сюда операторы преобразования и константность привёл - мне вообще не понятно. А то, что в Java все функции виртуальны - так это особенность именно Java.
Вообще, у ООП в частности и процессе построения архитектуры вообще - немножко другие задачи. Описанные тобою подробности реализации к решению этих задач имеет весьма опосредованное отношение.

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

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

Из тех самых стандартных операторов, которыми можно чота "соптимизировать" (ну или наоборот) я с разгону вспомню только inline, register да volatile.

Не густо. Вообще, месяца два назад на Хабре C-шники с C++-никами пузиками мерялись, кто лучше кое-какой алгоритм соптимизирует. Языковыми средствами, конечно же. В отношении того, что ты привёл в качестве примера - от этого, вообще говоря, мало толку. Обычно применяются немного другие вещи: грамотная константность, r-value refs-оптимизация, шаблоны, статический полиморфизм, использование свойств типов, понимание логики работы тех или иных контейнеров и алгоритмов, понимание того, как C++-сный код транслируется на ассемблер и, соответственно, правильный выбор типов...

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

[mikluho]

Ой... вот развели же холивар...

Вопрос, собственно не об этом был, и не об этом отвечать надобно. В более ранних комментариях это уже прозвучало: для интереса и расширения кругозора - надо несомненно. Равно как с той же целью стоит поизучать прочие современные языки/платформы. И именно в варианте "почитать книжку, сварганить тестовый проектик". Но ни в коем разе нельзя на этом зацикливаться. Без серьёзного использования на практике нельзя изучить ничего сложнее Basic-а. А по остальным, которые зацепят/заинтересуют - надо переходить к чтению серьёзных профильных книжек, предназначенных для углублённого изучения.

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

[yulia_shabunio]

mikluho,

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

Да можно этому научиться, и технологии есть.. Проблема в том, что учиться этому никто не хочет, потому что считает, что "и так тут всё понятно!" или "да ну, фигня какая-то"... (даже не знаю, какой вариант хуже) . Вот и выходит "или есть, или нет"...

[Flex Ferrum]

Проблема в том, что учиться этому никто не хочет, потому что считает, что "и так тут всё понятно!" или "да ну, фигня какая-то"...

yulia_shabunio,
Собственно, наверное это - весьма существенная причина для изучения C++. Чтобы разобраться в том, как реализация ОО-парадигмы выглядит "под капотом". Кроме того, понять принципы управления ресурсами (и что ими вообще надо управлять), основы работы с исключениями и т. д. и т. п. C++ в этом смысле хорош тем, что практически не прощает ошибок. Если напортачил с памятью - получи мемлики и крэш. Если приключилась фигня с многопоточностью (race condition, deadlock, data races и т. п.) - получи крэш и распишись. Если забил на грамотную обработку пролетающих исключений и работу с ресурсами - получи незакрытые транзакции, объекты с нарушением инвариантов, и прочие прелести и, опять же, крэш...

Ой... вот развели же холивар...

mikluho,

[yulia_shabunio]

Flex Ferrum,

Собственно, наверное это - весьма существенная причина для изучения C++.

Как я уже писала, я всеми руками ЗА то, чтобы учить С++, С, ассемблер и вообще всё на свете, что может быть использовано для того, чтобы заставить компьютер делать то, что мы от него хотим

Но вот как способ изучить именно парадигму ООП.... эмм... Не уверена. В С++ очень много реализации. Очень много реализации, отвлекающей от сути.
ООП я бы предложила изучить отдельно по книжкам "в картинках", написанных без привязки к языку вообще, чтобы понять суть именно парадигмы. Шаблоны проектирования поизучать. И только потом - аккуратно перейти к тому, как это реализовано в разных языках. Что отрезала Java, что переиначил C#, что накрутил и добавил С++ и как можно писать совершенно объектный по всем критериям код на перле и чистом С.