Podział języków programowania, ze względu na paradygmaty w których znajdują zastosowanie.

Dzień dobry. Potrzebuję pomocy przy uporządkowaniu listy. Mianowicie, chce dane języki programowania dopasować do paradygmatów, w których znajdują zastosowanie .

Paradygmaty :
a) programowanie proceduralne
b) programowanie strukturalne
c) programowanie funkcyjne
d) programowanie imperatywne
e) programowanie obiektowe
f) programowanie wizualne
g) programowanie uogólnione
h) programowanie logiczne
i) programowanie aspektowe
j) programowanie deklaratywne
k) programowanie agentowe
l) programowanie modularne

Języki programowania :

1. Java

2. Python

3. C

4. C++

5. C#

6. Visual Basic

7. JavaScript

8. Perl

9. Objective-C

10. Rust

11. Scala

12. Pascal

13. Go

14. PHP

15. Node.js

16. Kotlin

17. Ruby

18. R

19. Groovy

20. Matlab

21. Asembler

22. SQL

23. Swift

24. Delphi

25. HTML

26. XTML

27. CSS

Na ten moment udało mi się stworzyć takie dopasowania, ale tylko języki w przedziale nr 1-12. Niektóre języki opisane są jako wieloparadygmatowe, jednak nie znajduje konkretnych podziałów, dlatego potrzebuje pomocy. Może jeszcze jest jakiś rodzaj paradygmatu, który warto dodać ?

Paradygmaty :
a) programowanie proceduralne - (4) C++, (12) Pascal
b) programowanie strukturalne - (1) Java, (10) Rust, (3) C, (12) Pascal
c) programowanie funkcyjne - (1) Java, (2) Python, (4) C++, (7) JavaScript, (8) Perl, (10) Rust, (11) Scala
d) programowanie imperatywne - (1) Java, (2) Python, (3) C, (7) JavaScript, (8) Perl, (10) Rust
e) programowanie obiektowe - (1) Java, (2) Python, (4) C++, (6)Visual Basic (7) JavaScript, (8) Perl, (9) Objective-C, (10) Rust, (11) Scala,
f) programowanie wizualne
g) programowanie uogólnione - (4) C++
h) programowanie logiczne
i) programowanie aspektowe
j) programowanie deklaratywne
k) programowanie agentowe
l) programowanie modularne - (4) C++

To
HTML

XTML

CSS
To nie są języki programowania:
j) programowanie deklaratywne - SQL
f) programowanie wizualne - LabView - nie masz na liście

html to nie jest jezyk programowania

nodejs -> funkcyjne, obiektowe

W odniesieniu do komentarzy z pierwszego posta dodam tylko, że jak już chcesz to dzielić, to dziel ze względu na zastosowanie.

@marcyse: node to nie język programowania xd

szafran98 napisał(a):

W odniesieniu do komentarzy z pierwszego posta dodam tylko, że jak już chcesz to dzielić, to dziel ze względu na zastosowanie.

Tak naprawdę nie wiesz co jest jego celem i po co on to dzieli. Jak chce po paradygmatach to niech dzieli po paradygmatach.

Martin9410 napisał(a):

Paradygmaty :
a) programowanie proceduralne
b) programowanie strukturalne
c) programowanie funkcyjne
d) programowanie imperatywne
e) programowanie obiektowe
f) programowanie wizualne
g) programowanie uogólnione
h) programowanie logiczne
i) programowanie aspektowe
j) programowanie deklaratywne
k) programowanie agentowe
l) programowanie modularne

Tabelka jest z czapy, porównuje jablka do orzechów.
"programowanie uogólnione" wtf ?
agentowe, aspektowe nie są samodzielnymi językami (paradygmatami), to sposób w innych języakch/paradygmatach
wizualne to porównanie rowerów do jabłek. To bardziej pytanie o IDE / libkę komponentów
modularne / proceduralne / strukturalne dziś to ten sam "cloud", to się odróżniało jak trzeba było nadać nazwę nowemu stylowi, dziś po pierwsze mam małe znaczenie, po drugie wszystkie trzy są de facto złączone.

