Facebook
Misja Grupa 5000+ audycji Kino Czat Kryzys? Napisz Broń
Podpis:
Numer GG:
KonteStacja.com - radio ludzi wolnych Wspieraj KonteStację i dołącz do Kontest.CLUB
Dziś
20:00
Firma na emigracji
Jutro
21:00
Wydanie Główne
Słuchaj radia
Wydanie Główne (1)
5 dni temu
Autostopem na Kitaj
Naszym gościem jest Ludwik Papaj autor książki "Kierunek Kitaj". Odważna podróż przez Chiny, Rosję, Mongolię, Laos i Tajlandię. Minimalizowanie kosztów. Różnice kulturowe i...
Zrozumieć Nieruchomości
wczoraj
wywiad ze mną o kamienicach i nie tylko
wywiad ze mną przeprowadziła Marta Baczewska - Golik prowadząca podcast Ruszamy Nieruchomości
Skorzystaj z naszych projektów:

▸ Kontest.CLUB - wspieraj KonteStację
▸ Własna broń - zdobądź pozwolenie
▸ Wolny Rynek - w liczbach
▸ Emigrujesz - posłuchaj najpierw
▸ KontestKino - filmy na wieczór
▸ Poważny kryzys - napisz

Audycja: Epicentrum 2015-11-11

Ze względów bezpieczeństwa powinniśmy chodzić nago ☻

Nadający: Krzysztof Maczyński

Tak postuluje słuchacz. A ByteEater najpierw się bulwersuje na umowę TPP, po czym opowiada o językach programowania wyznaczających trend na za 15 lat, zwłaszcza Haskellu.

KOMENTARZE

nmk 2015-11-11

Jeden z linków, wspomnianych w audycji, odnośnie Haskella: 
https://github.com/Gabriel439/post-rfc/blob/master/sotu.md 
 
A tu coś dla tych, których interesuje gamedev + języki funkcyjne:  
https://michaelshaw.github.io/game_talk/game.html

Krzysztof z Bielska-Białej vel ByteEater 2015-11-11

A to praca naukowa (całkiem przystępnie napisana), o której wspomniałem, gdy nmk był na antenie, nie podając tytułu ani linku, jednak to właśnie opisane w niej podejście ze znanych mi obecnie uważam za najbardziej obiecujące w zakresie podniesienia Haskella, i ogólnie programowania funkcyjnego, z Immature do co najmniej Mature w kategorii „Standalone GUI applications”: oai.cwi.nl

Tomek Primke 2015-11-12

Na plus audycji można zaliczyć to, że wiesz, o czym mówisz. (Może nie ze wszystkim się zgadzam, ale fachowcem jesteś.) Słuchałem kiedyś audycji na Kontestacji, jakiegoś wywiadu z kimś, kto pisał w Javie. Po dwóch czy trzech wypowiedziach stwierdziłem, że koleś w życiu nie powinien być programistą, bo nie ma o tym pojęcia. W Twoim przypadku widać, że znasz się na temacie. 
 
ByteEater, polecasz tego Haskella, chwalisz go... A próbowałeś używać? Mógłbyś się pochwalić jakimiś aplikacjami? 
 
Pytam, bo ja próbowałem. A spróbowałem dlatego, że poczytałem o Haskellu. Wyczytałem mniej-więcej dokładnie to, co powiedziałeś w audycji (same cuda). A z praktyki mam wręcz przeciwne wrażenia niż te, o których opowiadasz. 
 
Zrobić w tydzień to, co konkurencja robi w dwa lata? Ja mam z Haskellem dokładnie na odwrót: to, co w Haskellu zajmuje mi dwa dni, w Eliksirze/Erlangu/JavaScript potrafię zrobić w dwie godziny. Haskell to język piękny, ciekawy i interesujący, ale produktywność w nim żadna. Dlatego Haskellowi zdecydowanie podziękuję. (I żeby była jasność: programuję głównie funkcyjnie; jestem przeciwnikiem programowania obiektowego.) 
 
