Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Dlaczego warto programować w Scali

Poza najpopularniejszym językiem platformy JVM istnieje wiele różnorodnych języków programowania, które potrafią w pełni wykorzystać możliwości tej maszyny wirtualnej i korzystać z bibliotek i narzędzi napisanych dla niej. Sama Java jest językiem dość starym i ciąży na nim konieczność utrzymywania przy każdej nowej wersji kompatybilności wstecznej, w taki sposób aby kod źródłowy programów napisanych dla wcześniejszych wersji JVM działał w nowszych wersjach. Choć Java ostatnio szybko się rozwija i w wersji ósmej pojawiają się w niej nowe konstrukcje w tym elementy programowania funkcyjnego, anonimowe funkcje, domknięcia itp., to niestety pozostały w niej niedoskonałości, które dzisiaj trudno jest z niego usunąć. Do takich można by zaliczyć fakt, że typy prymitywne Javy nie dziedziczą od klasy Object. Ma to swoje zalety, jednak bardzo utrudnia programowanie uogólnione. Jeżeli porównamy kod napisany w języku Java i kod napisany w niektórych innych językach dla JVM realizujący podobne zadanie to zauważymy, że najczęściej kod tych ostatnich jest krótszy, a tym samym zazwyczaj łatwiejszy do przeczytania i zrozumienia. Dotyczy to głównie języków typowanych dynamicznie takich jak Groovy, Jython czy JRuby, ale jest też przynajmniej jeden język typowany statycznie, dla którego to stwierdzenie jest również prawdziwe. Tym językiem jest Scala.

Java a sprawa Oracle vs Google

Innym poruszanym ostatnio problemem przez programistów Java jest sprawa pozwu Oracle przeciwko wykorzystaniu API Javy przez Google. Trudno zrozumieć tutaj niuanse prawne i przewidzieć jakie problemy mogą mieć inne projekty, które używają języka Java. Niektórzy uważają, że rozwiązaniem jest niekorzystanie z języka Java, a wykorzystanie jakiegoś innego języka pracującego na JVM.

Scala

Nazwa Scala bierze się od słowa skalowalna, co według twórcy tego języka Martina Odersky'ego ma oznaczać, że język może być dostosowany do potrzeb użytkownika. W Scali można realizować bardzo różnorodne zadania, począwszy od prostych skryptów wywoływanych podobnie do skryptów Pythona, aż do wielkich systemów informatycznych.
Technicznie rzecz ujmując, Scala jest językiem zorientowanym obiektowo i równocześnie funkcyjnie, ale typowanym statycznie. Dodatkowo, kompilator potrafi odgadywać w wielu sytuacjach samodzielnie typ obiektu, co umożliwia pisanie kodu wyglądającego jak w języku typowanym dynamicznie. Obiektowy paradygmat programowania pozwala wykorzystywać metodologie tworzenia oprogramowania, podobne do wykorzystywanych w innych językach, takich jak Java z użyciem UML itp. Natomiast elementy funkcyjne języka umożliwiają wysoką zwartość kodu, ale również bezpieczeństwo przetwarzanych danych, w szczególności przy programach wielowątkowych. Opiera się to na przekazywaniu między wątkami niezmiennych wartości. Po wyliczeniu nowej wartości stara zostaje odrzucona, natomiast powstaje nowa, którą przekazuje się dalej. (Działa to podobnie do klasy String w Javie, gdzie stringi są niemutowalne, a wszelkie operacje powodują powstanie nowego łańcucha znaków).
Język ten ma dodatkowo taką zaletę, że styl funkcyjny, do którego nie jest przyzwyczajona większość programistów, nie jest obligatoryjny. Można pisać kod zbliżony do tego jaki pisało się w innym języku używając typowych pętli, a gdy będziemy gotowi, przejść do stylu programowania odpowiadającego programowaniu funkcyjnemu.

Kompatybilność z Javą

Każdy kod napisany w Javie może być wykorzystany w języku Scala. Nie ma konieczności przepisywania bibliotek. Możemy z dnia na dzień zmienić język na Scalę i cały nasz dotychczasowy kod wykorzystywać dalej. Co prawda część bibliotek zastępuje te z Javy, ale często opiera się na tych standardowych. Przykładowo scala.String posiada wszystkie te same metody co java.lang.String i jest zasadniczo rozszerzeniem tej ostatniej. Rozszerzenia te ułatwiają użycie stringów na przykład dostarczając metod typu toInt, toFloat itp. (wymienione metody pozwalają łatwo konwertować napisy na liczby). Również sam kod napisany w Scali może być wywoływany w kodzie Javy, ale wymaga to już uwagi ze strony programisty i nie używania elementów typowych tylko dla Scali, jak chociażby przeładowanie operatorów.

Zwięzłość

To chyba najważniejsza zaleta Scali. Jeśli czytamy kod, to jedną z ważniejszych jego cech pozwalających łatwiej go zrozumieć jest jego zwięzłość, w tym ilość linijek, które trzeba przeczytać, aby zrozumieć jakąś bardziej złożoną operację. I w tym Scala wychodzi wyśmienicie. (podobnie jak wiele języków dynamicznych)

Przykładowy kod w Javie: class MyClass { private int index; private String name; public MyClass(int index, String name) { this.index = index; this.name = name; } } możemy zastąpić w Scali znacznie krótszym:class MyClass(index: Int, name: String)Wiele pomaga odgadywanie typów przez kompilator oraz korzystanie z przetwarzania funkcyjnego kolekcji co wydatnie skraca kod (zamiast używania pętli).

Scala jako język wysokiego poziomu

Walcząc ze złożonością kodu warto przechodzić na wyższy poziom abstrakcji, przerzucając niektóre zadania na gotowe konstrukcje. Scala posiada wiele takich konstrukcji pozwalających zajmować się bardziej dodawaniem naszej logiki do kodu niż odkrywaniem na nowo jak przetworzyć np. String na liczbę.
Przykładowy kod sprawdzający czy napis posiada co najmniej jedną wielką literę: boolean nameHasUpperCase = false; for (int i = 0; i < name.length(); ++i) { if (Character.isUpperCase(name.charAt(i))) { nameHasUpperCase = true; break; } } możemy napisać dużo krócej: val nameHasUpperCase = name.exists(_.isUpperCase)To następny powód dla którego pisanie i czytanie kodu jest łatwiejsze i szybsze.

Statyczne typowanie

Zalet statycznego typowania nie można przecenić. Do zalet w stosunku do języków typowanych dynamiczne możemy zaliczyć:
  • mniejsza ilość testów
  • mniejsza szansa na błędy w run-time
  • bezpieczniejszy refaktoring
  • prostsze tworzenie i czytanie dokumentacji
Zazwyczaj musimy wybierać między ekspresywnością języka, a jego bezpieczeństwem, które daje nam kompilator. W przypadku Scali mamy jedno i drugie. To jakby zjeść ciastko i mieć je dalej.

Wykorzystanie w projektach