Zamiast zajmować się jakimiś bezsensownymi rzeczami, to weź dowolny język, przejdź tutorial, napisz jakiś Hello, world czy coś. Teraz wydaje Ci się, że robisz coś pożytecznego, a tylko tracisz czas. — Saalin 16 minut temu

Zgadzam się w 200%

Ale wiesz że w niektórych językach możesz używać kilku paradygmatów na raz? I nie mówię "raz tego, raz tego" (jakieś zarty o językach "hybrydowych") tylko o kodzie autentycznie napisany wykorzystując dwa paradygmaty.

Częstym przykładem jest kod zarówno obiektowy jak i funkcyjny.

Saalin napisał(a):

Obiektowy z zewnątrz, funkcyjny w środku, niczym https://en.wikipedia.org/wiki/Molten_chocolate_cake

Nie o to chodzi.

Paradygmat funkcyjny w swojej podstawie ma nie redefiniowanie utworzonych zmiennych (jakbyś np w JS pisał tylko const, nigdy let/var) i korzystanie z "pure funkcji". Obiektowy zaś polega na hermetyzacji szczegółów implementacyjnych w obiektach. Nie ma powodu czemu nie mógłbyś napisać kodu który robi obie te rzeczy jednocześnie.

Martin9410 napisał(a):

l

b) programowanie strukturalne - (1) Java, (10) Rust, (3) C, (12) Pascal

"strukturalnie w javie" -??? - to tylko gwałcąc proponowane użycie języka.
Jak poszerzasz tabelkę o gwałcenie, to każdy paradygmat w każdym języku.

A już całkiem serio, wielokrotnie pisałem obiektowo w C (nie C++), zdarzało się a'la funkcyjnie w Lua, aspektowo w Python,
a nawet obiektowo w Delphi :) (herezja, apage satanas, - senior projektu to skasował z repo)

bezsensowny, to po co wspomina się o paradygmatach w opisie języka . — Martin9410 3 minuty temu

Żeby dać jakieś miękkie zagajenie, zamiast jechać z syntaxem, hello world i dalej. Żeby powiedzieć "dzień dobry".
Słowo, które jest grzecznym wstępem, aby sie porozumieć, a ty wywlekasz jakieś wojny jak o przecinek w Biblii.

ZrobieDobrze napisał(a):

Martin9410 napisał(a):

b) programowanie strukturalne - (1) Java, (10) Rust, (3) C, (12) Pascal

"strukturalnie w javie" -??? - to tylko gwałcąc proponowane użycie języka.

W programowaniu strukturalnym chodzi po prostu o to żeby nie używać "sków wykonania" (control flow) takich jak np "goto", a zamiast tego używać zwykłych struktury języka, jak warunki, pętle, wyjątki.

Co do proceduralnego, możesz spokojnie używać klas i pisać proceduralnie. Chyba nie myślisz że "używanie klas == programowanie obiektowe"?

Jeśli ktoś myśli że programowanie strukturalne to "używanie struktur/rekordów", a obiektowe to "używanie klas" to jest całym źródłem niezrozumienia paradygmatów, i takich kwiatków że ktoś pisze metodami statycznymi i mówi "ęę PrOgRaMoWaNie ObIeKtowE".

ZrobieDobrze napisał(a):

Martin9410 napisał(a):

l

b) programowanie strukturalne - (1) Java, (10) Rust, (3) C, (12) Pascal

"strukturalnie w javie" -??? - to tylko gwałcąc proponowane użycie języka.
Jak poszerzasz tabelkę o gwałcenie, to każdy paradygmat w każdym języku.

Może zanim zaczniesz krzyczeć o grałtach to przeczytaj definiecje programowania strukturalnego?

W programowaniu strukturalnym nie chodzi o struktury danych, które od niedawnia Java ma pod nazwę rekordy.
Chodzi o struktury sterujące jak if/for

UPDATE a dokładniej to chodzi o nie używanie goto jak poniżej napisał @Riddle

Riddle napisał(a):

ZrobieDobrze napisał(a):

Martin9410 napisał(a):

b) programowanie strukturalne - (1) Java, (10) Rust, (3) C, (12) Pascal

"strukturalnie w javie" -??? - to tylko gwałcąc proponowane użycie języka.

A czemu niby? Możesz spokojnie używać klas i pisać proceduralnie. Chyba nie myślisz że "używanie klas == programowanie obiektowe"?