Kompilator w Haskellu? Ogólnie wypowiadał się nie będę, natomiast wtrącę moje trzy grosze w dziedzinie transpilerów JavaScript. Pełno jest teraz tego (Babel, TypeScript, Elm, CoffeeScript, ...). W większości są one pisane albo w JavaScript, albo w samym transpilowanym języku. Jest też jeden transpiler pisany w Haskellu: PureScript. Efekt? Narzędzia w PureScript za cholerę nie integrują się z resztą ekosytemu Node.js tak, jak pozostałe transpilery. Co z tego, że PureScript (wzorowany na Haskellu) jest znacznie piękniejszy od Elm-a (też funkcyjnego), skoro to właśnie Elm-a znacznie prościej się używa? 
 
Aplikacje webowe? Dokładnie ta sama uwaga. Używając Eliksira, Pythona czy JavaScript jestem znacznie bardziej wydajny, niż w Haskellu. Właśnie dlatego, że Eliksir, Python i JavaScript są językami typowanymi dynamicznie, gorliwymi (przeciwieństwo lazy evaluation) i można w nich pisać funkcje z efektami ubocznymi bez znajomości monad. (A piszę to jako zwolennik typowania statycznego!) 
 
A swoją drogą, to przestań opowiadać farmazony, że w innych językach można przez przypadek odpalić głowice atomowe, a w Haskellu nie. Używałem Haskella przez rok i wiem, że w Haskellu też można popełniać błędy. Jak zresztą w każdym języku. (Tak przy okazji, ByteEater - kiedy to ostatnio Twój program napisany nie-w-Haskellu przez przypadek odpalił głowice atomowe? Bo mnie nigdy się to nie przydarzyło. Podobnie nigdy mi się nie przydarzyło przez przypadek skasować wszystkie dane. Więc argument też, jak dla mnie, chybiony.) 
 
Bliższy prawdy jesteś mówiąc, że w Haskellu można opracować bezpieczny system typów. To prawda. Tylko że zanim to zrobisz w Haskellu, to ja już trzy razy zdążę napisać gotową i działającą aplikację w innym języku. (Takie są moje doświadczenia z Haskellem - choć przyznaję, że ubogie w porównaniu do Pythona czy JavaScript.) 
Poza tym, każdy programista wie (POWINIEN wiedzieć), że specyfikacja oprogramowania często się zmienia. A to znaczy, że projekt typów sprzed, powiedzmy, roku, nie musi być odpowiedni do specyfikacji potrzebnej dzisiaj. Czyli cały misternie przemyślany system typów w Haskellu może powędrować do kosza. 
 
Na koniec napiszę tak: uwielbiam Haskella. To piękny język. Widać, że jest dobrze przemyślany. Gorąco polecałbym naukę Haskella każdemu, kto chciałby się czegoś nowego nauczyć o programowaniu. (A już obowiązkowo dla chcących poznać programowanie CZYSTO funkcyjne.) Jeśli audycja ByteEatera zachęci kogoś do nauki - to super. Spróbujcie. Napiszcie proste programy. Wyróbcie sobie własne zdanie. ByteEater przez 1.5h słodził nt. Haskella, to ja postanowiłem trochę ponarzekać. Tyle w temacie.

Faraday007 2015-11-13

@ByteEater 
 
Będąc całkiem zielony i nie rozumiejąc połowy z tego co mówiłeś zacząłem się zastanawiać jakimi zdolnościami matematycznymi powinien wykazywać programista? Czy te zdolności muszą byś rzeczywiście większe w przypadku programowania w Haskellu?

Krzysztof z Bielska-Białej vel ByteEater 2015-11-14

O, fajnie, że są pytania, i jest polemika! Tomek, Faraday, szerzej Wam w takim razie odpowiem w następnym odcinku, w którym planuję dopowiedzieć też o Elixirze i Scali. 
 
Ale teraz tak na szybko dla Was, i dla wszystkich chętnych, przede wszystkim czytających, którzy z jakiegoś powodu nie posłuchają, bądź zrobią to później: 
 
• Nie mówiłem, że Haskella należy się nauczyć jako jedynego języka i stosować w każdej niszy, wręcz przeciwnie. Miałem zamiar zareklamować 3 języki bardziej jako reprezentację pewnego trendu, który ma decydujący – tak przewiduję – wpływ na kierunek obecnego skrętu mainstreamu. Źródło inspiracji, poszerzenie horyzontów, przygotowanie na to, jak będą wyglądać wiodące języki i metody programowania (nawet jeżeli sam Haskell nie będzie wśród nich) za ileś lat. Także te obecnie mainstreamowe się do nich zbliżą jeszcze bardziej, bo już to robią. 
 
