Autor Wątek: Technologie do przeglądarkówek  (Przeczytany 5517 razy)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +3
# Czerwiec 22, 2015, 01:37:51
Cytuj
Jakie masz doświadczenie w webówce, że uważasz, że języki statycznie kompilowane są tu praktycznym rozwiązaniem?
Powiedzmy że co nieco, acz nie za dużo tam porobiłem, tyle że w PHP. Wypowiadam się tutaj jednak o samym programowaniu w językach nietypowanych, gdzie na przykładzie Pythona miałem niefajne doświadczenia głównie przez iteration time powodowany koniecznością uruchomienia i odpowiedniego przetestowania kodu by wyłapać chociażby literówkę.

Cytuj
Bo z poprzednich dyskusji, w moich oczach masz dopisek "ten gość świetnie zna i porusza się w C++, ale przez to wpychałby go nawet tam, gdzie pasuje jak pięść do oka".
Nie twierdzę, że inne języki się nie nadają, jak je dobrze znasz. Jednak gdy poruszamy się w obrębie języków imperatywnych, to na dobrą sprawę większość "pasowania" to zasługa bibliotek, a nie samego języka. Podobnie jak odczucia pięścio-oczne. :)

Swoją drogą, jakbym ogarnął połączenie C++ z MySQL, bibliotekę do wide stringów i kolejną do parsowania wejścia CGI, to nie widzę dlaczego taki setup nie miałby np. być w stanie pociągnąć mojej strony domowej. Jedyny problem jaki tu widzę to wyłącznie to, że trzeba by właśnie te biblioteki ogarnąć.

Cytuj
Przypominam, że mówimy o tych przeglądarkówkach, które więcej mają wspólnego z typowymi webappkami, niż inne MMO.
To akurat aż tak wiele nie zmienia w wyborze języka. Jakbym miał coś takiego w tej chwili pisać, to pewnie wybór padłby na PHP i to z mało epickiego powodu - mam tego wsparcie na swoim hostingu, a do tego trochę w tym kodowałem. Ale weź kogoś ze znajomością Ruby, to ci napisze w Rubym. Kogoś kodującego w Javie, to napisze w Javie. I każdy z nich będzie myślał że jego język jest najlepszy bo po prostu.

Cytuj
Masz bardzo dużą szansę, tylko, że przeważnie zostanie to wykryte na etapie kompilacji.
Przeważnie, nie zawsze. Można się spierać lub czepiać za słówka, czy jest to "szansa bliska zeru".
I właśnie o to mi chodzi - statyczne typowanie niebagatelnie wspiera tutaj programistę. Chociaż przy refaktoryzacji ciężko mówić o "etapie kompilacji", bo u mnie najczęściej ten etap jest na samym początku (powiedzmy taki error-driven refactoring). :)

Cytuj
Prawo nieszczelnych abstrakcji* sugerowałoby, że będzie odwrotnie, i do utrzymania programu kompilowanego do JS może okazać się potrzebna dobra znajomość języka źródłowego, JS i dodatkowo build systemu.
Tutaj chłopaki od Emscripten odwalili kawał naprawdę dobrej roboty. Póki co jedyny problem: brak wsparcia wątków. Ale taka już specyfika asm.js.

Cytuj
I bum, segfault czy zdawkowy wyjątek zamiast stacktrace'a OOTB (porównując C++/Javę vs. Python).
E... że co? W przypadku C++ (i Javy pewnie też) powiedział bym raczej: bum, wywalenie do IDE z pokazanym konkretnym miejscem błędu i wartościami wszystkich zmiennych po najechaniu myszą. Out of the box. W dodatku w przy embedded ostatnio mnie zaskoczyło Atmel Studio, bo zrobiło dokładnie powyższe to samo przy cross-compile na AVR. :)

Cytuj
* (zapisują w czymś przyjemniejszym, niż odpowiednik natywnego coredumpa)
Akurat core dump który można łatwo wczytać i zdebugować w przypadku błędu u testera/klienta to najlepsze rozwiązanie.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Xender

  • Użytkownik

  • +1
