[Scala] - Paradygmaty programowania

0

Zacząłem się ostatnio zastanawiać dlaczego "domyślnym" stylem programowania w Scali jest programowanie funkcyjne. Rozumiem że Scala wspiera takie rozwiązanie, domyślne kolekcje są niezmiennicze itp. Ale z drugiej strony Scala jest językiem wieloparadygmatowym wspierającym również programowanie obiektowe. Natomiast praktycznie gdzie nie spojrzę czy to do jakiś artykułów, książek czy kursów to prawie wszędzie mówione jest żeby pisać funkcyjnie bo inaczej to fe.
Dlaczego więc jeśli nie pisze się w Scali funkcyjnie (np: używa for, while zamiast rekurencji ogonowych, czy jakiś bardziej zaawansowanych technik) to dużo ludzi wpada w szał bo to źle ? Nie można pisać obiektowo czy w stylu mieszanym ?

PS. Tak, rozumiem że wiele bibliotek Scalowych jest opartych np: na niezmienniczości, jednak wg mnie programowanie funkcyjne jest po prostu kolejnym paradygmatem mającym swoje zalety i wady. Nie rozumiem czemu się wymusza ten styl jeśli można pisać w też w innych.

3

Myślę, że o czystej funkcyjności jest po prostu najgłośniej, to nośny temat. Scala powstała jako eksperyment mający dowieść, że OOP i FP da się skutecznie połączyć i dalej jest takim eksperymentem. Tymczasem sporo ludzi usilnie chce zrobić ze Scali Haskalatora i w efekcie przechodzą na Haskella. Jest tak bo twórcom Scali jak na razie bardziej pasuje by programiści skrajnego FP przechodzili na Haskella niż by przerabiać Scalę głównie pod ich potrzeby. Popatrz na Akkę, Lagoma, Playa etc To biblioteki czy frameworki od LIghtbenda czyli biznesu stojącego za Scalą. Nie są to biblioteki ekstremalnie funkcyjne.

0

Nie mam doświadczenia komercyjnego ze Scalą, więc trudno mi to wszystko oceniać. Głównym problemem jest dla mnie to że prawie wszędzie skąd czerpałem wiedzę forsowany jest styl funkcyjny jako domyślny z niewiadomych dla mnie przyczyn, bo tak jak wspominałem wg. mnie jak każdy paradygmat ma swoje zalety i wady gdzieś sprawdza się lepiej a gdzieś gorzej. Jeśli można napisać coś "dobrze" (cokolwiek miałoby to znaczyć) używając OOP lub OOP + fragmentów FP w czasie x, to nie widzę sensu żeby pisać to w FP w czasie 3x (chyba że dla własnej satysfakcji). W Scali jak dla mnie najwygodniej jest pisać OOP i stosować różne fajne rzeczy z FP (pamiętając oczywiście o konsekwencjach np: zmienniczości). Natomiast z tego co widzę takie podejście uważane jest za najgorszą zbrodnię godną szubienicy.

PS: Haskell to chyba w ogóle nie jest produkcyjny :d Choć kiedyś czytałem że podobno jakiś facebook wykorzystywał go w backendzie do analizy komentarzy czy coś takiego.

0

Hej,
tak ogólnie... Scala mi się podoba... Tak jak i programowanie funkcyjne... Ponieważ czasem jedną linijką można machnąć, to co np. w Javie wymaga dwudziestu... ale to nie znaczy, że jest lepsza... ale na pewno daje spore możliwości, jak niedoceniane trochę (i niszowe PF), w którym niektóre rzeczy można liczyć w locie... Poza tym w Scali są fajnie zrobione rzeczy bazodanowe (komendy SQL) w kontekście np. Sparka... chyba trochę lepiej niż w Javie, w którym chyba się konwertuje zwykłe bazodanowe zapytania, takie to ciut sztuczne... chyba, że czegoś nie wiem... w sumie nie wiem dokładnie jak Java sobie radzi ze Sparkiem.... jak macie jakieś fajne materiały, to podlinkujcie... poza tym, wydaje mi się, że trochę niedoceniana jest rekurencja, która jest bardzo ważna w PF... może kiedyś o tym więcej ciut... :) Natomiast z tego co widzę... to w IT jest dość spore zamieszanie technologiczne... myślę, że wynika to z tego, że każdy chce zarobić... a Ludzie walczą o zyski i strefy wpływów... stąd pewnie ta heca z próbą wyparcia Javy z Androida, i próbą wklejania tam, jakiegoś "genialnego" produktu... ;)

1

PS: Haskell to chyba w ogóle nie jest produkcyjny :d Choć kiedyś czytałem że podobno jakiś facebook wykorzystywał go w backendzie do analizy komentarzy czy coś takiego.

Ja słyszałem, że czat był oparty o Erlanga :P