Scala nie jest tak popularna jak większość mainstreamowych języków programowania. Jednak nie jest to język egzotyczny. W indeksie serwisu Tiobe zajmuje 40 miejsce. To lepiej niż Erlang czy D. Jego popularność ciągle rośnie, a kołem zamachowym są wielkie firmy, które wprowadzają go do swoich narzędzi i pomagają rozwijając nowe narzędzia i biblioteki dla tego języka. Najbardziej znane zastosowania Scali to: Twitter - duża część serwisu została przepisana na Scalę, bardzo znany startup Foresquare pisze prawie wyłącznie w Scali, Sgrouples - startup mający walczyć z Facebookiem. W Scali piszą takie firmy jak HP, IBM, The Guardian, LinkedIn.
Na polskim rynku jest sporo firm, które piszą w Scali. Wiele firm używa tego języka jako dodatkowego, ale są też takie gdzie jest on głównym. Czasem jednym z powodów pisania projektu w Scali jest fakt, że dobrzy programiści lubią poznawać nowe technologie i jest to sposób na przyciągnięcie uzdolnionych ludzi do projektu. Na szczęście nie obywa się to kosztem jakości pracy, a wręcz przeciwnie ludzie mający już jakiś kontakt z JVM i programowaniem funkcyjnym bardzo szybko stają się bardziej produktywni w pracy.

Podsumowanie

Warto rozważyć użycie Scali w nowych projektach, jak również zastanowić się nad dodawaniem nowych modułów dla programów napisanych dla JVM właśnie w Scali. W dłuższej perspektywie obniży to koszty utrzymania projektu.
Minusem Scali jest jej złożoność. Język ten jest trudniejszy do opanowania niż Java. Programując nawet krótko w Scali można zauważyć, że pisanie programów w Scali można podzielić na dwa tryby: pisanie logiki aplikacji z wykorzystaniem gotowych bibliotek i tworzenie własnych bibliotek i modułów do wielokrotnego użytku. Ten pierwszy tryb jest bardzo łatwy i nie wymaga zbyt dużych umiejętności programisty, ani też znajomości zaawansowanych elementów języka. Natomiast ten drugi jest dość trudny i wymaga sporej wiedzy. W zamian napisany kod jest łatwiejszy w utrzymaniu i użyciu co jest opłacalne na dłużą metę.

Inną zaletą jest możliwość pisania skryptów w Scali, podobnie jak to się pisze w językach takich jak Python czy Ruby. Jedyna niedogodność to fakt, że ze względu na konieczność zadziałania za każdym razem kompilatora, samo uruchomienie skryptu trwa sporo dłużej niż przykładowo skryptu Pythona. Za to jeśli nasz skrypt wykonuje jakieś większe obliczenia to wykorzysta znacznie większą szybkość działania Scali w porównaniu do typowych języków skryptowych.

Ten przydługi wpis jest wstępem do krótkiego kursu Scali (w oparciu o Programming in Scala ).

 

programowanie

Komentarze

0 nowych
cyryllo   16 #1 09.07.2014 13:30

No nic Miki czekam na ten kurs ;)

Jusko   12 #2 09.07.2014 13:37

Wydaje się ciekawe.

Niemniej podchodzę sceptycznie do skracania składni. Widziałem już parę parę takich przykładów (frameworki) i według mnie krócej, nie zawsze oznacza logicznie. Wydaje mi się, iż zaglądając w kod po czasie - może być ciężej wgryźć się ponownie w taki skrótowy kod, niż mając tradycyjną szpaltę kodu.

Autor edytował komentarz.
Wokuo   7 #3 09.07.2014 15:51

Według mnie Scala daje za dużo swobody jeżeli chodzi o składnie. Jeżeli ktoś nie będzie trzymać programistów za tak zwaną mordę to kod będzie straszny.
Scala daje całkowitą swobodę jeżeli chodzi o wstawianie średników. Dodatkowo jeżeli metoda nie ma parametrów nie trzeba pisać nawiasów [ obiekt.metoda zamiast obiekt.metoda() ]. Dodatkowo między obiektem a metodą nie trzeba dawać kropki. To tylko kilka przykładów z wariacji jakie są w Scali.

Nie bardzo wiem co przykład podany w sekcji "Scala jako język wysokiego poziomu" ma wspólnego z wyższym poziomem abstrakcji. Jak dla mnie to jest po prostu dodatkowa metoda w klasie String. Nie wiem jak w Javie, ale w C# podobny efekt uzyskasz korzystając z Extension Methods, bez potrzeby przepisywania całych klas, dodatkowo nie posiadając nawet kodu źródłowego klasy bazowej.

W sumie w Scali to jedynie mechanizm "Aktorów" mi się spodobał.

Piotrek_20   10 #4 09.07.2014 16:25

W końcu ciekawy wpis na blogach. Czekam na więcej.

enedil   9 #5 09.07.2014 17:33

"refaktoring"? refaktoryzacja, po polsku

Quest-88   15 #6 09.07.2014 18:27

Jestem zainteresowany! :-)

nr47   7 #7 09.07.2014 19:06

"Do takich można by zaliczyć fakt, że typy prymitywne Javy nie dziedziczą od klasy Object. Ma to swoje zalety, jednak bardzo utrudnia programowanie uogólnione." - raczej generic types w Javie są zepsute i mało użyteczne.

Frankfurterium   9 #8 09.07.2014 19:10

Zdanie mam takie samo jak @Wokuo , a do tego uważam, że czas Scali już... minął. Dawniej bardzo się nią interesowałem. Przeszło dwa lata temu nawet popełniłem o niej dwa wpisy. Ale od tego czasu język zbyt mocno się nie rozwinął, a devowie ciągle chwalą się tymi samymi kilkoma dużymi użytkownikami. Rozwinęła się za to Java, przy czym kilka pomysłów wchłonęła wprost od Scali.

Parę razy widziałem kod produkcyjny w Scali. Dobrze napisany potrafi być naprawdę śliczny, napisany na szybko może być straszniejszy niż wszystko, co oglądałem w Javie. Ale większość tego i tak była Javą napisaną scalowymi klasami wykorzystującą parę dosłownie ficzerów. Musiała taka być, żeby współgrać z javowymi frameworkami, bo Scala ma ich mało.

IMO jakiś czas temu język miał chwilę popularności, zainteresował światek JVM paroma trendami, ale do pierwszej ligi nigdy nie trafi. Zbyt dziwny, zbyt elastyczny, za małe wsparcie biznesu, za trudny na DSL-a. Co nie znaczy, że nie warto się go uczyć, choćby dla rozrywki i poszerzenia horyzontów. Ale w tej materii sam zainteresowałbym się teraz raczej Ceylonem od JBossa.

mikolaj_s   13 #9 09.07.2014 23:32

@Jusko: Jak będziesz miał czas, aby przeglądnąć moje wpisy to zobaczysz o co mi chodzi ;) Tak ogólnie mogę teraz napisać, że tak jak w przykładzie z szukaniem stringa z wielką literą, kod może być krótszy, jednolinijkowy, a programista czytając go nie musi wnikać w jaki sposób działa, ważne co zwraca. Dzięki temu czyta szybciej, zazwyczaj nie musisz za każdym razem dokładnie śledzić co robi każdy kawałek kodu.

@Wokuo: To prawda co piszesz, ale w odniesieniu do pisania bibliotek. Biblioteki muszą być dobrze pomyślane. Jeżeli je ktoś dobrze napisze to powstaje w zasadzie coś na wzór DSL i używając go ciężko coś skopać.
Co do kropek i nawiasów to ostatnia wersja Scali to trochę zmieniła. Teraz to czy daje się nawias czy nie zależy od definicji metody.