A po co uzywac klas? Klasy są dla p...
Można main i static metody ...

Ale ja to wiem.

No to czemu mówisz że używanie struktur kontrolnych ja if i for to gwałcenie języka? Jak inaczej chcesz sterowac programem bez ifa?

KamilAdam napisał(a):

Ale ja to wiem.

No to czemu mówisz że używanie struktur kontrolnych ja if i for to gwałcenie języka? Jak inaczej chcesz sterowac programem bez ifa?

Użycie WYŁĄCZNIE if i for jako jedynych środków ekspresji w programie Java (masowe w studenckich programach main + static) nie nazwiesz gwałceniem / kastracją ?

ZrobieDobrze napisał(a):

KamilAdam napisał(a):

Ale ja to wiem.

No to czemu mówisz że używanie struktur kontrolnych ja if i for to gwałcenie języka? Jak inaczej chcesz sterowac programem bez ifa?

Użycie WYŁĄCZNIE if i for jako jedynych środków ekspresji w programie Java (masowe w studenckich programach main + static) nie nazwiesz gwałceniem / kastracją ?

Ale używanie if i for nie wyklucza się z programowaniem obiektowym

ZrobieDobrze napisał(a):

KamilAdam napisał(a):

Ale ja to wiem.

No to czemu mówisz że używanie struktur kontrolnych ja if i for to gwałcenie języka? Jak inaczej chcesz sterowac programem bez ifa?

Użycie WYŁĄCZNIE if i for jako jedynych środków ekspresji w programie Java (masowe w studenckich programach main + static) nie nazwiesz gwałceniem / kastracją ?

W strukturalnym nie chodzi o używanie tylko if i for do kontroli przepływu programu - w skrócie to znaczy "nie używa goto". To jest programowanie strukturalne. Możesz sobie dodać klasy, polimorfizm, moduły, etc. ale to nie są narzędzia do kontroli przepływu, a o nich mówi @KamilAdam

O czym rozmawiamy?

Słowo "programowanie strukturalne" urobione zostało pewnie w latach 1970, aby podkreślić właśnie brak goto na rzecz if begin - end czy while { }
Na ów czas było to świeże i miało znaczenie, coś nazywało.

40-50 lat później nie wnosi NICZEGO jakościowego do rozmowy, do jasności dyskusji Używanie tego dzisiaj służy tylko "przykryciu" braków w innej argumentacji, wygodne jak się nie ma nic do powiedzenia własnymi słowami *) Jeśli autor wypowiedzi nie ma pary, aby powiedzieć coś od siebie o języku, zawsze może podnieść "paradygmat struktalny" .
Jak cała dyskusja że językowi koniecznie trzeba przypisać jakiś paradygmat, aby o nim mówić

Dziś tylko assembler nie jest strukturalny (choć nie dałbym sobie ręki uciąć)

*) porównam do wklejania na olx marketingowego opisu och i ach lustrzanki cyfrowej sprzed 20 lat. Dowód wyłącznie tego, że sprzedający ma ZERO pojęcia o fotografii, nigdy w życiu nie zrobił świadomie zdjęcia itd a jako taki, nawet nie jest w stanie zapewnić, ze wszystko jest sprawne.

ZrobieDobrze napisał(a):

O czym rozmawiamy?

Słowo "programowanie strukturalne" urobione zostało pewnie w latach 1970, aby podkreślić właśnie brak goto na rzecz if begin - end czy while { }
Na ów czas było to świeże i miało znaczenie, coś nazywało.

40-50 lat później nie wnosi NICZEGO jakościowego do rozmowy, do jasności dyskusji Używanie tego dzisiaj służy tylko "przykryciu" braków w innej argumentacji, wygodne jak się nie ma nic do powiedzenia własnymi słowami *)
Dziś tylko assembler nie jest strukturalny (choć nie dałbym sobie ręki uciąć)

*) porównam do wklejania na olx marketingowego opisu och i ach lustrzanki cyfrowej sprzed 20 lat.

No tak. Jeśli nie używasz dzisiaj goto (Ani innych rzeczy które potrafią zaburzyć w niejednorodny sposób kontrolę przepływu) to piszesz strukturalnie. Tak.

