Książki przedstawiające różne aspekty programowania w sposób sformalizowany

Czy możecie polecić jakieś książki, publikacje (poza dokumentacją), które przedstawiają zagadnienia typu "różnice między metodologiami zdarzeniową, proceduralną, strukturalną" itp. w bardziej formalny sposób? Dość dobrze czyta mi się tego typu pozycje ale nie chciałabym zakupić kilku książek tylko po to żeby przekonać się, że jednak nie są pisane takim językiem albo nie przestawiają zagadnień w konkretny sposób. Coś w takim tonie o programowaniu grafiki, DirectX, jeśli w jakimś stricte języku pozycje to C++, C#.

Gdyby komuś coś przyszło do głowy to będę wdzięczna za sprawdzone propozycje

Zacznij od tego
„Structure and Interpretation of Computer Programs”, Gerald Jay Sussman, Hal Abelson

Za darmo legalnie w sieci.

Tak się kiedyś uczyło od podstaw, formalnie na MIT. W Polsce to była, jest i będzie obowiązkowa pozycja do bibliografii na większości magisterek z tematów teoretycznych na informatyce jagiellońskiej.
Mojej mgr też.

Takie książki(i materiały) wymagają zwykle albo znajomości Lispa, Haskella, albo różnego rodzaju notacji matematycznych. I ja zwykle ich totalnie nie rozumiem. Chociaż przymierzam się, żeby coś poczytać, co napisał choćby Leslie Lamport, Conal Eliott czy inni goście, którzy mają może i dobre koncepcje, ale tłumaczą je właśnie w sposób bardziej formalny. Są wzory, symbole albo odwoływanie się do Haskella czy innych "trudnych" języków.

No ale ja jestem samoukiem, pewnie każdy absolwent polibudy bez problemu by to zrozumiał, w końcu uczą ich tam matmy czy podobnych rzeczy.

które przedstawiają zagadnienia typu "różnice między metodologiami zdarzeniową, proceduralną, strukturalną" itp. w bardziej
formalny sposób?

Chociaż mam wrażenie, że ty aż tak dużej formalności nie szukasz, a po prostu chcesz mieć coś bardziej konkretnego? No to do mnie przemawia Martin Fowler (nie wiem czy jakąś książkę napisał, ale na swojej stronie opisuje masę rzeczy z OOP, wzorców, metodologii itp.)

które przedstawiają zagadnienia typu "różnice między metodologiami zdarzeniową, proceduralną, strukturalną" itp. w bardziej
formalny sposób?

Z drugiej strony nie wiem, czy znajdziesz takie konkretne nakreślenie różnic, ponieważ one często się rozmywają w realnym świecie, poza tym sam podział może być nieaktualny. Ja np. nie łapię różnicy między p. proceduralnym a strukturalnym, jak patrzę na definicje z wikipedii. Ale może dlatego, że to już archaiczny podział który wziął się z konkretnych uwarunkowań historycznych w drugiej połowie XX wieku. Wg wikipedii w połowie XX wieku ludzie jechali na goto, a programowanie strukturalne było krokiem naprzód https://en.wikipedia.org/wiki/Structured_programming (tylko kto dzisiaj jedzie na goto?). Proceduralne programowanie już ma bardziej sensowną definicję: https://en.wikipedia.org/wiki/Procedural_programming

LukeJL napisał(a):

Ja np. nie łapię różnicy między p. proceduralnym a strukturalnym

Cztery paradygmaty: imperatywny, deklaratywny, obiektowy, funkcyjny. W zasadzie to od zarania dziejów tylko dwa: imperatywny, deklaratywny.
Imperatywny: krok po kroku dokładnie jak co wykonać. Od assemblera po Javę.
Deklaratywny: opisanie co chce się otrzymać, bez opisywania jak to zrobić. SQL (SQL QDL), programowanie funkcyjne.

Funkcyjny, to taki deklaratywny, używa się jak w matematyce, kompozycji funkcji i tworzy funkcje. Sin(x) opisuje, że chcemy dostać sinusa z x-a jak podamy x-sa, nie opisuje deklaracji zmiennych, pętli, algorytmu obliczania.

Obiektowy, taki worek do którego wrzuca się obiekty, a że obiektem może być wszystko i jeszcze obiekt to stan i działanie, to z dziedziczeniem można zrobić wszystko. Z tego wszystko okazało się, że nic porządnie, dlatego pozbierano tak zwane dobre praktyki i powstały wzorce projektowe.
W skrócie, nie ma takiego mądrego który by nie zgłupiał definiując czym obiektówka jest a czy nie jest.
Można powiedzieć, że to takie coś dla Programistów15K żeby mogli pisać deklaratywne zwykłe CRUDy w sposób Obiektowy15k.

I taki podział do mnie również przemawia. Też bardziej różnicuję rzeczy na deklaratywne / imperatywne, niż na paradygmatypu OOP, funkcyjne, proceduralne (ponieważ to i tak się miesza - można używać OOP do pisania proceduralnego, można mieszać OOP z funkcyjnym, można pisać obiektówo za pomocą programowania proceduralnego itd.
A deklaratywność kontra imperatywność to podział, który jest bardziej wyraźny (mimo, że to w zasadzie całe spektrum odcieni między deklaratywnością i imperatywnością). Czy może nie tyle wyraźny (bo mam wrażenie, że jest to często subiektywne), co po prostu bardziej praktyczny podział. Np. z faktu czy coś jest OOP czy funkcyjne czy proceduralne nie wynika specjalnie nic - a z faktu, że np. coś jest deklaratywne wynika dużo (bo wtedy myśli się deklaratywnie, i pisze "co" zamiast "jak"), tak samo rzeczy imperatywne też się inaczej pisze.

A FP, OOP, proceduralne? To można pisać tak samo zawsze (i tak pewne zasady się nie zmieniają, i jeśli wyznawcy programowania funkcyjnego mówią, że mutowalny globalny stan jest zły, to nawet pisząc proceduralnie czy OOP to odczujemy i będziemy chcieli pisać tak, żeby zminimalizować ten mutowalny globalny stan, bo to zdrowy rozsądek). Tak samo jak wyznawcy OOP mówią, że ważna jest zasada SRP, to w innych paradygmatach też będzie miało to znaczenie.

Dzięki wszystkim już zawsze coś fajnego wpadło :)

agiehowiak stary napisał(a):

Cztery paradygmaty: imperatywny, deklaratywny, obiektowy, funkcyjny. W zasadzie to od zarania dziejów tylko dwa: imperatywny, deklaratywny.

Alonzo Church miał doktoranta Alana Turinga
Church stworzył rachunek lambda - paradygmat funkcyjny.
Turing stanową maszynę, nazwaną jego imieniem - paradygmat imperatywny.
Dwóch wielkich matematyków, dwa paradygmaty. Reszta czerpie z tych dwóch źródeł.

C++ powstał tylko po to aby wszystko utrudnić i skomplikować.
snopes.com/fact-check/program-management/

Hej,
jeden z lepszych kursów poruszających tego typu problemy, ale raczej w sposób praktyczny: https://www.coursera.org/learn/programming-languages