"Nie bardzo wiem co przykład podany w sekcji "Scala jako język wysokiego poziomu" ma wspólnego z wyższym poziomem abstrakcji. Jak dla mnie to jest po prostu dodatkowa metoda w klasie String."

Dodatkowa metoda to isUpperCase, ale nie w klasie String tylko Char. Natomiast exists w rzeczywistości jest pętlą która przechodzi po wszystkich literach tego Stringa. String jest równocześnie kolekcją, która zawiera metody typowe dla języka funkcyjnego. W wymienionej metodzie użyto też skrótowej wersji funkcji anonimowej. Ważne jest, że kod jest krótki i jak ktoś ma jaką taką wprawę to prawie natychmiast wie co robi ten kod.

"W sumie w Scali to jedynie mechanizm "Aktorów" mi się spodobał."

Aktorzy są skopiowani z Erlanga, ale nieco zmienieni. Obecnie jest świetny framework wbudowany w Scalę o nazwie Akka. Jest też wersja Javowa Akki, ale Scalowa wersja jest łatwiejsza w użyciu.

@enedil: Tak to jest jak się czyta w oryginale i potem trudno znaleźć polskie słowo ;)

@@Frankfurterium:
"Ale od tego czasu język zbyt mocno się nie rozwinął"

A czego Ci brakuje w języku? Z fajnych rzeczy w Scali pojawiły się Future i Promises.

". Ale większość tego i tak była Javą napisaną scalowymi klasami wykorzystującą parę dosłownie ficzerów."

To tylko świadczy, że da się pisać nie zmieniając stylu pisania, czyli w zasadzie nie ucząc się całkowicie nowego języka. Aby zacząć pisać bardziej czytelnie funkcyjnie trzeba trochę czekać.

"IMO jakiś czas temu język miał chwilę popularności, zainteresował światek JVM paroma trendami, ale do pierwszej ligi nigdy nie trafi."

Zależy w jaki sposób oceniasz tę pierwszą ligę. Od wielu lat programowanie funkcyjne rozwija się równolegle z imperatywnym, ale jakoś nie może przebić się do mainstreamu, mimo, że jest uważana za lepsze. Być może po prostu sposób myślenia większości ludzi nie pasuje do tego stylu programowania i pewnie dlatego Scala nigdy nie osiągnie takiej popularności jak Java. Ten język trochę przypomina Erlanga, który też nie jest bardzo popularny, ale ma wiele zastosowań w których jest nie do zastąpienia. Podejrzewam, że ze Scalą będzie podobnie, albo trochę lepiej. Duże projekty zatrudniające dobrych programistów będą ciągle używać tego języka bo daje on o wiele większe możliwości i łatwość pisania i utrzymania kodu, tym samym dostarczając kod wyższej jakości. Natomiast mniejsze firmy nie będą sobie mogły na to pozwolić i zadowolą się popularnymi technologiami jak Java lub C#.

Wokuo   7 #10 10.07.2014 00:49

@mikolaj_s:
"Podejrzewam, że ze Scalą będzie podobnie, albo trochę lepiej. Duże projekty zatrudniające dobrych programistów będą ciągle używać tego języka bo daje on o wiele większe możliwości i łatwość pisania i utrzymania kodu, tym samym dostarczając kod wyższej jakości. Natomiast mniejsze firmy nie będą sobie mogły na to pozwolić i zadowolą się popularnymi technologiami jak Java lub C#."

Mam raczej inne odczucia co do tego. Jeszcze nigdy nie spotkałem firmy, w której cokolwiek było by napisane w Scali. Natomiast C# (opcjonalnie VB) oraz Java były w każdej i uwierz mi, że projekty do małych nie należały, a programiści za nie odpowiedzialni byli dużo lepsi niż tylko dobrzy.
Nie wiem czy to kwestia marketingu czy czegoś innego, ale Scala według mnie w biznesie się po prostu nie przyjęła.

  #11 10.07.2014 04:08

@mikolaj_s: Bo języki stricte funkcyjne są dla nerdów. Większość ich ciekawych elementów już dawno trafiła do C#, Pythona i JS, a nawet ostatnio do Javy.

Jak pytam fana języków funkcyjnych, żeby pokazał coś praktycznego, zamiast kolejnego fib, to mówi że to nie język do tego.

Zamiast się męczyć ze Scala, naucz się dobrych bibliotek dla Javy jak Guava.

Frankfurterium   9 #12 10.07.2014 09:50

Języki funkcyjne przydają się nie tylko do wyliczania ciągów, ale do różnego rodzaju newralgicznych sekcji wymagających wydajności przy ciężkiej algorytmice i ogromnym ruchu. To wszystko da się napisać w praktycznie każdym języku, ale przy standardowej obiektówce łatwiej walnąć gafę złą wielowątkowością albo nieodpowiednią pętlą. Za to pisanie całych projektów (nawet przy całej świetności Lispa i Clojure) już takie przyjemne nie jest.

Sama Guava jest dobra, ale trochę nieaktualna. Tak jak w przypadku Scali - spora jej część została wchłonięta do Javy 8.

mikolaj_s   13 #13 10.07.2014 10:17

@Wokuo: "Jeszcze nigdy nie spotkałem firmy, w której cokolwiek było by napisane w Scali."

Słabo się widocznie rozglądasz ;) Sprawdź chociażby oferty pracy, kilka firm się znajdzie.

@sprae:
"Jak pytam fana języków funkcyjnych, żeby pokazał coś praktycznego, zamiast kolejnego fib, to mówi że to nie język do tego. "

Nie bardzo rozumiem. Czyżby nie można było napisać aplikacji w Scali. Każdy kod który zapiszesz w Javie można zapisać w Scali, a dodatkowo masz możliwość pisania funkcyjnie.

"Zamiast się męczyć ze Scala, naucz się dobrych bibliotek dla Javy jak Guava."

Skąd takie założenie, że się z nią męczę? Wręcz przeciwnie, jestem zadowolony. Dzięki Scali i frameworkowi Lift jestem w stanie szybko pisać swoje aplikacje.
Sama Guava dopiero teraz przy użyciu funkcji anonimowych może się okazać równie wygodna w użyciu co kolekcje w Scali. Tyle, że dla mnie osobiście cała ta składnia jest raczej niezbyt pociągająca, szczególnie w porównaniu do Scali.

@Frankfurterium " Za to pisanie całych projektów (nawet przy całej świetności Lispa i Clojure) już takie przyjemne nie jest. "

Mam nadzieję, że nie stawiasz Scali pośród wymienionych języków. Bo mimo, że Scala jest funkcyjna to ten paradygmat nie jest jedynym. Np. Scala może operować również na mutowalnych zmiennych. Powiedziałbym, że jest prawie tym samym co obecna Java 8 tylko z kilkoma dodatkowymi elementami i lepszą bardziej przemyślaną składnią. I może jestem nietypowy, ale naprawdę nie widzę dlaczego pisanie w Scali miałoby być nieprzyjemne.

soanvig   9 #14 07.08.2014 14:01

@Wokuo: Jeśli Scala daje za dużo swobody, to lepiej nie zaglądaj do Rubiego. Serio.

  #15 08.08.2014 01:13

Jak ktos chce zwiezlosc, to niech programuje w Perlu. Celem Javy jest czytelnosc kodu i zmuszenie uzytkownikow, aby kod konkretnej funkcjonalnosci mogl byl pisany tylko na jeden konkretny sposob. Dzieki temu kod Javy jest czytelny i bezbledny. Eksperymenty takie jak Ruby, czy Scala, sa dobre dla ludzi, ktorzy nie tworza duzych, skomplikowanych programow od ktorych wymaga sie niezawodnosci.

mikolaj_s   13 #16 08.08.2014 11:24

@Anonim (niezalogowany): "Jak ktos chce zwiezlosc, to niech programuje w Perlu."
W Perlu można pisać tak, że nawet doświadczony programista będzie mieć problem z czytaniem. Słaba czytelność tego języka sprawia dużo problemów. Stąd jak sądzę niska popularność tego języka.

"Dzieki temu kod Javy jest czytelny i bezbledny. "
Kod ma tyle błędów ile popełni programista i nie ma to wiele wspólnego z wybranym językiem. Na czytelność też największy wpływ ma sposób w jaki pisze go programista. Można napisać program w Javie, który trudno się będzie czytać. Minusem Javy jest jej rozwlekłość. Sam się zastanów czy lepiej się czyta kod w którym jedną logiczną operację wykonuje się w jednej linijce, czy też w pięciu? W językach dynamicznych i podobnie w Scali kod jest krótki i dzięki temu czytelniejszy. Styl funkcyjny bardzo w tym pomaga. Mogę nawet nie rozumieć dokładnie jak działa dana linijka gdy czytam większy fragment kodu, ale wystarczy, że zanotuję co zwraca.

"Eksperymenty takie jak Ruby, czy Scala, sa dobre dla ludzi, ktorzy nie tworza duzych, skomplikowanych programow od ktorych wymaga sie niezawodnosci."

Problem w Rubym to brak statycznego typowania, co może przeszkadzać. Jednak napisano w nim wiele dużych serwisów jak chociażby Twittera. Chociaż Twitter po części zrezygnuje w wielu miejscach z Rubiego to jednak przyczyną nie jest nieczytelność czy niezawodność, a mniejsza wydajność. Notabene Rubiego zastępują właśnie Scalą, choć w aplikacjach backednu stosują też Javę. Scala ze względu na typowanie statyczne i wydajność zbliżoną do czystej Javy nie ma wad Rubiego (z którego swoją drogą sporo zgapiła). Jak najbardziej nadaje się do "dużych, skomplikowanych programów od ktorych wymaga sie niezawodnosci." Przykładem może być Foresquare, który całkowicie napisany został w Scali.

angh   8 #17 10.08.2014 21:02

Przyklad z szukaniem uppercase mnie rozwalil. Serio, taki potworek mozna napoisac w kazdym jezyku, nawet w scali, ale niczego on nie ilustruje.
takie:
val nameHasUpperCase = name.exists(_.isUpperCase)
w java moze byc zapisane jako:
boolean nameHasUpperCase = !name.equals(name.toUpperCase());
lub wykorzystujac wzorce:
boolean nameHasUpperCase name.matches(".*[A-Z].*");

Scala jest fajna alternatywa, ale nie ma co na sile wyszukiwac argumenty, ktore niewiele wnosza do tematu;)

  #18 11.08.2014 02:53

@mikolaj_s: "Kod ma tyle błędów ile popełni programista i nie ma to wiele wspólnego z wybranym językiem."

Kompletnie nie masz racji. Zeby to zrozumiec zainteresuj sie np. wspomnianym jezykiem Perl. Jak zobaczysz skomplikowane operacje zapisane w jednej linii, to sam zrozumiesz, ze pielegnowanie i poprawianie takiego kodu to koszmar.

"Sam się zastanów czy lepiej się czyta kod w którym jedną logiczną operację wykonuje się w jednej linijce, czy też w pięciu?"

Jak sobie wyobrazasz wykonanie jednej logicznej operacji w 5 linijkach? No chyba, ze przez "jedna logiczna operacje" rozumiesz cos innego niz ja.

Im bardziej "upakowany" jest kod, tym trudniejszy w rozumieniu - jest to oczywiste dla wiekszosci programistow i sa na to dziesiatki przykladow (np. niechec do korzystania, w Javie, z wyrazen warunkowych w postaci ?: ze wzgledu na duze upakowanie parametrow i brak czytelnosci).

A Java nie jest rozwlekla. Java jest przejrzysta i latwa do pielegnowania, poniewaz programisci implementuja te same funkcjonalnosci w podobny sposob (w odroznieniu od takiego np. C++, gdzie jedna rzecz mozesz napisac na setki sposobow). No, ale oczywiscie nie brakuje pasjonatow, ktorzy kolo chca wymyslac od nowa, a ze przy okazji tworzenia nowych jezykow gubione sa pewne bardzo wazne cechy to juz inna sprawa. Istotne jest, zeby zdawac sobie z tego sprawe przy wyborze jezyka programowania.

mikolaj_s   13 #19 11.08.2014 11:36

@Anonim (niezalogowany): "Kompletnie nie masz racji. "

Poczytaj serię książek R.C Martina w tym "Czysty kod", może zmienisz zdanie. Perl sam w sobie jest mało czytelny.
Czy czytając kod za każdym razem sprawdzasz dokładnie co robi każda linijka? Bo jeśli tak to faktycznie krótki kod Ci nie pomaga. Ale ja najczęściej czytając kod szukam konkretnej informacji więc przeglądanie wielu linijek mi to utrudnia, a kompletnie nie interesuje mnie najczęściej jak dana linijka działa tylko co zwraca.

" niechec do korzystania, w Javie, z wyrazen warunkowych w postaci ?: "

A może brzydota zapisu? w Scali używa się podobnie tylko pisze się val wynik = if(warunek) instrukcja else instrukcja i dla mnie jest to bardzo czytelne.

"A Java nie jest rozwlekla"
Jeśli muszę pisać dużo więcej znaków i linijek to dla mnie jest to rozwlekłość. Być może w Javie łatwiej się nauczyć pisać czytelniej niż w innych językach bo jest w miarę prosta, ale i tak czytelność zależy od programisty. Popatrz kiedyś na kod uczących się programowania ;)

mikolaj_s   13 #20 11.08.2014 11:49

@angh: Jak widać nie każdym języku jest to takie łatwe jak w Scali, bo w Twoim przykładzie zrobiłeś błąd. Zamiast name.toUpperCase() powinno być name.toLowerCase() ;)
Widać logicznie jest to trudniejsze do napisania. Przykład w Scali przy odrobinie wprawy jest super czytelny, cały kod to trochę niegramatyczny zlepek słów "w nazwie istnieje duża litera". Wyrażenia regularne to zupełnie inna kategoria i wymaga większej wprawy.
Po drugie kod w Scali jest odpowiednikiem tego, który jest wyżej napisany w Javie. To znaczy, że jest nieco wydajniejszy bo nie przetwarza całej pętli tylko sprawdza do pierwszego wystąpienia dużej litery.
No i na koniec, przyznałem się w tekście, że piszę to na podstawie "Programmig in Scala" Odersky'ego, Spoona i Vennersa i większość przykładów pochodzi z tej książki (pierwsza edycja dostępna jest za darmo online, ja mam papierową). W nawiasach w metodzie exists występuje funkcja anonimowa i może ona być nieco dłuższa. Trudno się spodziewać, że w przykładzie dla początkujących autorzy pokażą kod produkcyjny.

