Wpis z mikrobloga

@devopsiarz: to jeszcze tylko zlikwidować te głupie wymaganie używania wszystkich zmiennych i wszystkich importów, dodać sum types i przeprojektować system obsługi błędów, zrobić specyfikatory dostępu public/private zamiast konwencji nazewniczej, poprawić detekcję race'ów, aby działała zawsze i wykrywała błędy w czasie kompilacji a nie tylko od czasu do czasu w runtime, zlikwidować pauzy GC, dorzucić jakiś sensowny system paczkowania z repo paczek (a nie tylko GitHub) i będzie nieźle. A nie,
  • Odpowiedz
@Krolik: obstawiam, że nikogo nie interesuje, co Ty tam chcesz mieć w języku programowania i co Ty uznajesz za "głupie" lub "mądre". Popraw mnie jeśli się mylę: daj linka do jakiejś Twojej propozycji jakiegoś języka, która przeszła review i weszła do użytku. ( ͡° ͜ʖ ͡°)

I go mod nie obsługuje "tylko GitHuba", a GC można wyłączyć w pewnych sytuacjach - wiedziałbyś to wszystko, gdybyś więcej
  • Odpowiedz
@devopsiarz: twardy error kiedy masz nieużywane zmienne lub nieużywane importy jest *obiektywnie* złą rzeczą. To nie jest kwestia gustu, że się komuś podoba czy nie. Byłoby kwestia gustu gdyby to był jakiś trejdoff, czyli coś za coś. Ale tu nie ma pozytywów. Warningi są pod każdym względem lepsze.
  • Odpowiedz
@Krolik: poproszę zatem o szanowaną pracę naukową, która dowodzi, że jest to "obiektywnie zła rzecz". Skoro jest to "obiektywne", to pewnie istnieje jakiś minimalny konsensus naukowy w tej sprawie, a nie tylko Twoja prywatna opinia.

I nie, nie twierdzę, że to jest dobre/złe. Jedyne co twierdzę, że po prostu uznajesz swoje prywatne opinie za jakkolwiek "obiektywne", tak skromnie ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@marahin: Dlatego, że jak np. debugujesz, i wyłączysz jakiś fragment kodu aby zobaczyć co się stanie, to dostajesz litanie błędów, bo masz nieużywane rzeczy w projekcie. I jeśli tylko tracisz czas na komentowanie / usuwanie tych nieużywanych rzeczy, to pół biedy, się widziałem jak ludzie dają specjalnie przypisanie do podkreślnika aby wygasić błędy. I takie coś już jest niebezpieczne i może prowadzić do twardych błędów.
  • Odpowiedz
@devopsiarz: obiektywne, bo można zmierzyć czas stracony na usuwanie / komentowanie nieużywanych rzeczy (a potem przywracanie ich) podczas pracy z kodem. Strata czasu jest mierzalna i obiektywna. I nie odzyskujesz tego czasu nigdzie, bo ten ficzer nie ma tej drugiej strony która zwykle jest w "coś za coś".
  • Odpowiedz
@Krolik: hm. No ja na przykład używam debuggera w pracy, i owszem, jak wyłączę kod, to importy też powinny "zniknąć", ale w znakomitej większości wypadków robi to za mnie goimports / fmt czy inny tam jakiś formatter. Przyznaję, że zdarzyły się też importy aliasowane, które już potem same się nie zaimportują.
  • Odpowiedz
@marahin: ale tak z drugiej strony to na tyle rzadki case, że nie wiem, czy mi to przeszkadza. A przynajmniej stawiając taki wymóg, to ten kod jakoś taki czystszy... czy nie? :)
  • Odpowiedz
@Krolik: automatem się chyba nie da? :) Nie przypominam sobie, żeby kiedykolwiek się zirytować na to, że mi podkreśliło nieużywaną zmienną. Może to dlatego, że staram się raczej ten kod izolować, i w miarę małe klocki wywoływać. Ale wiem o co Ci chodzi, i jestem w stanie sobie wyobrazić sytuacje, gdy praca w ten sposób frustruje programistę. Dzięki!
  • Odpowiedz
. A przynajmniej stawiając taki wymóg, to ten kod jakoś taki czystszy... czy nie? :)