• Oczywiście Haskell nie jest tak popularną platformą, w sensie narzędzi, bibliotek integrujących go z czymkolwiek itd., żeby dorównywał JavaScriptowi z jego Node'em i silnikami w przeglądarkach, Pythonowi instalowanemu domyślnie w wielu dystrybucjach Linuksa, a tym bardziej Javie i .NET-owi. Ale nie jest też już akademicką zabawką, ma wiele bibliotek, wiodący kompilator (GHC) obrośnięty pakietem typu batteries included, są przyzwoite IDE i inne narzędzia. Więc gdy chodzi o stosowanie w praktyce, to oczywiście nie bierzcie Haskella w ciemno, tylko sprawdźcie, czy będzie się dało wygodnie w danym zastosowaniu z nim pracować, i to nie tyle z samym językiem, co właśnie pod kątem reszty ekosystemu. Ale to nie żaden minus języka, prawie każdy tak miał (no, Java, C#, Visual Basic i Objective-C (fuj!) nie, bo wprowadzały je gigantyczne korporacje w istniejących i już popularnych produktach). 
 
• Co do szybkiego prześcigania długotrwałego wysiłku konkurencji, to akurat było z wykorzystaniem LISP-a, innego języka funkcyjnego, omawiałem kiedyś już ten przykład dokładniej w audycji. Pisze o tym znany matematyk i informatyk Paul Graham: www.paulgraham.com 
 
• O głowicach to nie farmazon, tylko oczywisty chwyt retoryczny, dobitny przykład, mający działać na wyobraźnię, żeby łatwiej dotrzeć z przekazem, że to jest ważne. Sam np. dla Nokii pisałem przykładowy kod do dołączenia do SDK platformy Ovi, który się pytał (miał demonstrować wywołanie zapytujące się użytkownika o potwierdzenie, i standardowy styl takiego okienka), czy na pewno chcesz launch missiles. To jest wręcz topos w tej branży, jak exegi monumentum w poezji. A programistę, który jakiś czas temu niechcący usunął wszystkie dane, choć nie jestem nim ja, to znam, i to w Kontestacji; na szczęście zrobił to gdzie indziej (z oczywistych względów pominę identyfikację i inne szczegóły). 
 
• Czy i w jakim stopniu silny i statyczny system typów jest krępujący przy zmieniającej się specyfikacji? Czy dynamiczne i słabsze typowanie ma zalety, a jeśli tak, to przy stosowaniu w jakich niszach, które nie byłyby, przynajmniej w długim terminie, przerośnięte przez wady? (Ja uważam, że owszem, ma, w pewnych niszach.) Czy istotną zaletą systemów typów nawet w obliczu zmiennej specyfikacji jest trzymanie pewnej dyscypliny myślowej i w ryzach procesu arbitralnych zmian, co powstrzymuje nas (i klienta, jeśli jest zewnętrzny i bezpośrednio decyzyjny) od tworzenia ameb z featuritis i niespójnego bloatware'u (czego mogą nawet wszyscy żałować już w trakcie implementacji, ale być nieskłonni zmienić podejście, skoro już się wydało pieniądze i pracę na pójście daną drogą)? Czy może najlepszą (tak ja uważam) kombinacją jest programowanie w wielu językach, i pozostawienie słabo typowanego interfejsu skryptowego, podczas gdy zrąb aplikacji, a przynajmniej logika, są napisane w sposób zdatny do statycznej analizy i tym sposobem weryfikacji pożądanych własności (np. bezpieczeństwa), czyli prawdopodobnie w Haskellu lub języku inspirowanym Haskellem? To są głębokie pytania, i myślę, że nieco je sformułowaniami takimi, jak że plotę farmazony, zbyt lekko zbywasz. Warto byłoby porozmawiać i wspólnie te zagadnienia rozważyć. 
 
• Zauważ, że leniwe obliczanie jest coraz częściej obecne, czy to w formie bibliotek, czy nowych cech samego języka, także w JavaScripcie, Pythonie. Javie, .NET, C++, a nawet PHP. Owszem, to też głęboki temat, i naukowcy się zastanawiają i wiele prac piszą (a także eksperymentalnych języków tworzą, głównie zresztą jako rozszerzenia Haskella, który już zajął w tej roli dominującą pozycję) jak zgrabnie dać programiście możliwość łączenia najlepszych do zastosowania w danym problemie kawałków jednego i drugiego. 
 
