Илья

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

Например, ваше представление: "ООП удобен для бизнеса, можно разделять программу на модули" - неверно.
Модульность появилась задолго до ООП. Бизнес появился задолго до программирования, и ООП и бизнес не слишком и связаны.

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

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

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

И напоследок - полиморфизм и все другие фичи ООП - это уже следствие того, что парадигму стараются сделать максимально гибкой.
Самая главная суть ООП заключается в следующем:

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

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

Практика и еще раз практика!
Попробуйте книгу "Решение сложных задач на С++" порешайте, читайте разъяснения, там, глядишь и понимание придет.

Многое из того, что вы хотите есть у Майерса. Он дает советы по использованию различных возможностей C++, в процессе разъясняя, почему нужно делать именно так (т.е. как оно работает), в каких случаях это не работает и почему у некоторых конструкций такой неудобный синтаксис. По C++03 - это "Эффективное использование C++. 55 верных советов улучшить структуру и код ваших программ", там есть немного устаревшие вещи, но для понимания причин добавления различных элементов в новые стандарты это даже полезно. Её дополняет "Эффективный и современный С++. 42 рекомендации по использованию C++11 и C++14" - там про новые стандарты, с предыдущей практически не пересекается.

Много интересных статей на английском (точнее, ссылок на них) есть на https://www.reddit.com/r/cpp/ , но это больше для просмотра актуальных новостей, целенаправленно искать там что-то довольно сложно.

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

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

P.S. Без CRT кода просто твой C/C++ код компилируется в то, что ты написал. Нет ни единой чужой строчки кода. Ты просто видишь, во что компилируется код и понимаешь что все компилируемые языки это просто упрощение жизни, а не изобретение чего-то нового. Все эти парадигмы все равно сводятся к языку ассемблера, какие бы они не были. Собственно, и интерпретируемые языки - это просто ассемблерный код, анализирующий текст и в зависимости от того че там написано выполняющий какие-то действия.

Но есть и минус. Придет полное непонимание интерпретируемых языков в плане работы с памятью. Будешь мыслить уже в контексте указателей. Я иногда реально жестко туплю, казалось бы, на простых элементах языка Python.

Не благодарите.
А если хотите для старичка, то это:

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

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

Я вижу несколько способов разрешения зависимостей.
Во-первых, можно собрать libcurl и libjansson статически и прилинковать к вашему приложению.
Во-вторых, помимо статических libcurl и libjansson можно собрать сам Qt тоже в статику и прилинковать к вашему приложению. На выходе вы получите исполнительный файл большого размера (размер можно урезать с помощью утилиты upx), который будет запускаться во всех современных дистрибутивах GNU/Linux, где есть иксы.
В-третьих, самый рациональный способ - собрать DEB- или RPM-пакет, в котором в зависимостях прописать пакеты libcurl3(4), libjansson4, и необходимые модули с qt4(5).

Ну а запустить сам бинарь просто. У вас в Qt Creator'е есть переменная окружения LD_LIBRARY_PATH. Просто скопируйте в терминал её значение перед запуском программы:

LD_LIBRARY_PATH="/opt/QtSDKs/Qt5.3.1/5.3/gcc_64/lib:/opt/QtSDKs/Qt5.3.1/5.3/gcc_64/lib:/home/user/projects/jansson/lib:$LD_LIBRARY_PATH" ./my_cool_app

Curl у вас, похоже, собран статически. Попробуйте собрать jansson тоже в статику. Тогда ошибки error while loading shared libraries: libjansson.so.4: cannot open shared object file: No such file or directory вы не получите.

Работал.
Устроится можно - тут совершенно правильно подсказали, что изучите требования на сайтах работодателя и постарайтесь под них подстроится. Изучите технологии, которые востребованы в описаниях вакансий. Очень советую написать несколько статей и дать в резюме на них ссылки. Этим хоть как то можно показать свою экспертность. Это ценится. Очень нелишне будут всякие сертификаты. Можно от Майкрософта, очень неплохо от Оракла - оракл часто юзают в банковской сфере. Так же как и Sybase. По MSSQL тоже можно. MCSD не помешает. Жаль по юниксу нет (скажем так лично я не знаю) представительных сертификаций но можно найти что то на BrainBench.
Из преимуществ работы в банке могу сказать, что наверно у программистов банковских программ скорее выше зарплата. И она достаточно стабильна. На этом пожалуй все преимущества заканчиваются и начинаются недостатки.

