Swift to szybki, bystry czy chyży. Słowo to oznacza również sympatycznego ptaka jeżyka. Jest też samochód firmy Suzuki o tej nazwie i chyba do niego najbardziej podobny jest ten język. Taki trochę ciasny, mały i średnio dopracowany.

Ale o co chodzi?

Po pierwszych zachwytach podejściem tego języka do różnych problemów (functions are first class, pattern matching), doszedłem do momentu w którym przestałem go po prostu lubić. Początkowy zachwyt spowodowany był fajnymi kawałkami kodu który widziałem oraz wypowiedziami osób szeroko znanych (między innymi w Dot Net Rocks) jaki to wspaniały twór. I może mówię to lekko przedwcześnie (w końcu nic poważnego w nim jeszcze nie zakodowałem), ale już po wstępnym przeanalizowaniu jego podstaw widzę się źle.

Więc co mi się podoba?

Swift posiada operatory, typy i kolekcje podobne jak w każdym innym obiektowym języku programowania. Podobnie struktury i klasy nie są tu niczym nowym i odkrywczym. To co jest ciekawe (dla mnie programisty głównie C#) to szeroko wykorzystane Tuple do zwracania wyników funkcji. Oczywiście w C# też da się to zrobić ale tu jest to ogarnięte o wiele lepiej wraz z nazywaniem elementów w obiekcie Tupla itd. Podobnie zwracamy wyniki w Go 🙂

Podobnie jak w F# i innych językach programowania bardziej funkcyjnych jest możliwość nie zwrócenia wartości przy czym tu realizowane jest to za pomocą Enuma. Obiekt tegoż Enuma może przyjąć główną wartość (w tym przypadku np. None i Some) oraz dodatkową prawdziwą wartość (coś jak typy nullable w C# czyli np. int?). Czyli sprawdzenie czy istnieje jakaś wartość wyglądałoby tak:

Prawdopodobnie C# ma iść tą samą drogą i jak najbardziej jestem… Przeciw! Niech zrobią to jak w F# – tam jest o wiele lepiej.

Jest również możliwość zwrócenia wartości nil (tu Uncle Bob zaczyna rwać sobie włosy z głowy). W takim wypadku można zastosować sprytną konstrukcję:

Lambdy, które tu nazywają się Closures. I tu akurat nie mam uwag działa to fajnie:

No i są extension classes. Umożliwiają rozwinięcie klasy nie tylko o metody, ale również o implementację interfejsu.

I na tym miłe rzeczy się kończą i zaczynają niemiłe.

 

Co mi się nie podoba?

Dlaczego poszli “własną” drogą nazewnictwa? U nich wszystko nazywa się inaczej tak jakby sami to wymyślili. Przykład? Interface to w Swift Protocol… Dlaczego tak? Field/Member to stored property, a property to computed property. Nie chcę pytać co tam oni jeszcze wymyślili.

Funkcje mają parametry nazwane wewnętrznie i zewnętrznie. Nawet nie pytam gdzie ścisłość i zwięzłość programowania funkcyjnego:

Za to fajne są range w parametrach funkcji:

Ale to wszystko (a jest tego więcej, ale zostawię takie wesołe smaczki do kolejnych wpisów) nic w porównaniu do zarządzania pamięcią. Nowoczesny język, niedawno stworzony, niby pięknie działający… Super! Aż dowiadujemy się, że zarządzanie pamięcią polega na “reference counting“. WTF?! Dlaczego po 2010 pojawił się język programowania, który cofa nas do epoki kamienia łupanego? Ja rozumiem, że ten system jest prostszy, że Apple ściemnia, że Garbage Collector jest za wolny… Przypuszczam, że prawdziwy powód to koszty przepisania tysięcy bibliotek wiszących na Objective-C. W każdym razie, jako programista Delphi jeszcze w wersji 7 pamiętam te piękne czasy wycieków pamięci spowodowane zmienną nie przypisywaną do null’a po użyciu. To wszystko w 2016 to taki model zarządzania pamięcią w wersji vintage. Swoją drogą -> Closure czy Funkcja w rozumieniu tego języka jest First Class, ale oznacza to nic innego jak potraktowanie jej jako obiektu. A co to oznacza w poniższym kodzie?

Z mieszanymi uczuciami czas zrobić kolejny krok w tej przygodzie. Jak Wam się podoba ten kontrowersyjny już teraz język?

 

 

4 Replies to “Pierwszy rzut oka na Swift -> WTF!

  1. Pingback: dotnetomaniak.pl
  2. Swift jest dla ludzie którzy przesiadają się z Objective-C, a tam są właśnie “protocols” i “property”.
    A co do “reference counting” nie przejmowałbym się za bardzo. Są już miliony linii kodu napisane w Swift które działają na setkach milionów iOS’ów i nie crashują. RUST na przykład też nie ma GC. A napisali w nim cały nowy engine przeglądarek (servo).

    1. Wiesz robili to od nowa, to mogli zachęcić więcej ludzi niż tylko swoich starych klientów 🙂
      Co do reference counting -> nie chodzi o crashowanie, chodzi o to, że muszę teraz o tym pamiętać.
      a GoLang ma GC i sobie chwalę go bardziej niż Rust 🙂

  3. Jeżeli jest to reference counting, to żeby zrobić wyciek, trzeba we wskazaniach obiektów zrobić cykl.
    Będę śledził, bo zastanawiam się nad nauką swifta

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *