Czy PHP jest dobre

[Xirdus]

Słaby argument. Można go sprowadzić do absurdu wnioskując, że skoro są unit testy to statyczne typowanie jest niepotrzebne.

Gdzieś widziałem nawet o tym tekst, bodajże na blogu Xiona (nie mogę go jednak teraz odszukać, więc być może gdzie indziej).

[Mr. Spam]

[koirat]

@up Ale o czym ? Że unit testy miały by zastąpić statyczne typowanie ?

[Xirdus]

Tak.

[koirat]

Jak już znajdziesz ten artykuł to powiedz Xion-owi gdzie go ma żeby mógł go wykasować ;)
Bo jak by na to nie spojrzeć statyczne typowanie a Unit Test-y to zupełnie inne bajki.

[Xender]

Słaby argument. Można go sprowadzić do całkiem sensownego wniosku, stwierdzając, że skoro są unit testy to statyczne typowanie jest niepotrzebne.

Poprawiłem kilka słów w wypowiedzi (FTFY). ;)

Statyczne (w przeciwieństwie do dynamicznego) typowanie nie jest i nie powinno być celem samym w sobie.
Statyczne typowanie ma sens przy kompilacji AOT (ahead of time) - gdy błąd może zostać wychwycony, nim program zostanie wykonany.
W kompilacji JIT w konfiguracji per funkcja lub interpretacji kodu statyczne typowanie byłoby tylko upierdliwe.
W dodatku silne typowanie w wykonaniu C++ skutecznie utrudnia tworzenie heterogenicznych lub drzewiastych kontenerów, których struktura znana jest dopiero w runtime.
I to jest IMHO jeden z głównych powodów, dla którego w większości zastosowań C++ jest naprawdę nieefektywne.

A więc co jest celem? Ja bym powiedział, że to, żeby program działał [w określonym stopniu] niezawodnie i zgodnie z oczekiwaniami.

I jeśli chodzi o spełnienie tego celu - testy (niekoniecznie unit testy!*) IMHO mogą z powodzeniem zastąpić statyczne typowanie.
Natomiast samo statyczne typowanie bez testów niestety niewiele pomaga.
Bugi w programach pisanych w C/C++ widuję chyba częściej, na pewno są one o wiele gorsze do diagnozowania (segfault i coredump vs. stacktrace, gdb vs. pdb).

* Sformułowanie "testy jednostkowe" zaczyna mi wyglądać na kolejne magiczne słowo (buzzword), powtarzane bez głębszego zrozumienia. Może zostańmy przy samym "testy" albo "zautomatyzowane testy"?

Co innego silne (w przeciwieństwie do słabego) typowanie - to, że 2 stringi nie zostana przy porównywaniu przekonwertowane na liczby to dość elementarne oczekiwanie użytkownika.

Jak już znajdziesz ten artykuł to powiedz Xion-owi gdzie go ma żeby mógł go wykasować ;)
Bo jak by na to nie spojrzeć statyczne typowanie a Unit Test-y to zupełnie inne bajki.

Wykasuj lepiej tego posta. :P (ups, chyba go uwieczniłem w cytacie)

[Veldrin]

KAŻDY język oprogramowania, który pozwoli zarobić pieniądze jest DOBRY. Jakiego uczulenia na Jave bym nie miał to i tak jej użyję jak będzie taka potrzeba.

[bies]

Poprawiłem kilka słów w wypowiedzi (FTFY). ;)

Nie. Tylko patrzysz z innej perspektywy. Celem jest: niezawodnie*, zgodnie z oczekiwaniami i w budżecie. Testy kosztują znacznie więcej niż uruchomienie make/mvn/scons itp. A poza tym nie zapewniają pełnego pokrycia. Zatem dopisywanie testów do rzeczy które w trywialny sposób weryfikuje system typów to strata czasu ergo pieniędzy.

Co do heterogenicznych kontenerów w C++. Jeśli struktura jest znana dopiero w runtime to znaczy, że istnieje jakiś wspólny mianownik dla wszystkich typów którego można użyć (string + nullptr?). Więc C++ nic tu nie przeszkadza -- po prostu weryfikujesz pewne rzeczy w runtime. Co nie znaczy, że będę pisał backend aplikacja webowej w C++ (tu użyję raczej Xtenda lub Pythona).

*) zgadza się to jest pewna granica do której się dąży

Aha w cytacie powiedziałeś dwa razy to samo (czepiam się, wiem).

[Xirdus]

Nie. Tylko patrzysz z innej perspektywy. Celem jest: niezawodnie*, zgodnie z oczekiwaniami i w budżecie. Testy kosztują znacznie więcej niż uruchomienie make/mvn/scons itp. A poza tym nie zapewniają pełnego pokrycia. Zatem dopisywanie testów do rzeczy które w trywialny sposób weryfikuje system typów to strata czasu ergo pieniędzy.

Ale pamiętaj, e w Pythonie pisze się szybciej = taniej. Jak testy nie zapewniają pełnego pokrycia to trzeba ich po prostu dopisać więcej :) Zresztą wcale nie trzeba pisać podstawowych testów - bardziej złożone bazują na tym, że te podstawy działają.

Żeby nie było - osobiście preferuję jednak statyczne typowanie.

[kapustman]

Kompatybilność z C, templatki i brak modułów to główne bolączki, ale nie jedyne.