• Żeby mieć produktywność zespołu programistów w Haskellu, musisz najpierw taki zespół mieć. Szacuję, że ich liczba jest dwucyfrowa na świecie (to i tak zdecydowanie więcej niż dla języków akademickich, takich tylko dla teoretyków), a w Polsce na razie 0. Dlatego jeżeli chcesz coś robić w Haskellu, to zdecydowanie radzę zacząć od jakiejś niezbyt wielkiej rzeczy, do ogarnięcia przez 1 człowieka. 
 
• Kto i w którym odcinku był gościem jako niekompetentny programista w Javie? Było to może u Kamila C.? Ja zwykle w takich sytuacjach wrzucam ten link: www.joelonsoftware.com 
 
• Faraday, myślę, że z tą połową to przesadzasz, tak retorycznie. ;-P Tylko w paru momentach była wyższa matematyka, i starałem się też od razu dopowiedzieć coś dającego intuicję (np. o tych monadach). Czy da się programować w Haskellu bez uprzedniej głębszej znajomości matematyki niż w przypadku innych języków? Da się. Nawet czytałem fajny tutorial, który zaczyna nie od prostych wartości, typów, funkcji, curryfikacji, rekurencji i funkcji wyższego rzędu, jak większość, tylko od monady IO, bez stojącej za nią teorii, i od prostych programików z konsolowym wejściem i wyjściem, np. "Hello, World!". Ale to jest tak, że im dalej w las, tym więcej matematyki, której rozumienie pozwala dobrze wykorzystywać elementy Haskella. Przy czym można się tego uczyć równolegle, co zresztą polecam (i nauczam, za pieniądze), m.in. dlatego, że przełożenie na programowanie daje tej nauce matematyki motywację. No i jest to w znacznej mierze matematyka dość odmienna od tej w szkole, czy nawet na większości studiów inżynierskich, według mnie ciekawsza.

nmk 2015-11-17

Ogólnie nie padły chyba stwierdzenia takie jak immutability oraz rekurencja ogonowa. A to są, moim zdaniem, dosyć mocne punkty języków funkcyjnych. 
 
Temat trudności programowania w językach funkcyjnych jest według mnie taki sam jak z innej beczki - sorry, znowu trochę gamedev: 
 
w szkołach, książkach i internetach najczęśćiej uczy się robić obiektowo. Niestety jest to często mniej wydajne - tam gdzie naprawdę potrzeba - głównie z powodu `vtable`. Dlatego z czasem powrócono do pisania gier albo chociażby raytracerów w sposób zorientowany na dane. Tzn. atrybuty zaczęto wkładać do osobnych tablic, np. zamiast robić klasę `Entity { Vector2 position, Vector2 size, Vector3 speed }`, to powstają trzy tablice `float[] positions`, `float[] sizes`. Bo tak jest szybciej. No ale wiadomo - architektura to, no, wątpliwa, chociaż pojawiło się potem coś takiego jak Data-Driven Design czy podobne terminy. Potem wykluło się coś znacznie piękniejszego, czyli Entity Component Systems - tu klasyczny link: t 
 
Teraz będę dążył do analogi nauki Haskella przez Tomka Primke. Podejście ECS w stosunku do OOP jest zgoła inne. W zasadzie to bardzo inne. Nie skupiamy się już na obiektach, a aspektach, czyli zestawach komponentów, pod które piszemy obsługujące je Systemy. Mniejsza o architekturę, tematem interesuję się już od ponad dwóch lat, właściwie bawiąc się tym, kodząc różne rzeczy po godzinach właśnie w ten sposób. Początek wyglądał świetnie! Robię MovementSystem, który operuje na tych encjach (Entity), które mają komponenty Position i Velocity. Ale po paru klasach tego typu człowiek miał pełno wątpliwości - co z hierarchią encji, coś z warstwami renderowania, co z dwukierunkowymi relacjami między encjami, np. przy kolizjach, co z inputem, co z eventami itd. No to sobie rozwiązywałem te problemy jeden po drugim. Przyznam się, że przez rok takiej zabawy po godzinach mindset ciągle przestawiałem. Tzn. trudno było z tą architekturą pracować, ale zdaję sobie sprawę, że z powodu OOP. I jak człowiekowi po miesiącu wydawało się, że już obiektowość go nie trapi, to i tak przez następne 11 miesięcy nie jest jak ryba w wodzie. 
 