Autor edytował komentarz.
angh   8 #21 11.08.2014 13:23

@mikolaj_s: racja, kod wpisalem z roznych testow i wzialem nie ta linijke, co trzeba. Identyczny blad mozna zrobic i w scali, na glupote uzytkownika nie ma rady;)
Ale scale bede traktowal jako raczej ciekawostke. Pracuje troche w javie i generalnie urzycie takiego a nie innego jezyka jest wynikiem polityki filmy, a wsparcie do javy jest po prostu solidniejsze, co pociaga mniej problemow.

co do drugiego punktu, jezeli scala uzywa jvm, to ciezko powiedziec, jak jest z ta wydajnoscia. Dorzucanie kolejnej warstwy interpretujacej kod scala do kodu java moze powodowac dodatkowy overhead.
A co do wyrazen regularnych to nie znam nikogo pracujacego w zawodzie dluzej niz pare miesiecy, kto nie potrafi ich uzyc na zawolanie. Nie zawsze sa one najlepszym rozwiazaniem i nie zawsze dzialaja tak, jak sie spodziewamy, ale jezeli jest to wiadome to mozna uzywac je jeszcze bardziej efektywnie. Podany przeze mnie przyklad regexp jest bardzo szybkim, ale bardzo zlym przykladem. Nie chcialbym polegac na takim kodzie;) szczegolnie w miedzynarodowym srodowisku.

  #22 11.08.2014 18:40

@mikolaj_s: Sam sobie przeczysz - z jednej strony twierdzisz, ze:
Kod ma tyle błędów ile popełni programista i nie ma to wiele wspólnego z wybranym językiem".
a z drugiej "Perl sam w sobie jest mało czytelny".

Nie trzeba czytac ksiazek, wystarczy minimalne doswiadczenie programistyczne, zeby wiedziec, ze zbyt wiele informacji w jednej linii kodu utrudnia jego rozumienie.

Podam ci przyklad, zeby unaocznic o co chodzi.

Ten kod (Kod1 - zapisany w jednej linii):

zmienna = warunek1?(warunek2?wyrazenie21:(warunek22?wyrazenie221:wyrazenie222)):(warunek3?wyrazenie31:wyrazenie32);

Jest rownowazny ponizszemu kodowi (Kod2):

if (warunek1)
{
if(warunek2)
{
zmienna = wyrazenie21;
}
else
{
if(warunek22)
zmienna = wyrazenie221;
else
zmienna = wyrazenie222;
}
}
else
{
if(warunek3)
zmienna = wyrazenie31;
else
zmienna = wyrazenie32;
}


Jezeli twoim zdaniem Kod1 jest czytelny, a Kod2 jest rozwlekly, to najwyrazniej nigdy nie pracowales jako programista. Kazdy kierownik projektu kazalby przerobic Kod1 na wersje Kod2, z powodow o ktorych juz pisalem.

  #23 11.08.2014 18:41

mikolaj_s: Sam sobie przeczysz - z jednej strony twierdzisz, ze:
Kod ma tyle błędów ile popełni programista i nie ma to wiele wspólnego z wybranym językiem".
a z drugiej "Perl sam w sobie jest mało czytelny".

Nie trzeba czytac ksiazek, wystarczy minimalne doswiadczenie programistyczne, zeby wiedziec, ze zbyt wiele informacji w jednej linii kodu utrudnia jego rozumienie.

Podam ci przyklad, zeby unaocznic o co chodzi.

Ten kod (Kod1 - zapisany w jednej linii):

zmienna = warunek1?(warunek2?wyrazenie21:(warunek22?wyrazenie221:wyrazenie222)):(warunek3?wyrazenie31:wyrazenie32);

Jest rownowazny ponizszemu kodowi (Kod2):

if (warunek1)
{
if(warunek2)
{
zmienna = wyrazenie21;
}
else
{
if(warunek22)
zmienna = wyrazenie221;
else
zmienna = wyrazenie222;
}
}
else
{
if(warunek3)
zmienna = wyrazenie31;
else
zmienna = wyrazenie32;
}


Jezeli twoim zdaniem Kod1 jest czytelny, a Kod2 jest rozwlekly, to najwyrazniej nigdy nie pracowales jako programista. Kazdy kierownik projektu kazalby przerobic Kod1 na wersje Kod2, z powodow o ktorych juz pisalem.

  #24 11.08.2014 18:41

mikolaj_s: Sam sobie przeczysz - z jednej strony twierdzisz, ze:
Kod ma tyle błędów ile popełni programista i nie ma to wiele wspólnego z wybranym językiem".
a z drugiej "Perl sam w sobie jest mało czytelny".

Nie trzeba czytac ksiazek, wystarczy minimalne doswiadczenie programistyczne, zeby wiedziec, ze zbyt wiele informacji w jednej linii kodu utrudnia jego rozumienie.

Podam ci przyklad, zeby unaocznic o co chodzi.

Ten kod (Kod1 - zapisany w jednej linii):

zmienna = warunek1?(warunek2?wyrazenie21:(warunek22?wyrazenie221:wyrazenie222)):(warunek3?wyrazenie31:wyrazenie32);

Jest rownowazny ponizszemu kodowi (Kod2):

if (warunek1)
{
if(warunek2)
{
zmienna = wyrazenie21;
}
else
{
if(warunek22)
zmienna = wyrazenie221;
else
zmienna = wyrazenie222;
}
}
else
{
if(warunek3)
zmienna = wyrazenie31;
else
zmienna = wyrazenie32;
}


Jezeli twoim zdaniem Kod1 jest czytelny, a Kod2 jest rozwlekly, to najwyrazniej nigdy nie pracowales jako programista. Kazdy kierownik projektu kazalby przerobic Kod1 na wersje Kod2, z powodow o ktorych juz pisalem.

  #25 11.08.2014 18:42

mikolaj_s: Sam sobie przeczysz - z jednej strony twierdzisz, ze:
Kod ma tyle błędów ile popełni programista i nie ma to wiele wspólnego z wybranym językiem".
a z drugiej "Perl sam w sobie jest mało czytelny".

Nie trzeba czytac ksiazek, wystarczy minimalne doswiadczenie programistyczne, zeby wiedziec, ze zbyt wiele informacji w jednej linii kodu utrudnia jego rozumienie.

Podam ci przyklad, zeby unaocznic o co chodzi.

Ten kod (Kod1 - zapisany w jednej linii):

//zmienna = warunek1?(warunek2?wyrazenie21:(warunek22?wyrazenie221:wyrazenie222)):(warunek3?wyrazenie31:wyrazenie32);

Jest rownowazny ponizszemu kodowi (Kod2):

if (warunek1)
{
if(warunek2)
{
zmienna = wyrazenie21;
}
else
{
if(warunek22)
zmienna = wyrazenie221;
else
zmienna = wyrazenie222;
}
}
else
{
if(warunek3)
zmienna = wyrazenie31;
else
zmienna = wyrazenie32;
}