Hmm, z modułami się zgodzę, przydałby się. Templatki, to zależy. Jak nie przesadzasz z nimi, to są bardzo pożytecznym narzędziem, ale dla mnie nie nadają się do metaprogramowania (std::enable_if to już przesada). Co do kompatybilności z C, to z tego co pamiętam, to C++  jest rozszerzeniem języka C o programowanie obiektowe + kilka rzeczy zastępujących makra.

[Xirdus]

Co do kompatybilności z C, to z tego co pamiętam, to C++  jest rozszerzeniem języka C o programowanie obiektowe + kilka rzeczy zastępujących makra.

No właśnie o to mi chodzi. Stroustrup powinien się w 1979 mocniej odciąć od C.

[kapustman]

A co przez to rozumiesz? Chcesz aby C++ był czymś w rodzaju C#, gdzie kompatybilność z C to już tylko jest w nazwie?

[Xender]

KAŻDY język oprogramowania, który pozwoli zarobić pieniądze jest DOBRY. Jakiego uczulenia na Jave bym nie miał to i tak jej użyję jak będzie taka potrzeba.

Miłego COBOL-a.

Celem jest: niezawodnie*, zgodnie z oczekiwaniami i w budżecie. Testy kosztują znacznie więcej niż uruchomienie make/mvn/scons itp. A poza tym nie zapewniają pełnego pokrycia. Zatem dopisywanie testów do rzeczy które w trywialny sposób weryfikuje system typów to strata czasu ergo pieniędzy.

To pisze się inne testy - czy mając przykładowe dane wejściowe, dane wyjściowe są OK, jak są obsługiwane przypadki brzegowe itp.

Statyczne typowanie też nie zapewnia pokrycia niektórych powshechnych błędów - bolączek C - segfaultów i buffer overflow wszelakiej maści.

Co do budżetu - znów się powtórzę - co z debugowalnością?
To mniej kwestia samego systemu typowania, bardziej całego środowiska: języki interpretowalne/bajtkodowe, z ładnym raportowaniem błędów (wyjątek z opisem i stacktracem) i bogatą introspekcją debuguje się przyjemnie. UI pdb też jest nawet miłe, w porównaniu do gdb.

Może jestem leniwy, ale wydaje mi się, że debugowanie Pythona jest tańsze (skoro już przliczamy wszystko na pieniądze ;_;), niż debugowanie C[++].

Co do heterogenicznych kontenerów w C++. Jeśli struktura jest znana dopiero w runtime to znaczy, że istnieje jakiś wspólny mianownik dla wszystkich typów którego można użyć (string + nullptr?). Więc C++ nic tu nie przeszkadza -- po prostu weryfikujesz pewne rzeczy w runtime.

Sugerujesz trzymanie wszystkiego jako stringi (czylie de facto odserializowanie tylko drzewa, a nie wartości) i odserializowywanie wartości przy każdym dostępie?

Robienie czegoś takiego w C++ zakrawa o masochizm. To jest po prostu przypadek, na którym statyczne typowanie łamie zęby i nie ma co się oszukiwać, że jest inaczej.

Stroustrup powinien się w 1979

Nawet nie zaczynaj retrospekcji. To do nikąd nie prowadzi.

A z innej beczki - wiecie, że jest skrypt do uczynienia tych niesławnych błędów templatkowych w C++ czytelniejszymi?
Jakby ktoś miał okazję się pobawić, dajcie próbkę wejścia i wyjścia błędu, bo jestem ciekawy, a nie za bardzo mam pod ręką co przezeń przepuścić.
https://duckduckgo.com/?q=gstlfilt.pl

[bies]

To jest po prostu przypadek, na którym statyczne typowanie łamie zęby i nie ma co się oszukiwać, że jest inaczej.

Ale komu/czemu łamie zęby? A serio to właśnie zniknąłeś np. wszystkie biblioteki do JSON-a dla JVM. Albo XPath/XML. Albo Boost Property Tree. Albo...

[Xender]

Ale komu/czemu łamie zęby? A serio to właśnie zniknąłeś np. wszystkie biblioteki do JSON-a dla JVM. Albo XPath/XML. Albo Boost Property Tree. Albo...

Sobie. Programiście. Albo...

Ok, przykładowe linijki z mojego Pythonowego skryptu, które przetwarzają dane z web API pewnego serwisu w JSON:

Kod: (Python) [Zaznacz]

data = r.json()  # JSON z odpowiedzi HTTP sparsowany do drzewa podstawowych Pythonowych struktur danych.
for post in data['posts']:
    filename = str(post['tim']) + post['ext']
    # Dalej robienie czegoś z filename
Napiszesz to krócej w którymkolwiek z przez siebie wymienionych.

[bies]

Xtend z istniejącą biblioteką org.json.*.

Kod: [Zaznacz]

var posts = data.optJSONArray("posts") ?: new JSONArray()
for (var i = 0; i < posts.length(); i++) {
    val filename = posts.getJSONObject(i).getString("tim") + posts.getJSONObject(i).getString("ext")
    // ...
}Gdyby org.json.JSONArray lepiej wpisywało się w Java Collections byłoby czytelniej.

W C++ z ładnie napisaną biblioteką mogłoby to wyglądać tak:

Kod: [Zaznacz]

for (auto &post : json::json(data)["posts"]) {
    auto filename = post["tim"] + post["ext"];
    // ...
}Pod spodem byłoby dużo konwersji i dynamicznego typowania ale taką bibliotekę powinno dać się napisać w C++11/14.