I co z tego?

1. Ale przecież dalej są jezyki które mają goto
2. swich w C (i podobnych językach) też jest krytykowany za to że nie jest strukturalny
3. continue/break w pętlach też są za to krytykowane
4. Nawet wielekrtone używanie return z funkcji/metody bywa uznawane za łąmanie programowania strukturalnego

KamilAdam napisał(a):

1. Ale przecież dalej są jezyki które mają goto
2. swich w C (i podobnych językach) też jest krytykowany za to że nie jest strukturalny
3. continue/break w pętlach też są za to krytykowane
4. Nawet wielekrtone używanie return z funkcji/metody bywa uznawane za łąmanie programowania strukturalnego

Akurat tutaj muszę się odezwać. Punkty 2,3,4 to brednie.

Nie goto samo w sobie jest problemem, ani nie skoki przepływu są problemem.

Tak na prawdę, to co jest "złe" to są skoki pomiędzy scope'ami. Skok w ramach jedngeo scope'u (jak return) albo skok z parenta do dziecka, albo dziecka do parenta (jak continue/break) są w porządku. One nie powodują problemów z działaniem, ani problemów z utrzymaniem. Z tego powodu, gdybyś użył goto ale tylko żeby skakać w ramach jednego scope'u, albo do scope'u rodzica, to to też byłoby całkowicie w porządku. Po prostu zaimplementowałbyś ifa z użyciem goto.

To dlaczego goto jest hejtowane, to dlatego że przy jego użyciu można również skakać pomiędzy całkowicie obcymi scope'ami, np można skoczyć ze środka jednego if'a do drugiego. Albo ze środka jednej pętli do innej. I to jest cały powód czemu używanie goto jest szkalowane.

Teoretycznie możnaby dopuścić do używania goto, gdyby kompilator odrzucał użycie goto pomiędzy obcymi scope'ami. To byłoby spoko - chociaż wtedy byłby właściwie tożsamy z return/continue/break/if/else.

Z tego powodu, gdybyś użył goto ale tylko żeby skakać w ramach jednego scope'u, albo do scope'u rodzica, to to też byłoby całkowicie w porządku. Po prostu zaimplementowałbyś ifa z użyciem goto.

No byloby w porzadku. Ale nie byloby zgodne z paradygmatem strukturalnym, czego nie rozumiesz?¯\_(ツ)_/¯

Riddle napisał(a):

KamilAdam napisał(a):

1. Ale przecież dalej są jezyki które mają goto
2. swich w C (i podobnych językach) też jest krytykowany za to że nie jest strukturalny
3. continue/break w pętlach też są za to krytykowane
4. Nawet wielekrtone używanie return z funkcji/metody bywa uznawane za łąmanie programowania strukturalnego

Akurat tutaj muszę się odezwać. Punkty 2,3,4 to brednie.

Nie goto samo w sobie jest problemem, ani nie skoki przepływu są problemem.

Tak na prawdę, to co jest "złe" to są skoki pomiędzy scope'ami. Skok w ramach jedngeo scope'u (jak return) albo skok z parenta do dziecka, albo dziecka do parenta (jak continue/break) są w porządku. One nie powodują problemów z działaniem, ani problemów z utrzymaniem. Z tego powodu, gdybyś użył goto ale tylko żeby skakać w ramach jednego scope'u, albo do scope'u rodzica, to to też byłoby całkowicie w porządku. Po prostu zaimplementowałbyś ifa z użyciem goto.

To dlaczego goto jest hejtowane, to dlatego że przy jego użyciu można również skakać pomiędzy całkowicie obcymi scope'ami, np można skoczyć ze środka jednego if'a do drugiego. Albo ze środka jednej pętli do innej. I to jest cały powód czemu używanie goto jest szkalowane.

Cóż, czytałem inną wersję i według niej to co piszesz to brednie :P
W tej wersji co czytałem to odkrycie że goto jest problematyczne miało nastąpić przy pisaniu optymalizatorów przy kompilatorach. Otóż odkryto że kod który nie używa goto łatwo się optymalizuje, a kod który używa goto trudno się optymalizuje.
A więc zasada jednego wejścia do bloku kodu i jednego wyjścia z bloku kodu pochodzi (a więc paradygmat programowania proceduralnego) pochodzi wprost z zaleceń jak pisac wydajny kod (łatwy do optymalizacji dla kompilatora).
Oczywiście dziś to już nie musi być prawda bo twórcy kompilatorów poczynili ogromny postęp jeśli chodzi o optymalizację kodu

