Luke J. Li

Zmieniło się trochę. W skrócie: Silnika gier już nie robię, bo pobawiłem się w międzyczasie Unreal Engine 4 i doszedłem do wniosku, że po co robić coś co będzie i tak słabsze od UE4? (tudzież od Unity i podobnych rzeczy). Owszem, mógłbym zrobić coś lepszego od Phasera, Kiwi czy innych webowych silników, ale jednak powiedzmy sobie szczerze - webówka to jest przedszkole. Te wszystkie nasze frameworki webowe to takie zabawki. Prawdziwe rzeczy jeśli chodzi o silniki gier/edytory robi się na desktopie (przy czym teraz się to wszystko miesza - UE4 ma opcję eksportu do HTML5, Unity chyba też). Za to robię to, co planowałem już od dwóch lat, czyli własne IDE do JavaScriptu . Zrobiłem już kilka wersji, przepisywałem od nowa, teraz wreszcie doszedłem do jakiejś tam stabilności, i niedługo wypuszczam to w kosmos. To znaczy w internet. Na tym poziomie nie będzie to raczej IDE, ale edytor, w stylu Atoma czy VSCode. Natomiast będę szedł tym w stronę IDE (prawdopodobnie bardziej inteligentn...

Po raz kolejny czytam, że ktoś uważa jakoby klasy w ES6 były jakąś super zmianą, która z JavaScriptu czyniła w pełni obiektowy język. This is wrong on some many levels... JavaScript był obiektowy już dawno . Może nie w pełni obiektowy i dalej nie jest w pełni obiektowy w takim stopniu jak Python (choćby dlatego, że w JS liczby nie są prawdziwymi obiektami tak do końca - w Pythonie są), jednak jest obiektowy enough, prawie wszystko jest obiektem (łącznie z funkcjami - w wielu niby to obiektowych językach funkcja nie jest obiektem), można stosować polimorfizm, kompozycję, dziedziczenie, enkapsulację danych (przez domknięcia). Owszem, klasy są pewną formalizacją patternów, które użytkownicy już dawno stosowali. Jeśli ktoś stosował składnię typu: function Foo() {... } Foo.prototype.meth = function () { }; to pewnie się ucieszy, że używając klas składnia jest prostsza. Klasy ukrócą również partyzantkę, że każdy framework tworzy własną implementację pseudoklas (React.cr...