# Czerwiec 22, 2015, 02:47:49
Powiedzmy że co nieco, acz nie za dużo tam porobiłem, tyle że w PHP. Wypowiadam się tutaj jednak o samym programowaniu w językach nietypowanych, gdzie na przykładzie Pythona miałem niefajne doświadczenia głównie przez iteration time powodowany koniecznością uruchomienia i odpowiedniego przetestowania kodu by wyłapać chociażby literówkę.
Wolę określenie "dynamicznie typowane". To, że typ jest przypisany do wartości, a nie do indentyfikatora, nie znaczy, że go nie ma.

Na niektóre literówki to mógłby pomóc linter.
Mam nadzieję, że nie porównujesz pisania w C++ w wypasionym IDE do z pisaniem w Pythonie w edytorze tekstu bez kontekstowych wspomagaczy.
Chociaż ja wspomagaczy mało używam. False-positive bywają drażniące.

Co do czasu iteracji, to skoro mówimy o webówce, to większość Pythonowych frameworków w trybie debug ma 2 opcje, które pozwalają go drastycznie skrócić:

- Niezłapany wyjątek pokaże stacktrace na stronie, do której próbowaliśmy się dostać.
Nie ubija to serwera ani frameworku, strona chodzi dalej.
We Flasku jeszcze na każdej ramce stosu można odpalić REPL Pythona (debugger wbudowany w Werkzeug).

- Automatyczne przeładowywanie plików modułów przy zapisie pliku.
Aczkolwiek we Flaskowym reloaderze niezłapany wyjątek w tym momencie (np. SyntaxError) wycrashuje całą aplikację, to można by chyba poprawić w reloaderze i to małym nakładem pracy...

Dwa dodać dwa i z czasem iteracji można nieźle zejść.

Nie twierdzę, że inne języki się nie nadają, jak je dobrze znasz. Jednak gdy poruszamy się w obrębie języków imperatywnych, to na dobrą sprawę większość "pasowania" to zasługa bibliotek, a nie samego języka. Podobnie jak odczucia pięścio-oczne. :)
A IMO istnienie takich bibliotek jest po części zasługą mechanizmów języka, które ułatwiają i nadanie im wygodnego interfejsu, i implementację.

Swoją drogą, jakbym ogarnął połączenie C++ z MySQL, bibliotekę do wide stringów i kolejną do parsowania wejścia CGI, to nie widzę dlaczego taki setup nie miałby np. być w stanie pociągnąć mojej strony domowej. Jedyny problem jaki tu widzę to wyłącznie to, że trzeba by właśnie te biblioteki ogarnąć.
Webaplikacje w C z CGI to powstają już od bardzo dawna, nie ma powodu, żeby to nie działało.
Pytanie, na ile byłoby wygodne.

Chcąc zobaczyć, czy takie coś istnieje, znalazłem ORM-a do C++ (i to nie jedynego).
Więc jakieś światełko w tunelu masz.

E... że co? W przypadku C++ (i Javy pewnie też) powiedział bym raczej: bum, wywalenie do IDE z pokazanym konkretnym miejscem błędu i wartościami wszystkich zmiennych po najechaniu myszą. Out of the box. W dodatku w przy embedded ostatnio mnie zaskoczyło Atmel Studio, bo zrobiło dokładnie powyższe to samo przy cross-compile na AVR. :)
O ile odpalasz spod IDE w trybie debug, na buildzie debugowym, to ok.
Za to jak błąd zacznie się ujawniać dopiero na wyższych poziomach optymalizacji, to robi się zabawniej.

Akurat core dump który można łatwo wczytać i zdebugować w przypadku błędu u testera/klienta to najlepsze rozwiązanie.
Też fakt.
Dobra, wycofuję argument, ten był rzeczywiście bez sensu.
« Ostatnia zmiana: Czerwiec 22, 2015, 02:49:42 wysłana przez Xender »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 22, 2015, 03:08:19
Cytuj
Mam nadzieję, że nie porównujesz pisania w C++ w wypasionym IDE do z pisaniem w Pythonie w edytorze tekstu bez kontekstowych wspomagaczy.
Ani trochę. Wspomagacze do Pythona to już nawet do Visual Studio można dostać. :)

Cytuj
Co do czasu iteracji, to skoro mówimy o webówce, to większość Pythonowych frameworków w trybie debug ma 2 opcje, które pozwalają go drastycznie skrócić:
Problem z Pythonem i iteracjami z tego co zauważyłem polega na tym, że żeby faktycznie coś sprawdzić, trzeba dany fragment kodu uruchomić. Nie żeby w innych językach nie trzeba było, ale w Pythone trzeba to robić z każdym błędem z literówką włącznie. Po pewnym czasie robi to się nieco irytujące.