KamilAdam napisał(a):

W tej wersji co czytałem to odkrycie że goto jest problematyczne miało nastąpić przy pisaniu optymalizatorów przy kompilatorach. Otóż odkryto że kod który nie używa goto łatwo się optymalizuje, a kod który używa goto trudno się optymalizuje.
A więc zasada jednego wejścia do bloku kodu i jednego wyjścia z bloku kodu pochodzi (a więc paradygmat programowania proceduralnego) pochodzi wprost z zaleceń jak pisac wydajny kod (łatwy do optymalizacji dla kompilatora).
Oczywiście dziś to już nie musi być prawda bo twórcy kompilatorów poczynili ogromny postęp jeśli chodzi o optymalizację kodu

Nie neguję. Możliwe że dwie osoby doszły niezależnie od siebie do podobnych wniosków.

To o czym ja mówię wynika z pracy Edgara Dijkstry: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf Który chciał wykazać języki programowania jako matematyczną prawdę i równania.

Nie udało mu się to, ze względu na niektóre goto - takie które skakały z obcych scope'ów do innych. Wykazał również, że jeśli usunie się te goto które dotykają zbyt dalekich scope'ów (czyli innych niż on sam, jego direct rodzic lub direct dziecko) wtedy da się wyrazić taki program jako działanie matematyczne (a więc np da się go wyrazić funkcyjnie). Stąd teza pracy - "goto considered harmful". I z tego co wiem to Dijkstra właśnie pierwszy raz użył określenia "structural programming", jako to bez goto.

Rozumiem że twórcy kompilatorów i optymalizatorów mogli zauważyć problemy z implementacją goto (i nawet podjąć decyzję o nie wspieraniu go), ale to chyba jeszcze nie oznacza że to oni wynaleźli programowanie strukturalne.

Martin9410 napisał(a):

Dzień dobry. Potrzebuję pomocy przy uporządkowaniu listy. Mianowicie, chce dane języki programowania dopasować do paradygmatów, w których znajdują zastosowanie .

Robienie takiej listy miałoby sens, gdybyś miał

• super głęboką wiedzę na temat paradygmatów. Wchodził głęboko i np. umiał rozróżnić różne podejścia do programowania obiektowego, różne oblicza programowania funkcyjnego
• znał historię informatyki na kilkadziesiąt lat wstecz
• miał szeroką wiedzę - znał choćby pobieżnie każdy z języków, który opisujesz.

Jakbyś miał taką wiedzę, to myślę, że wtedy spokojnie mógłbyś pisać książki o tym albo występować na konferencjach. Kurczę, to samo w sobie jest ciekawe, posłuchać np. jak się różni obiektówka w Smalltalk(historycznie, bo prawie nikt dzisiaj nie pisze już w Smalltalk. Ale dobry case do omówienia) kontra obiektówka z Javy kontra pisanie OOP w C czy innych językach teoretycznie nie wspierających OOP, jak można pisać obiektówkę w językach funkcyjnych. Czy dziedziczenie jest potrzebne czy kompozycja lepsza. Czy wzorce ECS, DDD, actor-model to odmiany OOP czy jednak inne paradygmaty.

Podobnie z funkcyjnym. Też inne będzie czyste programowanie funkcyjne typu Haskell, a inne będzie użycie funkcyjnego paradygmatu jako dodatku w języku imperatywnym, w projekcie, który funkcyjnie napisany nie jest itp.

Natomiast jeśli to ma być tylko takie uporządkowanie, bo tak, to w sumie nie ma to sensu. Większość mainstreamowych języków są to języki wieloparadygmatowe, które co najwyżej przechylają się ku jednemu paradygmatowi o tyle, że wspierają go mocniej. Więc do wyboru, do koloru. Ciekawsze jest, w jaki sposób języki się nawzajem inspirują (i jak po kolei kolejne języki dostają async/await czy pattern matching) niż sucha kategoryzacja.