Прошу совета,как начинающий программист) ПРЕДЫСТОРИЯ: С программирование я познакомился не так у давно,а именно в 11 классе. это был Пакаль нужен был только для сдачи егэ по инфе,но дело это увлекло,так что решил связать свою жизнь с прогерством.. Поступил на кафедру Прикладная математика и информатика,где сейчас и учусь. За первые два семестра мы теоретически должны были изучить Си(дальше будет курс ООП). Программа конечно у нас не самая лучшая,да и препод попался не ахти.. так что информацию в основном черпал из соответствующей литературы. После сдачи сессии понял,что полагаться на универовскую программу не стоит и надо самому основательно браться за какой-нить язык программирования. Недолго думая, я выбрал С++, так как владел какими-никакими основами Си. Потратив некоторое(хехе, довольно длительное ) время на изучение синтаксиса языка и основных концепции ООП, я пришел к состоянию,в котором нахожусь сейчас: я не знаю что учить дальше! К серьезному изучению VStudio я еще не готов однозначно. Подскажите как мне можно отточить практическое применение С++(от синтаксиса и элементарных прог перейти к чему нибудь более серьёзному). Понравилась идея Qt, однако немного смутила немногочисленность книг по ней)сложна ли она для понимания новичка?
Заранее Спасибо!

Начать писать простые, но нужные программки, любая обточка теории до совершенства есть практика!
Можешь написать на заказ кому-нибудь что-то простое, знакомым например. У нас в институте есть пару объявлений о работе, где требуется знание QT и линукс-систем.
Паскаль в 11 классе? Эх... я на нём ещё в 7 лет писал программки, благодаря его простому синтаксису, даже книгу у родителей выпросил, но правда далеко не ушёл от паскаля... Сейчас правит другой синтаксис, другие методы программирования, другие языки...

Хотя когда разбирался в основах СИ++, то понял, что многое в нём сделано для удобства.

Люди, которые говорят, что знают C++ либо идиоты, либо им просто не известно чего они не знают. (С) Крис Касперски

Купи книгу "Сборник задач для программиста. C++."

Напиши простой веб-браузер на C#.
Профи справляются с этой задачей за пару часов, а ты потратишь уйму времени и получишь огромное количество навыков, которые потом обязательно пригодятся.

спасибо за советы! ну до браузера я еще точно не дорос)) да и в С# не шарю..решил Будут по-тихоньку в сторону Qt двигаться..

Эх, а я в 5 лет хотел стать программистом, еще не зная, шо це есмь а к сдаче ЕГЭ пришлось "тормозить" себя: придумывал изощренные методы решения. Бабульки не поймут..Я тоже сейчас учусь на нем писать Удобный с большой буквыДля использования как компилятор\отладчик ее особо изучать не надо

А я кстати, думаю, под какие библиотеки учиться писать.. вроде как .NET удобен, но не особо портируем.. GTK, Qt.. что посоветуете вы?

начал почитывать про Qt- очень понравилась книжка(Шлее Qt 4.5 в подлиннике). Порадовала документация-действительно доступная и доходчивая, хотя я и не особо силен в Английском. Устройство самих библиотек тоже понравилось(по сравнению с MFC))) Собстно, в планах серьезно взяться за Qt, а потом уже может и основы MFC получится одолеть(считаю что это все таки необходимо)

Автору тему могу сказать следующее (у меня скоро будет 10 лет программирования,из них почти 5 промышленного):

Первое: важно понимать, что если вы собираетесь работать в индустрии или в другой отрасли на позиции программиста, то от вас потребуется не только знание языка С++, но и знание других технологий, таких как SQL, COM, XML, к примеру. И на одном С++ вы сможете куда-то "уехать" только в исключительных случаях.
Второе: существует тенденция, что С++ скоро умрет (а кто-то его уже считает мертвым языком, конечно, абсолютно незаслуженно). Точно можно сказать одно - он требуется все меньше и меньше, а в секторе бизнес приложений под заказ он практически не востребован, с оговоркой, что иногда и это встречается. Где он реально до сих пор востребован - это gamedev, яндекс и подобные монструозные проекты, а также коробочные решения.
Я рекомендую вам его бросить и посмотреть в сторону Java/C#.
Третье: Много проектов сегодня - это WEB проекты. Нужно изучать Web технологии, а так же базы данных.
Без этого - вы не промышленный программист.

Четвертое: Промышленное программирование и то, какой взгляд на программирование дают в универе - это достаточно сильно различающиеся вещи. Во время работы вам придется далеко не только писать код, но и понадобится анализировать требования заказчика, формировать понимание модели и процесса ПО, которое вы делаете, работать в команде вместе с тестерами и аналитиками, которые будут решать немного иные, но в конечном счете, одинаковые с точки зрения достижения одной цели задачи. Придется думать над архитектурой и функциональной декомпозицией продукта. Также вы будете работать по определенной методологии. Всему этому в универе практически не учат , да и научиться можно только на практике. Однако, начальные знания можно получить заранее. - Попробуйте начать с википедии. Слова для поиска: RUP, Agile methodolgies, Software Engineering