Cytuj
A IMO istnienie takich bibliotek jest po części zasługą mechanizmów języka, które ułatwiają i nadanie im wygodnego interfejsu, i implementację.
Ja bym powiedział raczej, że zasługa przyzwyczajenia ludzi do danego kontekstu. Poza tym najczęściej to też nie kwestia istnienia, tylko popularności, bo do mainstreamowych języków można znaleźć chyba prawie wszystko.

Cytuj
O ile odpalasz spod IDE w trybie debug, na buildzie debugowym, to ok.
Za to jak błąd zacznie się ujawniać dopiero na wyższych poziomach optymalizacji, to robi się zabawniej.
W trakcie refaktoryzacji to zazwyczaj będzie odpalane w trybie debug. Trafić na coś, co sypie się dopiero po optymalizacji póki co zdarzało mi się niezmiernie rzadko i to często na skutek błędu samego kompilatora (wtedy bez schodzenia do asma i tak nie poradzisz).

Offline Paweł

  • Użytkownik

# Czerwiec 22, 2015, 09:11:18
Krzysiek: zamiast cgi weź fast cgi, i użyj biblioteki np. fastcgi++. Nie jest może najwyższych lotów ale dokumentację ma dobrą. Do tego coś do baz danych. Uruchamianie kodu po to by wyłapać literówki to jakiś absurd. Również zostałbym przy c++.

Offline lukiz1

  • Użytkownik

  • +3
# Czerwiec 22, 2015, 09:35:01
W tych grach, które już istnieją, jest spora szansa, że siedzi PHP.
I jest to przeżytek, ale po co przepisywać coś, co działa wystarczająco dobrze.
Tudzież Pythona czy Ruby.
Albo jakieś node.js, aczkolwiek JS choć nie jest tak skopany jak PHP, to swoje dziwnostki ma.
Co masz na myśli?
Mogę sobie wyobrazić, że ustrzegą od błędów jak pozostawienie gdzieś starej nazwy funkcji czy niezgodność typu zwracanego.
Od błędów logicznych przy jakiejkolwiek edycji kodu język nie ma jak ustrzec, jaki by nie był.
Więc co rozumiesz przez "refaktoryzacja praktycznie nie generuje błędów"?

Xender, ale się nie zgodzę z tobą. PHP nie jest przeżytkiem. I jeśli jest dobry programista to śmiga i refatoryzacja jest dobra.
Wkurza mnie, jak ktoś zwala wszystko na język programowania. Według mnie to tylko świadczy negatywnie o programiście.
W php jest ten problem, że bardzo dużo zależy od programisty i na niego spada całą odpowiedzialność w programowaniu. Php zmienia się co wersje, na lepsze. Prawda, że php nie posiada silnej typizacji, ale ją rozpoznaje. Wiec walidacja typu należy do obowiązków programisty. Tak jak i wiele innych.
Naprawdę nie wiem czy te negatywne komentarze, a czasami złośliwe na php to jest wynik nie wiedzy, braku doświadczenia cz lenistwa i strachu przejęcia odpowiedzialności za kod.

Co do pythona mam znajomych którzy w tym programują. Owszem chwalą ten język ale tylko do małych skryptów. Przy większych projektach, według nich robi się nie znośny. No i ponoć nie jest mistrzem prędkości. Ale jak każdy skryptowy język jest wolniejszy.


Siema, w czym się dziś robi gry a'la plemiona czy coś takiego?
Po stronie serwera siedzi jeszzce php? czy już to raczej przeżytek?
po stronie klienta js? node.js?
oreintuje się ktośjak to wygląda?

node.js nie siedzi po stronie klienta tylko serwera i robi jako serwer.
Trochę teorii poczytaj, bo to podstawa.

Moja propozycja. html 5, jquery/ js, ajax, po stronie serwera php albo js jeśli użyjesz node.js
Moja propozycja taka bo się tym zajmuje i jest to dla mnie wygodne  i skuteczne.

Oczywiście możesz jave lub c++ w którym na pewno wydajniejsze zrobisz (o ile jesteś dobrym programistą)