Natomiast z tego co widzę takie podejście uważane jest za najgorszą zbrodnię godną szubienicy.

Nie u mnie w pracy. Blogaski swoje, życie swoje.

0

Dlaczego więc jeśli nie pisze się w Scali funkcyjnie (np: używa for, while zamiast rekurencji ogonowych, czy jakiś bardziej zaawansowanych technik) to dużo ludzi wpada w szał bo to źle ? Nie można pisać obiektowo czy w stylu mieszanym ?

Ciekawostka, implementacja whileTrue z Pharo

whileTrue
	"Ordinarily compiled in-line, and therefore not overridable.
	This is in case the message is sent to other than a literal block.
	Evaluate the receiver, as long as its value is true."
 
	self value ifTrue: [ self whileTrue ]

For-y/while w stylu c nie mają nic wspólnego z programowaniem obiektowym... Dodatkowo wykreśl lambdy z "fajnych rzeczy funkcyjnych".

0

Coś więcej o wykreślaniu lambd z "fajnych rzeczy funkcyjnych"?

Już smalltalk miał bloki. Jak dla mnie skoro można wysłać lambdzie wiadomości, to jest obiektowa. Bardziej kwestia kto pierwszy zaklepał ten termin...
Zresztą z tego co czytałem to smalltalk uformował lambdy dzisiejszych czasów.

Programming with collections using high-order functions rather than individual elements is an important way to raise the level of abstraction of a program. The Lisp function map, which applies an argument function to every element of a list and returns a new list containing the results is an early example of this style. Following its Smalltalk root, Pharo adopts this collection-based high-order programming as a central tenet. Modern functional programming languages such as ML and Haskell have followed Smalltalk's lead.

Ale ja tam młody jestem, nie znam tych czasów :)

1
Szalony Kot napisał(a):

Coś więcej o wykreślaniu lambd z "fajnych rzeczy funkcyjnych"?

Już smalltalk miał bloki. Jak dla mnie skoro można wysłać lambdzie wiadomości, to jest obiektowa. Bardziej kwestia kto pierwszy zaklepał ten termin...
Zresztą z tego co czytałem to smalltalk uformował lambdy dzisiejszych czasów.

Programming with collections using high-order functions rather than individual elements is an important way to raise the level of abstraction of a program. The Lisp function map, which applies an argument function to every element of a list and returns a new list containing the results is an early example of this style. Following its Smalltalk root, Pharo adopts this collection-based high-order programming as a central tenet. Modern functional programming languages such as ML and Haskell have followed Smalltalk's lead.

Ale ja tam młody jestem, nie znam tych czasów :)

Patrząc na historię to termin zaklepał Alonzo Church, a potem był wykorzystywany na przykład przez LISP'a, na długo przed Smalltakliem. To, że paradygmaty lubią odchodzić i przychodzić widać w historii i nie inaczej jest w tym przypadku. Nikt nie twierdzi, że Scala wynajduje nowoczesne techniki programowania nieznane wcześniej. Większość pojęć na które obecnie jest hype - funktory, monady czy monoidy zapewne były znane dużo wcześniej przed powstaniem języków funkcyjnych

2

Bardziej niż wymyślanie coraz to nowych rzeczy liczy się stworzenie takiej kombinacji cech, by w danym języku dało się efektywnie tworzyć określony rodzaj aplikacji. Scala z wersji na wersję dorzuca i wyrzuca trochę bajerów, tak by całkowity zestaw cech był jak najsensowniejszy.

Dotty ma być Scalą 3. Polecam zajrzeć w Reference -> Dropped Features na: http://dotty.epfl.ch/docs/index.html

0

Właśnie jakiś czas temu oglądałem konferencję Oderskiego. Powiem szczerze że nie wiedziałem co o tym myśleć, z jednej strony obiecują większą unifikację, uproszczenie itp. a z drugiej strony mam wrażenie że powrzucają tam jeszcze tyle rzeczy że poziom złożoności Scali wzrośnie.

PS - w ogóle odniosłem wrażenie dużo "scalowców" jest bezgranicznie oddanych Oderskiemu i na wszelkie próby krytyki pod ich adresem odpowiadają świętym oburzeniem.

0

Powiem szczerze że nie wiedziałem co o tym myśleć, z jednej strony obiecują większą unifikację, uproszczenie itp. a z drugiej strony mam wrażenie że powrzucają tam jeszcze tyle rzeczy że poziom złożoności Scali wzrośnie.

Niekoniecznie. Powinien nawet zmaleć. Weźmy na przykład type lambdas: http://dotty.epfl.ch/docs/reference/type-lambdas.html
W Dotty wyglądają spoko, a w Scali 2 trzeba robić koślawe i nieczytelne konstrukcje typu: https://underscore.io/blog/posts/2016/12/05/type-lambdas.html

1 użytkowników online, w tym zalogowanych: 0, gości: 1