А именно - в банках есть некое негласное разделение золотые воротнички (высший менеджмент, который обитает в своих сферах и редко снисходит - у них там своя вселенная со своими законами своей гравитацией и законами физики) , белые воротнички - клерки и синие. Это уборщики, техперсонал и ... программисты, как правило. Я не могу сказать про все банки ... но будучи сам и белым и немного позолоченным и потом программистом могу сказать что в целом картина такая. Наверно есть оазисы ... но сейчас не могу сказать, давно ушел из мира банков, хотя сейчас работаю именно в области финансов.
Т.е. отношение .. ну как к тех персоналу. Какая-нибудь тетя из кредитного отдела, у которой обязанности нажимать в день две кнопки, по которым получается какой-нибудь отчет для начальства будет смотреть с высоты своего положения :) немного свысока на молодого выпускника физтеха кто во сне решает дифуры сходу.
Работа как правило тоже малоинтересная с точки зрения программиста - довольно скучные приложения в основном клиент сервер туда сюда данные, формы, формы с числом полей приближающихся к бесконечности, джава апплеты зачастую страшные как атомная война.
Но это еще хорошо, ибо большая часть работы это поддержка. И это самый ужос. Копаться в технологиях, зачастую древних как мумие мамонта. Я сейчас работаю на американскую финансовую контору - так там даже еще майнфремы пашут. Все это было написано тогда когда еще компьютеры были большими и тепло-ламповыми и везде ползали трилобиты и трилобайты. И самое страшное, что это все работает. На эмуляторах конечно. Представьте себе эмулятор под древний майнфрейм - и причем оный эмулятор работает из под винды. А на нем проги бегут на Алголе. И ЭТО рулит реальными (по российским масштабам нереальными) деньгами. Как … никому не ведомо. Интересно? И это в то время как космические бульдозеры сравнивают Большой театр за самострой :).
Сюда прибавить бюрократию и строгую иерархию (начальник моего начальника не мой начальник) – никаких диванчиков в стиле гугла и яндекса и детских игрушек. Все строго с 9 и до "солнце еще высоко" – обеды в офис и все такое. Никаких, как правило, удаленок и прочих элементов сладкой жизни. Опять же, как правило, никаких поездок и загранкомандировок с интеллектуальными играми, тургеневскими барышнями, ночными освежающими прогулками по Тендерлойн и Кастро в Сан Франциско (для тех кто понимает :)), веществами и напитками в номер. Для рядовых программистов конечно.
Как правило, весь действительно интересный софт для банков пишут отдельные конторы. Хотя есть гиганты в, которых довольно мощные центры разработки. Есть в Москве такой банк из крупных международных.
Т.е. если интересная финансовая сфера, то лучше таки пойти в контору, которая изначально программисткая и для программистов. Работа там гораздо интереснее и вы как вроде там не синий воротничок на седьмом киселе, а самая что не на есть белая кость и уважаемый человек – одним словом Программист, а не какой то там клерк :).
В связи с массовым «импортозамещением», платными парковками и прочими радостями современных реалий (вт.ч. курсом доллара) многие конторы сейчас переводят весь персонал в какие то более теплые и спокойные страны, что конечно делает жизнь скучнее но работу плодотворнее и вообще открывает перспективы. Да и свой евро ближе к телу. Так что может повезти чего не скажешь, про работу в среднем Российском банке. Ах да из преимуществ можно еще отметить мегакорпоративы на новый год )) Но это только раз в году. Так что преимущество сомнительное тем более, если не любитель пышных женщин и вообще жизненных излишеств.
Вот где действительно интересно – это все что связанно с биржами и трейдингом. Это некий свой особый мир, лежащий чуть в стороне от классического банкинга (читай расчеты). Это специфическая область и там все серьезно и плане математики и в плане технологий. Одна из лучших контор в которой мне довелось работать, это контора связанная с биржевыми данными и трейдингом. Контора американская, но работает в Москве. Очень высокий уровень разработки и культуры управления. Требует серьезного уровня подготовки. Все в основном на С++ и С - все остальное по скорости безнадежно сливало – работа в терминах микросекунд) под правоверный линкус. Советую, если не радует рутинная бесконечная унылая работа рваться в эту область. Еще можно попробовать оценки рисков. Но вообще советую именно программерскую контору а не банк. Кстати мир загнивающего капитализма точно такой же, а не только в России такая картина. Тока на загнивающим надо пару нулей приписать к любой цифре, ну и в долларах все, а так в принципе то же самое.
Но в трейдинговых конторах интересно, особенно если допустят до торговых алгоритмов. Для этого нужна хорошая мат. подготовка и программерская тоже. Но там зарплаты бывают ну очень большими и бонусы еще.. бонусы
На хабре есть цикл статей от ITinvest – можно поискать .. почитать проникнутся. Написано очень интересно. Я проработал в этой области много лет но и сам много чего нового и интересного нахожу. Так на всякий случай я с ITinvest никак не связан вообще – так что с них стакан мангового сока за рекламу.