Jezeli twoim zdaniem Kod1 jest czytelny, a Kod2 jest rozwlekly, to najwyrazniej nigdy nie pracowales jako programista. Kazdy kierownik projektu kazalby przerobic Kod1 na wersje Kod2, z powodow o ktorych juz pisalem.

  #26 11.08.2014 18:42

mikolaj_s: Sam sobie przeczysz - z jednej strony twierdzisz, ze:
Kod ma tyle błędów ile popełni programista i nie ma to wiele wspólnego z wybranym językiem".
a z drugiej "Perl sam w sobie jest mało czytelny".

Nie trzeba czytac ksiazek, wystarczy minimalne doswiadczenie programistyczne, zeby wiedziec, ze zbyt wiele informacji w jednej linii kodu utrudnia jego rozumienie.

Podam ci przyklad, zeby unaocznic o co chodzi.

Ten kod (Kod1 - zapisany w jednej linii):

//zmienna = warunek1?(warunek2?wyrazenie21:(warunek22?wyrazenie221:wyrazenie222)):(warunek3?wyrazenie31:wyrazenie32);

Jest rownowazny ponizszemu kodowi (Kod2):

//if (warunek1)
{
//if(warunek2)
{
zmienna = wyrazenie21;
}
//else
{
if(warunek22)
zmienna = wyrazenie221;
else
zmienna = wyrazenie222;
}
}
//else
{
if(warunek3)
zmienna = wyrazenie31;
else
zmienna = wyrazenie32;
}


Jezeli twoim zdaniem Kod1 jest czytelny, a Kod2 jest rozwlekly, to najwyrazniej nigdy nie pracowales jako programista. Kazdy kierownik projektu kazalby przerobic Kod1 na wersje Kod2, z powodow o ktorych juz pisalem.

  #27 11.08.2014 18:43

mikolaj_s: Sam sobie przeczysz - z jednej strony twierdzisz, ze:
Kod ma tyle błędów ile popełni programista i nie ma to wiele wspólnego z wybranym językiem".
a z drugiej "Perl sam w sobie jest mało czytelny".

  #28 11.08.2014 18:44

mikolaj_s:

Nie trzeba czytac ksiazek, wystarczy minimalne doswiadczenie programistyczne, zeby wiedziec, ze zbyt wiele informacji w jednej linii kodu utrudnia jego rozumienie.

Podam ci przyklad, zeby unaocznic o co chodzi.

Ten kod (Kod1 - zapisany w jednej linii):

zmienna = warunek1?(warunek2?wyrazenie21:(warunek22?wyrazenie221:wyrazenie222)):(warunek3?wyrazenie31:wyrazenie32);

Jest rownowazny ponizszemu kodowi (Kod2):

if (warunek1)
{
if(warunek2)
{
zmienna = wyrazenie21;
}
else
{
if(warunek22)
zmienna = wyrazenie221;
else
zmienna = wyrazenie222;
}
}
else
{
if(warunek3)
zmienna = wyrazenie31;
else
zmienna = wyrazenie32;
}


Jezeli twoim zdaniem Kod1 jest czytelny, a Kod2 jest rozwlekly, to najwyrazniej nigdy nie pracowales jako programista. Kazdy kierownik projektu kazalby przerobic Kod1 na wersje Kod2, z powodow o ktorych juz pisalem.

  #29 11.08.2014 18:47

mikolaj_s:

Nie trzeba czytac ksiazek, wystarczy minimalne doswiadczenie programistyczne, zeby wiedziec, ze zbyt wiele informacji w jednej linii kodu utrudnia jego rozumienie.

Podam ci przyklad, zeby unaocznic o co chodzi.

Ten kod (Kod1 - zapisany w jednej linii):

zmienna = warunek1?(warunek2?wyrazenie21:(warunek22?wyrazenie221:wyrazenie222)):(warunek3?wyrazenie31:wyrazenie32);

Jest rownowazny ponizszemu kodowi (Kod2):

if (warunek1)
{
if(warunek2)
{
zmienna = wyrazenie21;
}
else
{
if(warunek22)
zmienna = wyrazenie221;
else
zmienna = wyrazenie222;
}
}
else
{
if(warunek3)
zmienna = wyrazenie31;
else
zmienna = wyrazenie32;
}


Jezeli twoim zdaniem Kod1 jest czytelny, a Kod2 jest rozwlekly, to najwyrazniej nigdy nie pracowales jako programista. Kazdy kierownik projektu kazalby przerobic Kod1 na wersje Kod2, z powodow o ktorych juz pisalem.

  #30 11.08.2014 18:52

@mikolaj_s:
PS. Kod1 i Kod2 musisz sobie oczywiscie sformatowac (usuniecie laman linii, pododawac wciecia), bo jak widac dobreprogramy.pl nie maja szacunku dla formatowan w dodawanych komentarzach.

  #31 11.08.2014 19:13

@angh: "Dorzucanie kolejnej warstwy interpretujacej kod scala do kodu java moze powodowac dodatkowy overhead."

Kod Skali jest kompilowany do bytecodu, wiec zadnej "kolejnej warstwy interpretujacej" nie ma. Overhead moze sie pojawic na etapie kompilacji.

mikolaj_s   13 #32 11.08.2014 20:52

@angh: Zawsze można używać Scali w jakiś mniejszych częściach projektu. Nie raz na JUGu słyszałem jak w firmach tak robią. Można też używać w prywatnych projektach, tutaj nikt Ci nie narzuca technologii. ;) Pytanie czy warto inwestować w naukę Scali, ale tutaj sądzę, że warto chociażby po to aby potem lepiej rozumieć elementy funkcyjne w Javie. Sam używam go bo w połączeniu z używanym przeze mnie Liftem jestem w stanie pisać szybko aplikacje WWW, może nawet szybciej niż gdy pisałem w django i Pythonie. Tego nie da mi Java.

"Dorzucanie kolejnej warstwy interpretujacej kod scala do kodu java moze powodowac dodatkowy overhead. "

Tak zazwyczaj jest. W różnego rodzaju benchmarkach czasem nie ma żadnego narzutu, ale czasem sięga +50% czasu wykonania programu. Ale jak popatrzymy na języki dynamiczne działające na JVM jak Jython czy JRuby to nie ma porównania.

mikolaj_s   13 #33 11.08.2014 21:29

@Anonim (niezalogowany): "Kod Skali jest kompilowany do bytecodu, wiec zadnej "kolejnej warstwy interpretujacej" nie ma. Overhead moze sie pojawic na etapie kompilacji."

Ale są odwołania do bibliotek Scali co nieco wydłuża czasem czas działania programów.

"Sam sobie przeczysz - z jednej strony twierdzisz, ze:
Kod ma tyle błędów ile popełni programista i nie ma to wiele wspólnego z wybranym językiem".
a z drugiej "Perl sam w sobie jest mało czytelny"."

Tak masz rację. ;) Ale Perl jest tutaj szczególnym wyjątkiem. Chciałem powiedzieć raczej, że ważniejsza w tym względzie jest wiedza i umiejętność programisty niż język sam w sobie, chociaż faktycznie są języki gdzie łatwiej można coś sknocić.

Przykład kodu bardzo dobry bo trafia w sendo. Jasne, że dla takich zapętlonych warunków pierwszy kod jest zupełnie nieczytelny. Ale drugi jest tylko trochę czytelniejszy. W tym przypadku napisałbym go w Scali tak:

