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

булева алгебра, шось таке, я просто пам'ятаю, що там показували, що можна робити з 1 і 0

ООП - один із способів програмування (як і ФП). Розробляти великі проекти без ООП досить складно.
Єдина проблема, з якою зіштовхуйуться програмісти, які використовують ООП, - це те, що мови програмування (C#, C++, Java, Object Pascal, PHP, Ruby) реалізують ідеї ООП не в повному обсязі, в кожній з перелічених мов я знайшов недоліки, які не дозволяють програмісту побудувати правильну (з точки зору ООП) архітектуру, процес проектування (побудови архітектури) перетворюється на кошмар і написання костилів.
Але програмування в стилі ФП нічим не краще.

Припускаю, Ви не вивчали або не засвоїли ООП.
ФП, звичайно, не вимре, але майбутнє за ООП.

Чому? Роблять же без ООП всякі лінукси і докери.

Я б сказав, є задачі, де ООП справді полегшує розробку, а є випадки, де це просто нав'язаний патерн.

наче Америку відкрили, всі ці ооп і т.д. лише інструмент, і ясний пєнь, якщо вам треба полагодити змішувач, то бензопила для цього непотрібна, ліііл

Так.
Розробники Java (ті що пишуть саму мову) із новаторів перетворилися на консерваторів. Для них підтримка старого байт-коду стала важливішою ніж розширення можливостей мови (в плані проектування).
Мені їх шкода, вони закопують власні можливості.
Людям потрібна нова об'єктно-орієнтована мова програмування, просто вони ще не знають про це.

Я думаю, що якщо людина пише процедурний гкод, то після ООП, це буде той таки гкод, запхнутий в класи/обєкти. (може більш впорядкований - гкод).

wat?
що складно без ооп?

по-перше, правильна архітектура великого проекту не залежить від мов програмування, движків баз даних etc
правильна - означає що вона готова до легкого і швидкого горизонтального масштабування - поставив ще один сервер, за пару хвилин код залив, одну строчку відредагував -- все, потужності додано, проект далі на взлеті))

це так як знайомий програміст, оперуючи застарілими 4 роки назад фактами про mysql - запевнює всіх що на mysql неможливо великий проект запустити, "оскільки він блокує всю таблицю, і взагалі mysql це для маленьких проектів, використовуйте оракл (далі ода любові до оракла)" --- про innoDB не чув, про сайт-злодій не чув, який працював на mysql до написання власних двигунців бд))

по-друге, прозорість проекту у першу чергу залежить від правильної архітектури та строгого упорядкування файлів --- на днях трошки працював у якості фрілансера над одним сайтом -- файли розкидані як попало, дизайн і тут і там, функції і тут і там, папки розкидані як попало, жодного порядку))
пів-дня йде щоб знайти файл і 5хв щоб відредагувати

----

чому це фп нічим не краще?
краще - тому що прозоріше,
краще - тому що швидше працює,
краще - тому що не клепає мізки ні програмісту, ні серверу))

---

майбутнє за ооп? як би не так

по-перше, майбутнє за веб-сокетами, оскільки кількість пристроїв і запитів росте, а нічого окрім вебсокетів кращого за класичні http запити ще не придумали, а сервер може обробити рівно стільки користувачів - скільки зєднань може витримати - тут вебсокети рулять

по-друге, виходячи з вебсокетів та кількості з'єднань - ми плавно переходимо до того що нічого кращого за erlang ще не придумали
хтось може розкричатися що є node.js, але нода програє відразу по декількох параметрах - і меньша кількість зєднань, і проблеми з памяттю, і відсутність решти плюшок erlang-а
ще хтось може згадати про Go - втім erlang залишає позаду і його)

по-третє ми говоримо про майбутнє --- як тут не згадати про нейронки -- а у erlang вони з-коробки, як особливість мови програмування))

майбутнє за erlang-ом та його надбудовами - elixir, etc
(звісно, asm та c/c++ нікуди не подінуться)