Albo jakieś node.js, aczkolwiek JS choć nie jest tak skopany jak PHP, to swoje dziwnostki ma.

Xender opowiedz mi o tym? jakie dziwnowski? i jak jest skopany php. przykłady ? Jakie masz doświadczenie js i php?
1. js i php są językami skryptowymi.
2. js jest jedno wątkowy, przez co trzeba umieć w nim programować lub stosować dodatkowe techniki.
3. php i js używają interpretera nie kompilatora

Uważam, że najpierw trzeba zrozumieć dany język i technologię a potem komentować.
« Ostatnia zmiana: Czerwiec 22, 2015, 09:40:20 wysłana przez lukiz1 »

Offline 10log

  • Użytkownik

  • +1
# Czerwiec 22, 2015, 10:14:43
@lukiz1 ja bym się nie wczuwał w dyskusję ;). Na tym forum panuje opinia, że php to zło w najczystszej postaci :D. Chłopaki ciągle chyba myślą, że używa się switch, case i include, żeby załadować nowy widok a jedyny słuszny argument to "dynamiczne typowanie".

Co do tematu gorąco polecam http://haxe.org/. Język obiektowy, statycznie typowany, kompilowalny do innych języków takich jak c++, java, c#, AS3, JS, Python i o zgrozo PHP.
Użyteczny po stronie serwera jak i klienta. Po stronie klienta polecam dodatkowo http://www.openfl.org/ i http://haxeflixel.com/. Jak kogoś razi Flash to zmienia output na html5 i cały Open FL i HaxeFlixel leci przez JS.
Jakby było potrzebne 3d to jest Away3D dla Open FL https://github.com/away3d/away3d-core-openfl

Offline lukiz1

  • Użytkownik

# Czerwiec 22, 2015, 10:31:12
@lukiz1 ja bym się nie wczuwał w dyskusję ;). Na tym forum panuje opinia, że php to zło w najczystszej postaci :D. Chłopaki ciągle chyba myślą, że używa się switch, case i include, żeby załadować nowy widok a jedyny słuszny argument to "dynamiczne typowanie".


Chyba, masz rację, że nie warto. Ale wkurza mnie jak ktoś rozsiewa takie opinie nie mając pojęcia.
A tak w ogóle skoro Xender  nie lubisz tak php. To jak myślisz, warsztat na czym jest zrobiony? Chyba nie powinno ciebie tu być skoro tak nie lubisz php.


Co do tematu gorąco polecam http://haxe.org/.

Myślę, że może być ciekawym rozwiązaniem. Sam w wolnej chwili przetestuje.

Offline lethern

  • Użytkownik

  • +2
# Czerwiec 22, 2015, 12:23:30
Naprawdę nie wiem czy te negatywne komentarze, a czasami złośliwe na php to jest wynik nie wiedzy, braku doświadczenia cz lenistwa i strachu przejęcia odpowiedzialności za kod.
Załóżmy że Ty wolisz, gdy posiadasz całą odpowiedzialność za kod, ale niektórzy wolą gdy część tej odpowiedzialności posiada język (że tak to ujmę)
Coś podobnego mamy przy porównaniu języka wysokiego poziomu i niskiego poziomu - w wysokim poziomie nie odpowiadasz za to, co i kiedy wpisujesz do rejestru, w przypadku niskiego poziomu odpowiadasz za wiele rzeczy, dlatego bardzo duży projekt to bardzo bardzo duża odpowiedzialność = milion bugów, milion bólów głowy i miliony godzin. Podobna sprawa z C/C++ vs C#/Java i choćby wskaźniki. Tam gdzie nie musisz dbać o wszystkie wskaźniki -> mniej bólu głowy, więcej produkcji.
W takim ujęciu mamy dużo odpowiedzialności -> źle
Na przykład dlatego można nie lubić PHP
(dodatek: to że ktoś "nie lubi Asemblera" nie oznacza, że asembler jest zły. Choć w przypadku PHP, czy jest złe czy nie jest, może być z innych powodów)