def czyWarunek22 = if(warunek22) wyrazenie221 else wyrazenie222

def czyWarunek3 = if(warunek3) wyrazenie31 else wyrazenie32

def czyWarunek2 = if(warunek2) wyrazenie21 else czyWarunek22

val zmienna = if(warunek1) czyWarunek2 else czyWarunek3

(W scali wyrażenie if - else zwraca wartość)

Czytelność tego kodu byłaby w dużym stopniu uzależniona od dobrze dobranych nazw warunków. A rozbicie kodu na osobne wyrażenia jedno linijkowe ułatwia czytanie, a w sumie linijek jest mniej niż w Twoim przykładzie. Ponadto w przypadku wielu możliwych opcji (ale płaskich, a nie tak jak w tym przykładzie) w Scali zamiast else if można użyć match - case, która bardzo poprawia czytelność kodu (coś jak switch, ale można sprawdzać prawie wszystko w tym typ, bardzo potężne narzędzie do ułatwiania sobie życia).
Co do tych jednolinijkowych wyrażeń to pomyśl bardziej przez porównanie do jQuery gdzie wynik jednego przetworzenia poddawany jest następnemu napisanemu w tej samej linii. O ile wiem coraz częściej jest podobna tendencja w Javie, chociażby na przykładzie frameworka Guava.
Sama Java IHMO dąży właśnie do czegoś podobnego do Scali, tylko że utrzymując kompatybilność wsteczną, a dodając nowe elementy sama stanie się potworkiem.

Autor edytował komentarz.
angh   8 #34 12.08.2014 01:09

@mikolaj_s: Zawsze warto sie uczyc, jezeli wciaz sie szuka swojej specjalizacji;) A jak juz sie znajdzie, to wtedy szlifuje sie tylko to, w czym sie pracuje, po jakichs 2-4 latach, jako senior, mozna znalezc czas na hobbistyczna zabawe innymi jezykami;) Niestety, ilosc specjalistycznej wiedzy jest na tyle duza, ze nie da sie byc dobrym we wszystkim.

@Anonim: overhead istnieje, poniewaz dodatkowe objekty i funkcje skali musza byc wkompilowane. Kompilator robi wiele, zeby uproscic bytecode i usuwa wiele niepotrzebnych odwolan, ale gdyby potrafil sam z siebie usunac wszystkie performance engineer bylby niepotrzebny - a tak nie jest. Trzeba miec spora wiedze, zeby napisac kod tak, aby ten overhead byl minimalny.
Co do twojego przykladu kodu, no to jest troche demagogia. Operator trojargumentowy jest swietnym konstruktem, jezeli jest uzywany zgodnie z przeznaczeniem. W dodatku, zaden kierownik projektu nie przeglada kodu pracownikow. Chyba by sie zajechal. Od tego sa unit testy i systemy raportowania, aby trzymac kontrole, a sam kod powinien byc czytelny, ale nawet potrojnie zagniezdzony operator trojargumentowy nie jest czyms, co uznalbym za wyjatkowo nieczytelne. Za to sa inne kryteria, jak na przyklad wydajnosc - tenary operator jest wolniejszy niz zwykly 'if' w Java.

A czytelnosc?
// IF
int a;
if (i == 0)
{
a = 10;
}
else
{
a = 5;
}

//Tenary
int a = (i == 0) ? 10:5;

Drugi jest ZNACZNIE czytelniejszy. Wszystko zalezy od wymagan i konkretnej sytuacji.

Autor edytował komentarz.
  #35 12.08.2014 18:48

@angh: Mam wrazenie, ze nie rozumiesz pojecia demagogia, ani tego czym jest interpretacja kodu. Poczytaj sobie najpierw o tym co to jest Interpreter i proces kompilacji.

Oczywiscie, ze kierownik jest odpowiedzialny za kody tworzone przez podleglyc mu programistow. Nie oznacza to, ze kazda linijke kodu musi osobiscie sprawdzic, ale moze zbierac informacje o lewym kodzie od swoich pracownikow i wyciagac konsekwecje. Wspolczesne repozytoria kodow rowniej wspomagaja utrzymywanie porzadku w kodzie.

Co do Operatora trojargumentowego, to (az glupio o tym pisac) ponownie nie zrozumiales sedna problemu.

  #36 12.08.2014 19:14

@mikolaj_s:

"Ale Perl jest tutaj szczególnym wyjątkiem."

Niestety jezykow ktore sklaniaja do pisania niejasnego i trudnego w analizie kodu, jest cala masa. Swietnym przykladem jest tutaj C++, w ktorym prosta funkcjonalnosc mozna napisac na tak wiele sposobow, ze potem niejeden programista ma problem z analizowaniem takich kodow (bo jeden lubi uzywac wskaznikow, drugi referencji, trzeci tablic, a czwarty przeciazonych operatorow).

Twoj odpowiednik Kod1 (z mojego przykladu) zapisany w Skali jest rownie nieczytelny. Pracowalem w wielu roznych projektach, poprawialem kod pisany w Polsce i za granica i wierz mi, ze gdybys po 7 godzinach pracy mial analizowac kod, jaki podales w Skali (a, zeby utrudnic, wrednie zalozmy, ze nie ma w nim przypisania wartosci do zmiennej, ale sa wywolania funkcji), to by cie szlak trafil, tak jak kazdego normalnego programiste.

Po latach pracy w zawodzie programisty, kiedy opada juz entuzjazm zwiazany z poznawaniem roznych jezykow i fikusnych technologii, kiedy cala uwaga jest skupiona na dostarczeniu programu do klienta, okazuje sie, ze jest tylko jedno kryterium w doborze jezyka programowania - czytelnosc kodu. Java oferuje fantastyczna czytelnosc, bo z mysla o niej byla projektowana. Skala nie jest juz taka czytelna i dlatego Java zajmuje wiodaca pozycje na rynku, a Skala to ciekawostka. Nie twierdze, ze nie warto uczyc sie Sklali, bo uczyc sie warto wszystkiego, nawet Perla, ale warto sobie zdawac sprawe z pewnych niuansow zwiazanych z wyborem jezyka programowania.

angh   8 #37 12.08.2014 19:45

@Anonim (niezalogowany): zgodze sie ze stwierdzeniem, ze jeden z nas nie rozumie;)

mikolaj_s   13 #38 12.08.2014 19:47

@Anonim (niezalogowany): Pojęcie czytelności jak widać jest względnie. Dla mnie Twój kod jest dużo mniej czytelny. Dochodząc do ostatnich ifów pewnie już bym zapomniał co było w pierwszym. W moim przykładzie wszystko opiera się o dobranie odpowiednich nazw.
A co do pisania w Scali, to mi zwiększa szybkość pisania kodu, a potem dużo szybciej mogę go czytać niż w jakimkolwiek znanym mi języku. Może to kwestia percepcji.

  #40 13.08.2014 02:58

@mikolaj_s: Jezeli kod, ktory stworzyles w Skali (odpowiednik Kod1), jest dla ciebie bardziej czytelny (od Kod2), to nie mamy o czym dalej rozmawiac. Po prostu roznimy sie w rozumieniu pojecia: czytelnosc kodu.