@marahin: ale taki wymóg możesz postawić w praktycznie każdym języku, który robi to prawilnie przez ostrzeżenia. Dajesz odpowiednią regułę w CI że ma nie być ostrzeżeń i już. Nikt nie wkomituje syfu, ale można normalnie z kodem pracować.
  • Odpowiedz
@Krolik: obiektywnie rzecz biorąc, nie mam Twoich problemów (no i co teraz?), bo:

1) Znam go spec i co cięższe packages mają init() i nie muszę nic zakomentowywać. Znowu: wymaga to znajomości języka większej niż na potrzeby internetowej znajomości, czego mu brakuje do Rusta
2) Debugger i goimports już Ci wypomniano
3) Jak coś musisz zakomentowywać, aby coś sprawdzić, to chyba coś nie tak z Twoim kodem, przy czym, to
  • Odpowiedz
@devopsiarz: nieużywane funkcje nie są błędem? Ale jeśli tak, to z kolei to też jest źle. Bo powinno być ostrzeżenie - nieużywane cokolwiek w kodzie może (ale nie musi) oznaczać błędu. Btw Rust nie ma tu nic do rzeczy, Java i C++ też nie robią tak pod górkę - dla mnie Go to krok wstecz względem tych języków. IMHO gdyby to nie powstało w Google to pies z kulawa noga
  • Odpowiedz
@Krolik: zadziwię Cię, ale nie - patrzę na taką jedną właśnie w GoLandzie (jest na szaro co wskazuje na brak użycia gdziekolwiek) i nazwa zaczyna się z małej litery. Wyeksportowane nieużywane funkcje (bo tak się to nazywa w Go), czyli te z nazwami od wielkiej litery, również nie wkurzają kompilatora w żaden sposób.

Naprawdę, wystarczy napisać coś więcej niż "Hello World", nie wiem, 2 katalogi (packages) z kodem i będzie
  • Odpowiedz
@devopsiarz: Aha, czyli kompilator nie ostrzega przed nieużywanymi funkcjami, ale ostrzega przed nieużywanymi zmiennymi i nieużywanymi importami. Żelazna konsekwencja. No to po cholerę zawracać głowę nieużywanymi importami, które są sprawą całkowicie kosmetyczną? Nieużywana funkcja w produkcyjnym kodzie może jeszcze oznaczać błąd - np. ktoś robił copy-paste (co w Go jest częstą praktyką) i zapomniał zmienić wywołanie na nową funkcję, natomiast nieużywany import - trochę trudno sobie wyobrazić aby to był
  • Odpowiedz
@Krolik: wciąż czekam, aż poprzesz swoje twierdzenia jakąś pracą naukową, bo zmierzamy w dyskusji donikąd. Twoje prywatne opinie i odczucia nikogo nie obchodzą, w tym twórców języka. Rzuciłem tu w pierwszym poście linka do issues na githubie i zobacz jaka tam jest dyskusja na poziomie, w tym z gościami od C#, którzy patrzą na niektóre zmiany swoje języka z perspektywy czasu. Absolutne przeciwieństwo Twoich pretensji, nawet jak uważają, że coś
  • Odpowiedz
@devopsiarz: ojej, ale to Ty się striggerowales i stosujesz ad hominem fallacy zamiast odeprzeć argument. Jak tak chcesz naukowej debaty to sorry, nie tędy droga. Ja tylko napisałem, że skoro poprawiają te popsute pętle, to jeszcze tylko poprawia parę innych denerwujących rzeczy i ten język będzie się do czegoś nadawał. Owszem, to jest opinia, może trochę rant, niemniej te ułomności o których napisałem są realne i to już nie jest
  • Odpowiedz
@devopsiarz: btw, w sumie i tak wole Go, niż Pythona, ale irytuje mnie że mógł być dużo lepszy, gdyby do tak się nie pospieszyli z projektem. Trochę analogicznie jak pierwszą Jave wypuścili za szybko bez genericsów i bez lambd.
  • Odpowiedz
Twoje prywatne opinie i odczucia nikogo nie obchodzą, w tym twórców języka


@devopsiarz: Czyli może język zaprojektowany średniawo, ale przynajmniej community toksyczne ( ͡° ͜ʖ ͡°).
  • Odpowiedz