Odnośnie funkcjyjnych to ja programowałem w OCamlu na studiach przez cały semestr i tak mi się spodobało, że zacząłem zgłębiać inne możliwości - Erlang, który był na serwerach w jednej pracy, no i Scala, z której zrobiłem certyfikat zorganizowany na Coursera.org przez twórcę Scali - Martina Odersky'iego. Szczerze, to ten certyfikat ledwie liznął niektóre tematy, a niektóre pozostawił samym sobie. Monady niestety też. W każdym razie Scalę mogę polecić szczególnie niezdecydowanym - jest funkcyjność, obiektowość i mutacyjność danych (mutability) nie jest jakoś szczególnie utrudniona jak np. w OCaml. 
 
Natomiast na studiach poznałem jeszcze inny język - mozart.github.io Wielu się nie podobało, bo "niepraktyczne" itd. ale deklaratywność dla komunikacji międzyprocesowej tutaj zaprezentowana była miodna (o ile pamiętam). W zasadzie kojarzy mi się z tematem modnym swego czasu - czyli FRP (Functional Reactive Programming) właśnie. Przy czym, to FRP to dużo bardziej coś w rodzaju "approach" niż "language syntax", "algorithm" albo "design pattern". A u podstaw FRP, wydaje mi się, leży deklaratywność, czyli możliwość opisania tego co się chce uzyskać - zamiast tego jak to uzyskać. Deklaratywność to jest moc i moim zdaniem powinniśmy do niej dążyć w wielu ogólnie pojętych systemach (chociażby przez data binding), zwłaszcza w których użytkownik ma bezpośredni wpływ na stan aplikacji, gdzie wtedy deklaratywność upraszcza auto-wnioskowanie stanu na podstawie inputu. Niestety w praktyce wydaje się to trudne, bo za bardzo wysokopoziomowe. Komputery jednak działają sekwencyjnie :( 
 
Odnośnie wspomnianego wielokrotnie leniwego obliczania, to skojarzył mi się też CQRS (bardziej approach niż design pattern - devtalk.pl gdzie taka deklaratywność, pod której sukienką kryje się leniwe obliczanie, data binding i takie tam, to właśnie najczytelniejszy sposób zaprogramowania takich optymalizacji jak w CQRS. A pragnę zauważyć, że optymalizacje to jedna z gorszych rzeczy psujących utrzymywalność kodu, czyli mówiąc wprost - jego czytelność. 
 
I jeszcze ostatni temat - matematyka w językach funkcyjnych. Ja bym nie "reklamował" tego w ten sposób, bo większość ludzi nie myśli tutaj o rachunku lambda / składaniu funkcji czy regułach Liskova, tylko raczej o wykresach i wzorze na deltę przy funkcji kwadratowej albo o pochodnych i całkach :D - jeżeli mieli z tym ostatnim do czynienia. A to trochę nie tak.

Dodaj komentarz...

Krzysztof Maczyński

Krzysztof Maczyński vel ByteEater z Bielska-Białej – interdyscyplinarny freelancer, z wykształcenia informatyk, zarabia na życie w większości programowaniem i prowadzeniem szkoleń, a w mniejszości, jak chcecie wiedzieć, to się zapytajcie .

Oddolny aktywista i lider regionalnych wolnościowców, dziennikarz KonteStacji, prowadzi audycje Epicentrum oraz Proste zwierciadło, członek Stowarzyszenia Libertariańskiego.

Sam do siebie odnosi takie m.in. paradoksalne określenia, jak biblijny katolik, geek lubiący poznawać ludzi, buntowniczy tradycjonalista, logiczny marzyciel i anarchokapitalista.



Epicentrum to audycja popularnonaukowa, często o informatyce, ale nie tylko. Często z gośćmi. Porusza zagadnienia dotyczące technologii, nauki, edukacji, karier, posiadania pasji i jej miejsca w życiu, a także uzyskiwania dzięki niej pieniędzy, jeśli się da. Dla ludzi o szeroko pojętych zainteresowaniach w jakiś sposób związanych z tymi tematami.

Konto bitcoin autora, na które możecie go docenić dowolnymi wpłatami: 1Kkjzpc2NZVeJLKPPwGFBb4H1geLEqMwj1.

Inne audycje tego autora:



Hakerskie opowieści - 8 tygodni temu

Droga do bankructwa (2) - 3 miesiące temu

Na metadane nie miej wyjebane (2) - 6 miesięcy temu

DevOps: oswajanie Dockera - 8 miesięcy temu

Co pokona Bitcoina? (1) - 8 miesięcy temu

Więcej audycji...

Nowe technologie XXI wieku (7) - 9 miesięcy temu

Nie słuchaj, bo utyjesz! (4) - 10 miesięcy temu


Ile tak naprawdę nóg ma stonoga? (3) - 11 miesięcy temu

Naga półprawda (3) - 11 miesięcy temu

Ceny minimalne w świecie kryptowalut? (3) - 11 miesięcy temu


Czy szczepionki wywołują autyzm? (12) - ponad rok temu







Odcinek wielobarwny (4) - ponad rok temu

Cyberzbóje i cyberrycerze (7) - ponad rok temu



Czym otruć prezydenta? (4) - ponad rok temu


Kryptowalutowy Dziki Zachód (4) - ponad rok temu

Jak oni programują (11) - ponad rok temu

Lightning Network – Bitcoin 2.0? (2) - ponad rok temu

Czy koty są okrutne? (6) - ponad rok temu



Darmowa energia, tania energia… (10) - ponad rok temu


Lecą drony z każdej strony! (2) - ponad rok temu






Zawrotne prędkości (2) - 2 lata temu









Po co nam science fiction? (1) - 3 lata temu

Interview with Lyn Ulbricht (1) - 3 lata temu



Szachy kontra go (10) - 3 lata temu



Zagadkowy odcinek (4) - 3 lata temu






Co to jest biohacking? (8) - 3 lata temu




Innowacje w motoryzacji (2) - 3 lata temu









Epicentrum wolności (4) - 4 lata temu

Śmierć Windows XP (7) - 4 lata temu


ARM vs x86 (5) - 5 lata temu


Podsumowanie roku 2013 (7) - 5 lata temu

Gry niezależne (indie games) (13) - 5 lata temu







Bitcoin - wirtualna waluta (25) - 5 lata temu




FBI zamknęło Silk Road (4) - 5 lata temu

Linóx to ZUO? (4) - 5 lata temu

Gość elektronik: LordBlick (9) - 5 lat temu



Magia gier (2) - 5 lat temu

Mobilny 1010fingers (1) - 5 lat temu



Wywiad z Robertem Partyką (2) - 6 lat temu

Hackerspace odyssey (5) - 6 lat temu

Geeky Afterparty 2012 (3) - 6 lat temu



Jak nagrywać własne podcasty (14) - 6 lat temu


Urządzenia ponadczasowe (3) - 6 lat temu


Polski tablet czy UMPC? (11) - 6 lat temu



UMPC (1) - 6 lat temu

Co z tą innowacyjnością? (3) - 6 lat temu

Wozniak, kafelki i rowery (15) - 6 lat temu

Geek Drags o tabletach (5) - 6 lat temu



Rozszerzona rzeczywistość (3) - 6 lat temu

Wehikuł czasu nerdów (2) - 6 lat temu








Własne media center - 7 lat temu






Zaoranie HTML5 (4) - 7 lat temu


Wszystko o XML-u (4) - 7 lat temu


Google kupił Motorolę! (3) - 7 lat temu

IRC - technologia do lamusa? (4) - 7 lat temu


Geek cloud: ARM i x86 (9) - 7 lat temu

























Mobilny HydePark (1) - 8 lat temu




UMPC i tablety (8) - 8 lat temu




Notebook czy Netbook? (1) - 8 lat temu

Linux w kieszeni (4) - 8 lat temu



Audycja Mobilnych - 8 lat temu

Audycja Mobilnych - 8 lat temu

Audycja Mobilnych - 8 lat temu

Audycja Mobilnych - 8 lat temu



A dzisiaj polecamy:
 align="center">
Program sponsorują:

nexty - - 10.00
Koczkodan - - 20.00
Piotrek - - 25.00
Pigularz - - 30.00
Ćwok - a teraz do roboty - - 50.00
Wudz po raz n - - 50.00
Grzech - - 40.00

Możesz i ty zasponsorować >>>

Promuj radioWydrukujDaj komuś ulotkęChcesz prowadzić audycję?Kontakt