Tlumaczenie "dochodząc do ostatnich ifów pewnie już bym zapomniał co było w pierwszym" kompletnie mnie nie przekonuje - rownie dobrze mozesz zapomniec co jest na poczatku twojego kodu analizujac ta zlepiona, zbita w jeden blok kasze manna. Kod2 ma jasna strukture (wciecia, podzial na linie), a twoj kod nie posiada tej cechy.

mikolaj_s   13 #41 13.08.2014 11:35

@Anonim (niezalogowany): Czytelność mojego kodu byłaby bardzo uzależniona od odpowiedniego doboru nazw. Nazwy dla czytelności to, poza rozbiciem kodu na mniejsze części, podstawa.

Normalny człowiek ponoć jest w stanie zapamiętać co było do w siedmiu ostatnich linijek. W moim kodzie jeśli pamiętam co daje wynik poprzednich dwóch linijek to mogę zrozumieć następną.

angh   8 #42 13.08.2014 12:03

@Anonim (niezalogowany): ok, z demagogia racja. Powinienem napisac: manipulacja.

A interpretera/jit/kompilatora to chyba sam nie rozumiesz, albo cos ci umknelo w dyskusji. Bo chyba nie uwazasz, ze traktuje jit byte code jako jedynie jezyk interpretowany w stylu js...;)

  #43 15.08.2014 19:00

@mikolaj_s: Normalny czlowiek/programista juz po rzucie oka na Kod2 widzi jego strukture - widzi podzialy oraz to, jakie czesci tego kodu beda go interesowac, a jakie sa nieistotne. Ludzie to wzrokowcy, wiec latwo zapamietuja i rozrozniaja poszczegolne czesci kodu, ktore roznia sie dzieki wcieciom i nawiasom.

Po rzucie oka na twoj kod widac jedynie blok skomplikowanych warunkow. I dobor nazw niczego tu nie zmienia.

Ale ja nie mam zamiaru nikogo na sile przekonywac, ani walkowac w nieskonczonosc ten sam temat. Jak chcesz, to programuj sobie wszystko z uzyciem operatora trojargumentowego.

  #44 15.08.2014 19:06

@angh: Pojecia manipulacja najwyrazniej tez nie rozumiesz, skoro mi ja zarzucasz w miejsce, zle przez ciebie pojmowanej, demagogii.

"A interpretera/jit/kompilatora to chyba sam nie rozumiesz, albo cos ci umknelo w dyskusji. Bo chyba nie uwazasz, ze traktuje jit byte code jako jedynie jezyk interpretowany w stylu js...;)"

Nie rozumiem tego zdania. To jakis belkot.

Twoj blad polega na tym, ze nazywasz translacje kodu interpretacja i tylko o to mi chodzilo.

mikolaj_s   13 #45 15.08.2014 23:32

@Anonim (niezalogowany): "Jak chcesz, to programuj sobie wszystko z uzyciem operatora trojargumentowego."

W Scali go nie ma ;)

  #46 15.08.2014 23:37

@mikolaj_s: "W Scali go nie ma ;)"

A czy ktos kazal ci sie uczepic Scali? Litosci...

mikolaj_s   13 #47 16.08.2014 10:49

@Anonim (niezalogowany): Już się dawno uczepiłem i nie zamierzam zmieniać.

  #48 16.08.2014 18:04

@mikolaj_s: Nie warto sie czepiac i warto zmieniac... na lepsze :).

mikolaj_s   13 #49 17.08.2014 01:29

@Anonim (niezalogowany): Moze kiedyś pojawi się coś lepszego to pomyślę

angh   8 #50 17.08.2014 23:52

@Anonim (niezalogowany): Alez, juz napisalem, ze demagogia w sensie politycznym istotnie byla przeze mnei zle uzyta.
Manipulacja zas jest dosc widoczna - polega na przejaskrawieniu przykladow i probie sprowadzenia ich do smiesznosci.

Widze zreszta, ze rzeczy, ktorych nie rozumiesz, jest wiecej. Piszac interpretacja nie odnosilem sie ani do translacji, ani intepretera, a jedynie do tego, jak kod napisany w Scali zostanie przez kompilator zrozumiany, i jakich bibliotek on uzyje do wygenerowania byte code. I te 'rozumienie' nazwalem interpretacja. Twoim bledem jest to, ze nie uzywamy tego samego slownika (dziedzin).

  #51 24.08.2014 00:48

@angh: "Manipulacja zas jest dosc widoczna - polega na przejaskrawieniu przykladow i probie sprowadzenia ich do smiesznosci. "

Jezeli rozsmieszyl cie przyklad z odrzuceniem zlego kodu przez kierownika projektu, to jest on z zycia wziety - z projektu w ktorym bralem udzial. Kod byl znacznie obszerniejszy i troche gorszy (mniej czytelny), niz omawiane tu przyklady brzydkiego programowania, ale niewiele gorszy. Skonczylo sie na przepisaniu go od zera z informacja do osoby, ktora go pisala, ze jej kod laduje w koszu. Tak wiec nie ma tu zadnej manipulacji, a jedynie twoja zla ocena podszyta subiektywnym "zdawalo mi sie".

"Interpretacja kodu" jest pojeciem jednoznacznym. Uznales, ze proces ten zachodzi tam, gdzie ne zachodzi (vide: "Dorzucanie kolejnej warstwy interpretujacej kod scala do kodu java moze powodowac dodatkowy overhead."), wiec to sprostowalem. Tymczasem okazuje sie, ze ty tylko uzyles tego zwrotu w zlym kontekscie, bo poslugujesz sie "innym slownikiem z innej dziedziny". Nie wiem z jakiej dziedziny uzywasz slownika, ale nie wprowadzalbys zametu na forum i nie musial potem unosic sie honorem, w obronie wypisanych banialukow, gdybys poslugiwal sie slownikiem z dziedziny informatyki.

  #52 24.08.2014 00:51

@angh: "Manipulacja zas jest dosc widoczna - polega na przejaskrawieniu przykladow i probie sprowadzenia ich do smiesznosci. "

Jezeli rozsmieszyl cie przyklad z odrzuceniem zlego kodu przez kierownika projektu, to wiedz, ze jest on z zycia wziety - z projektu w ktorym bralem udzial. Kod byl znacznie obszerniejszy i troche gorszy (mniej czytelny), niz omawiane tu przyklady brzydkiego programowania, ale niewiele gorszy. Skonczylo sie na przepisaniu go od zera z informacja do osoby, ktora go pisala, ze jej kod laduje w koszu. Tak wiec nie ma tu zadnej manipulacji, a jedynie twoja zla ocena podszyta subiektywnym "zdawalo mi sie".

"Interpretacja kodu" jest pojeciem jednoznacznym. Uznales, ze proces ten zachodzi tam, gdzie ne zachodzi (vide: "Dorzucanie kolejnej warstwy interpretujacej kod scala do kodu java moze powodowac dodatkowy overhead."), wiec to sprostowalem. Tymczasem okazuje sie, ze ty tylko uzyles tego zwrotu w zlym kontekscie, bo poslugujesz sie "innym slownikiem z innej dziedziny". Nie wiem z jakiej dziedziny uzywasz slownika, ale nie wprowadzalbys zametu na forum i nie musial potem unosic sie honorem, w obronie wypisanych banialukow, gdybys poslugiwal sie slownikiem z dziedziny informatyki.