PS
Cytuj
A tak w ogóle skoro Xender  nie lubisz tak php. To jak myślisz, warsztat na czym jest zrobiony? Chyba nie powinno ciebie tu być skoro tak nie lubisz php.
?? Chyba nie przemyślałeś tego zdania... To czy ktoś lubi php czy nie, to przecież nie jest jakaś sekta, że ma się unikać stron mających coś z php wspólnego...
« Ostatnia zmiana: Czerwiec 22, 2015, 15:58:37 wysłana przez lethern »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 22, 2015, 14:35:58
Cytuj
Podobna sprawa z C/C++ vs C#/Java i choćby wskaźniki. Tam gdzie nie musisz dbać o wszystkie wskaźniki -> mniej bólu głowy, więcej produkcji.
Oj, to trochę akurat zależy. W C#/Javie masz takie same wskaźniki, tyle że pochowane i z nieco zautomatyzowanym usuwaniem. Niestety nie dość, że nie usuwa to wszystkich problemów (np. nadal możesz trafić na null pointer, czy zapomnieć wynullować jakiejś referencji i mieć w efekcie memory leak), to dokłada pewne swoje - przykładowo czystego RAII nie zastosujesz, bo odebrano Ci kontrolę nad usuwaniem obiektów. Słowem - niby pomaga, ale wymaga przestrzegania pewnych zasad. Podobnie jak przestrzeganie pewnych zasad może całkowicie uwolnić od bólu głowy związanego ze wskaźnikami w C++.

Offline Xender

  • Użytkownik

  • +1
# Czerwiec 22, 2015, 17:05:17
@lukiz1: Przede wszystkim - typowanie to dość skomplikowana sprawa.

Nie mam nic przeciwko dynamicznemu typowaniu, moim ulubionym językiem jest Python, typowany przecież dynamicznie.

To, co IMO powoduje o wiele więcej problemów, niż ma korzyści, to słabe typowanie:
https://en.wikipedia.org/wiki/Strong_and_weak_typing#Implicit_type_conversions_and_.22type_punning.22
To ma PHP z jego porąbanymi operatorami porównania, to ma JS z dodawaniem tablic do obiektów, to ma Perl, gdzie stringi "" i "0" mają wartości logiczne fałszywe, a każdy inny string (np. "1", "a", "00") - prawdziwe.
Przy czym w Perlu nie ma tych skaz aż tak dużo, jak w JS, jak w PHP.

Jeśli nie jest to dla Ciebie oczywiste, to teoretycznie można mieć te dziwnostki (słabe typowanie AKA "type punning" AKA "stringly typed" (typowanie poprzez metaforyczne konwersje czego popadnie na stringi przy różnych operacjach)) również w językach typowanych statycznie (w czasie kompilacji).
Niestety żadnego statycznie typowanego języka który jednocześnie miałby takie dziwnostki nie znam, więc nie posłużę przykładem.


Nie lubię PHP.
Nie lubię HTML - IMO ponowne pisanie nazwy tagu przy zamykaniu go to tylko strata miejsca, a implicite konwersja dowolnych ciągów znaków białych na jedną spację powoduje takie problemy jak wstawianie spacji w przypadkowych miejscach, jeśli chce się mieć ładnie sformatowany kod, lub niemożność łatwego wstawienia kilku spacji pod rząd.

Żeby nie być hipokrytą, nie piszę w PHP, a tam, gdzie to wygodne, zamiast pisać HTML samemu mogę próbować zastosować jakiś preprocesor, jak HAML.
Gdybym prowadził bloga, pewnie postawiłbym go na skrypcie napisanym w Django lub Flasku.

Natomiast nie mam najmniejszego problemu z pisaniem na forach napisanych w PHP, czytaniem blogów na Wordpressie ani używaniem WWW w ogóle (bo przecież tam jest HTML).
Czemu wg. Ciebie powinienem mieć z tym problem?

I niech Ci się nie wydaje, że to, że używamy forum napisanego w PHP świadczy o wspaniałości PHP-a.
Świadczy to tylko o jego popularności. Muzyki pop też raczej nie słucham, a przecież jest popularna.
Poszukaj sobie silników forów w Railsach, Node.js, Django czy Flasku (to znalazłem tylko jeden, FlaskBB).
Więc ani ten PHP taki świetny, ani niezastąpiony.
Żadne tam "zło konieczne", skoro jest niekonieczne.