Надеюсь, я вас не сильно нагрузил.
Резюмировать можно так: Язык + технологии(БД, WEB, XML, прочие) + знание методологий и архитектур

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

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


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

ToSHiC Математику или алгоритмизацию ? А почему именно "или" ? =) То есть с плохой математикой (высшей конечно) и хорошей алгоритмизацией тоже нормально?

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

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


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


На С++ ? Какой в этом смысл? Java рулит, программируй-нехочу. Если под WIndows Mobile - можно на Сишарпе.
Что касается performance, то я не думаю, что его падение ощутимо заметят. Если только в каких-нибудь особо жрущих играх.


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

Бывают дискретные и непрерывные алгоритмические/математические методы.
Все что было названо нематематикой : красночерные деревья, машины состояний, паттерны и прочие подобные объекты относится к дискретной математике и возникает на практике в явном виде чаще, чем
Непрерывные методы, которые оперируют числами, а не структурами. К таким методам относится линейная алгебра, диффуры, экономико-математические методы, да и элементарная арифметика тоже, вообще говоря.
Поэтому, сделаем оговорку, что реже встречаются именно продвинутые непрерывные методы. Элементарные - сплошь и рядом.

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

BSS/OSS системы, например. если грубо - то, что стоит заказчику больше 10 миллионов долларов. от начала разработки до первого внедрения у таких систем проходит, обычно, несколько лет, а затем они обычно используются лет по 10-15, с доработками в рамках новых версий, естественно.

симбиан с маемо, например. но гуи на с++...

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

Окей, спасибо. Теперь могу ответить на счет методологии.
Заранее скажу, что я сам лично не внедрял OSS,поэтому ничего не могу сказать по специфическим моментам их особенности. итд. В соседнем отделе со мной работают люди, которые этим занимаются.
Итак, две вещи:
1) В данном топике речь идет о чистом программировании, именуемом в промышленности "custom development", как вы знаете. К нему OSS отношения не имеет. Это сектор вендорских решений, по сути готовых. Действительно, получается, что Agile тут и не причем.
2) С другой стороны, знание Agile практик во-первых расширяет кругозор разработчика, а во-вторых - некоторые элементы Agile могут быть легко позаимствованы в отдельных случаях для использования в более тяжеловесных методологиях. За примерами идти далеко не нужно. Несколько
проектов, в которых я участвовал на уровне менеджмента были устроены как RUP, а на уровне мелких суб-команд были устроены как некий извращенный вариант итерационного scrum. При этом все замечательно работало и никто не увлекался.


Да, у меня в универе было несколько курсов по ЦОС. Хорошо представляю. о чем вы говорите. К сожалению (или может быть счастью) эти знания никогда в индустрии мной по понятным причинам на практике не применялись С вашей позицией готов согласиться.

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

Непосредственно автору: возможно вы на данном этапе не все понимаете, что было нами упомянуто.
Однако, некоторые основные мысли мы выделили. Если есть вопросы - в привате, чтобы не кричал никто, что мы тут оффтопим жутко

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

в активном запасе надо держать не языки, а концепции программирования, "уметь программировать в целом"©. я бы даже разделил процесс на "программирование" и "кодинг" (опять проблема с терминологией...). если ты можешь хорошо представить себе картину, как ЭТО должно работать - то реализовать будет легко даже на малознакомом языке. да, разные языки накладывают свои особенности стиля, но ООП, к примеру, при этом остаётся всё тем же, а императивное программирование на ассемблере не сильно сложнее программирования на паскале. освоение концепций даётся тяжело, освоение языков, основанных на этих концепциях - легко.

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

Все зависит от "диаметра" вашей головы
Если серьёзно, то индустриальный программист постоянно использует не менее двух языков в бою. (например, C# и Transact SQL) Кто-то использует больше. Не нужно думать, что если появится задача на языке, который был успешно забыт прошлым летом, условно говоря, то от вас потребуется вспомнить его моментально. Работа в индустрия - это в том числе работа и с документацией. Если вы раньше что-то знали - посмотрите examples + docs и вы снова готовы, обычно так.


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

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

Ибо я так понял, что единственный способ развития - самообразование, причём жёсткое.

Может.
От чего же. http://www.intuit.ru/department/pl/funcprog/1/ - вот например
(Кстати,неплохой видеокурс. Но не для новичков.)

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

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

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

К тому же, ещё один вывод - если софт прекрасно работает , то не факт, что внутри него не сидят три носорога и две обезьяны В индустрии такое бы тоже прокатило, если бы код не увидел какойнить Senior Lead Programmerl. Тестер бы протестил - все работает и его бы залили в билд ))

Aside Я вообще не понимаю этот код, но проверка выглядит страшно. Зачем делать циклы по двум числам. Потом прибавлять им +1 и обнулять их снова при цикле? Только эти nobjects ограничивают цикл.
Это же получается, что эта фигня всегда будет выполнять if( i == j) continue;

P.S. Си знаю очень-очень поверхностно.
Или i=0 , j=0 в операторе for просто создаёт эту переменную, а в цикл не входят?) Но всё равно какой-то бред.