Если сухой остаток то советую C C++ (Страуструп, Мейерс, Александреску, Саттер помогут и подскажут стандарты 11, 14, 17, boost и stl само собой после всего советую C++ Concurrency in Action, Williams - THE MUST и совершенно адскую книжищщу Addison.Wesley.C++.Template.Metaprogramming.Concepts.Tools.and.Techniques.from.Boost.and.Beyond - вырыв мозга с корнем), к сожалению много стало Java (не люблю жаву но реальность данная нам в ощущениях такова), хорошее ... очень хорошее знание Linux (само собой bash и Perl, Linux.in.a.Nutshell.6th.Edition - хорошая), Python совсем не лишен, алгоритмы - особенно на загнивающем - страсть как любят алгоритмы, 80% времени собеседований не про языки а про алгоримы ( советую скачать Introduction to Algorithms 3th, Cormen, Leiserson, Rivest, Stein.pdf ну и Кнута конечно) и очень хорошо это знание стека протоколов TCP/IP (UNIX._Network_Programming._3rd_ed Стивенса). Еще POSIX многопоточность - я лично учился по Системное программирование на C++ для Unix, Теренс Чан - книжка старая но по моему не потеряла актуальность и Unix Взаимодействие процессов, Уильям Стивенс и QNX-UNIX. Анатомия параллелизма, Цирюлик .О - последняя написанна просто и толково). С этим багажом можно уже выходить на очень приличный уровень. Конечно сразу не взять такой объем но в целом как то так. Ах да .. и английский конечно. На нормльном разговорном уровне.

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

"Coding: You should know at least one programming language really well, preferably C++ or Java. For specific projects, we do also use C
and Python but these are normally secondary languages at Google. You will be expected to write code in most of your interviews. You will
be expected to know a fair amount of detail about your favorite programming language. Make sure to check out our Google code style
guides. You will be expected to know about API’s, OOD/OOP, how to test your code, as well as come up with corner cases and edge cases
for yours and other peoples code.

Algorithms: You will be expected to know the complexity of an algorithm and how you can improve/change it. Big-O notations also
known as the run time characteristic of an algorithm. If you get a chance, try to study up on fancier algorithms, such as Dijkstra and A*. For
more information on algorithms you can visit TopCoder.

Sorting: What common sorting functions are there? On what kind of input data are they efficient, when are they not? What does
efficiency mean in these cases in terms of runtime and space used? E.g. in exceptional cases insertion-sort or radix-sort are much better
than the generic QuickSort / MergeSort / HeapSort answers.

Data structures: You should study up on as many other structures and algorithms as possible. You should especially know about the
most famous classes of NP-complete problems, such as traveling salesman and the knapsack problem. Be able to recognize them when an
interviewer asks you in disguise. Find out what NP-complete means. You will also need to know about Trees, basic tree construction,
traversal and manipulation algorithms, hash tables, stacks, arrays, linked lists, priority queues.

Mathematics: Some interviewers ask basic discrete math questions. This is more prevalent at Google than at other companies
because counting problems, probability problems and other Discrete Math 101 situations surrounds us. Spend some time before the
interview refreshing your memory on (or teaching yourself) the essentials of elementary probability theory and combinatorics. You should
be familiar with n-choose-k problems and their ilk – the more the better.
"

Всего дело то :))

Не представляю, как вы пользуетесь этой вашей IDLE. Один раз, при знакомстве с питоном, зашёл в неё, вышел и перекрестился.

Для лёгких скриптов на <100 строк - любой встроенный редактор: gedit, pluma (можно sublime)
Для всего остального - PyCharm