Xender opowiedz mi o tym? jakie dziwnowski? i jak jest skopany php. przykłady ? Jakie masz doświadczenie js i php?
[...]
Uważam, że najpierw trzeba zrozumieć dany język i technologię a potem komentować.
W PHP - kilka lat lat temu próbowałem zrobić małą webappkę.
Posmakowałem:
- Bezużytecznych operatorów porównania: skoro zamiast '==' należy używać '===', to czego używać zamiast '<'?
- Funkcji od MySQL, którym można przekazać handle do połączenia, ale nie trzeba, bo jeśli się nie poda, to domyślnie użyją ostatnio używanego (WTF!?) połączenia.
- Sprawdzania, która funkcja z rodziny mysql_*_escape_string to ta właściwa, która uchroni przez SQL-Injection.
I tak można by wyliczać i wyliczać.

Dobry język programowania nie pozwala na sytuację, gdy dopiero gruntowne przeczytanie i zrozumienie manuala pozwala napisać aplikację w miarę solidnie, ale nieprzeczytanie manuala skończy się stworzeniem czegoś zabugowanego i dziurawego jak ser.

Proszę, oto przykłady:
http://phpsadness.com/ - Przykłady dziwadełek z wyjaśnieniami autora, czemu dane zachowanie jest wg. niego problematyczne.
http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ - Rant o tym, dlaczego PHP roi się od złych decyzji projektowych (lub ich braku) na wielu poziomach abstrakcji.
https://www.reddit.com/r/lolphp - Tu już loża szyderców, aczkolwiek nadal można znaleźć argumentację, czemu z niektórych rzeczy się wyśmiewają.

Tu dziwnostki JS:
https://bonsaiden.github.io/JavaScript-Garden/
Moje doświadczenie z JS - też proste, drobne aplikacje po stronie klienta, jakieś userscripty...

Żeby nie było, Python też ma swoje dziwnostki:
http://excess.org/article/2011/12/unfortunate-python/
Przy czym jedyna poważna wydaje mi się ta z hasattr połykającym wszystkie wyjątki, nawet KeyboardInterrupt.
Została naprawiona w Pythonie 3:
http://excess.org/article/2011/12/unfortunate-python/#hasattr

W ogóle większość błędów projektowych Pythona 2 (a żaden z nich IMHO nie był tak poważny, jak w JS, jak i w żaden z JS nie był tak poważny, jak te z PHP) zostało naprawionych w Pythonie 3.
A jak z PHP-em? Dzikie operatory == i < nadal grasują po okolicy?

Jeszcze jedna dziwnostka Pythona ma podłoże historyczne: chodzi o typy bytes i unicode i jak ma się do tego str.
W 2 str to bytes (skaza historyczna).
W 3 str to unicode (naprawione).
To powoduje czasem problemy przy pisaniu bibliotek, które mają chodzić pod 2 i 3.
Takie utrudnienia to cena za naprawianie błędów projektowych.

Dlatego twierdzę, że PHP-a nie da się naprawić - zbyt dużo starego kodu by się rozleciało, gdyby chcieć naprawić co poważniejsze problemy.
Trzeba by drastycznie zerwać kompatybilność wsteczną, a wtedy byłby to po prostu inny język.
« Ostatnia zmiana: Czerwiec 22, 2015, 17:07:44 wysłana przez Xender »

Offline Karol

  • Użytkownik

# Czerwiec 22, 2015, 17:26:43
Xender, Ty to chyba masz w notatniku to wszystko zapisane i gotowe do wklejania, prawda? Bo nie wierzę, że za każdym razem chce Ci się tak produkować w walce z wiatrakami? :D Zamiast zająć się czymś produktywnym to jakąś krucjatę prowadzisz ;).

Trzeba by drastycznie zerwać kompatybilność wsteczną, a wtedy byłby to po prostu inny język.
Hmm...
Ja to tu tylko zostawię - http://hacklang.org/
Jest wstecznie kompatybilny i wydaje się załatwia większość problemów PHP.

Offline Kos

  • Użytkownik
    • kos.gd

# Czerwiec 22, 2015, 17:28:29
Powiedzmy że co nieco, acz nie za dużo tam porobiłem, tyle że w PHP. Wypowiadam się tutaj jednak o samym programowaniu w językach nietypowanych, gdzie na przykładzie Pythona miałem niefajne doświadczenia głównie przez iteration time powodowany koniecznością uruchomienia i odpowiedniego przetestowania kodu by wyłapać chociażby literówkę.
Powaga? Ja własnie lubię Pythona za czas iteracji. Nie ma problemu z kompilacją, więc mogę sobie odpalać jakiś podzbiór unit testów automatycznie przy każdym save edytora.
Żeby nie było, w Go jest ten sam komfort, bo kompilacja jest na tyle szybka, że jej nie czuć.

(kiedyś nawet skracałem sobie czas iteracji przeładowując w locie moduły w chodzącej apce z GUI, ale dawno i nieprawda - nie polecam, więcej zachodu niż uzysku)

Edyta: no dobra, może nie tyle "lubię konkretnie Pythona za czas iteracji", co raczej: "nie lubię C i C++ przez czas iteracji", tu głównie użeranie się z brakiem modułów i ogólnie liche toole. Ale w takim Go czy C# już jest dużo lepiej. A Pythona używam dużo bo po prostu mi się w nim szybko produkuje fajne rzeczy.
« Ostatnia zmiana: Czerwiec 22, 2015, 17:35:41 wysłana przez Kos »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 22, 2015, 17:36:40
Cytuj
Nie ma problemu z kompilacją, więc mogę sobie odpalać jakiś podzbiór unit testów automatycznie przy każdym save edytora.
O ile masz unit testy. Nie będę raczej pisał unit testów exportera modeli z Blendera w Pythonie, bo mi to zajmie więcej niż sam eksporter. :)

Cytuj
Żeby nie było, w Go jest ten sam komfort, bo kompilacja jest na tyle szybka, że jej nie czuć.
Podobnież ja nie czuję kompilacji w przypadku C++.

Offline Kos

  • Użytkownik
    • kos.gd

# Czerwiec 22, 2015, 17:41:30
@Xender:

Co do czasu iteracji, to skoro mówimy o webówce, to większość Pythonowych frameworków w trybie debug ma 2 opcje, które pozwalają go drastycznie skrócić:

- Niezłapany wyjątek pokaże stacktrace na stronie, do której próbowaliśmy się dostać.
Nie ubija to serwera ani frameworku, strona chodzi dalej.
We Flasku jeszcze na każdej ramce stosu można odpalić REPL Pythona (debugger wbudowany w Werkzeug).

W Django ofc też.

Ale takie smaczki są nie tylko w interpretowanych: kopara mi opadła gdy zobaczyłem jak dobrze działa Gin, taki reloader do Go. W zasadzie dostajesz taki sam experience jak przy djangowym runserver, tylko implementacja odpowiednio inna: gin chodzi jako proxy, na requeście przekompilowuje projekt (jeśli potrzeba) i restartuje serwer, a jeśli masz błąd kompilacji, to wyświetla go w przeglądarce.

Offline Xender

  • Użytkownik

  • +1
# Czerwiec 22, 2015, 18:33:24
Xender, Ty to chyba masz w notatniku to wszystko zapisane i gotowe do wklejania, prawda? Bo nie wierzę, że za każdym razem chce Ci się tak produkować w walce z wiatrakami? :D Zamiast zająć się czymś produktywnym to jakąś krucjatę prowadzisz ;).
Ha, żadnej copy-pasty, posty 100% handmade. ;)

Hmm... [Hack] jest wstecznie kompatybilny i wydaje się załatwia większość problemów PHP.
To, że się kompiluje do PHP, czy do VM, którego Facebook używa do PHP, nie znaczy, że jest wstecznie kompatybilny.
Może być kompatybilny za poziomie API z PHP, to nadal nie jest wsteczna kompatybilność.

Wsteczna kompatybilność jest wtedy, kiedy nowy kod możesz odpalić pod starym interpreterem i będzie działał, jak powinien.

(kiedyś nawet skracałem sobie czas iteracji przeładowując w locie moduły w chodzącej apce z GUI, ale dawno i nieprawda - nie polecam, więcej zachodu niż uzysku)
Tak, można się naciąć na obiekty ze starych wersji modułu nadal żyjące w programie.
Choć wydaje mi się, że w webówce można mocno ograniczyć globalny stan, bardziej, niż w GUI.

Podobnież ja nie czuję kompilacji w przypadku C++.
Czyli, że nie używasz Boosta?