Facebook uwalnia silnik Presto

Facebook uwalnia silnik Presto

    przez -
    69 833
    Facebook
    Facebook ogłosił uwolnienie silnika Presto, który jest rozproszonym silnikiem zapytań SQL. Został zbudowany na potrzeby portalu Facebook, aby móc obsługiwać bazy danych o rozmiarach ponad 300 petabajtów. Oczywiście do tej pory istniały klastry Hadoop, aczkolwiek Hive i inne narzędzia nie były w stanie zapewnić bardzo niskich wyników zapytań, jakich potrzebowała firma. Całość została napisana w Javie, aby zapewnić szybki rozwój oraz łatwą integrację z obecną infrastrukturą.

    Pojedyncze zapytanie do Presto potrafi zebrać dane z wielu źródeł, pozwalając na szybką analizę całej organizacji. Presto wspiera wiele backendów, posiada 10 razy lepszą wydajności, niż Hive/MapReduce oraz obsługuje większość zapytań standardu ANSI SQL.

    • garrappachc1992

      Java i Presto to prawie jak oksymoron ;)

      • Java jest bardzo wydajna. To, że się długo uruchamia to nie znaczy, że operacje wykonywane w trakcie programu są powolniejsze.

      • o_O

        Java jest straszliwie powolna. Zarówno podczas uruchamiania jak i potem w działaniu.
        Od Javy gorszy jest tylko .net – tak samo powolny, a do tego windows-only.

      • Nie martw się Mono ma AOT.
        A C++ śmierdzi na urządzeniach osadzonych jak tylko zacznie się używać virtual.

      • Kaleson

        To że ci się Minecraft tnie nie znaczy że jest powolna, whateva…

      • o_O

        Nie gram w minecrafta, więc nie wiem czemu uroiło ci się, że ma się MI ciąć.
        Ale się tnie. I to właśnie znaczy, że Java jest powolna. Kolejny przykład na to.

        Java jest do dupy jeśli chodzi o czas startu, GUI, obliczenia (zarówno HPC jak i grafikę na GPU), bezsensowne zużycie RAMu.
        Praktycznie do niczego się nie nadaje. Do dużych rozwiązań działa za wolno i jest zbyt zasobożerna. Nadawałaby się do małych konsolowych programików, ale startuje za wolno.

        Java to tragiczna pomyłka ewolucji.
        Dobre było w niej wyłącznie to, że była przenośna. To było genialne rozwiązanie.
        Dzisiaj mamy standardy C++ i przenośnie biblioteki. Piszesz raz i kompilujesz na różne platformy. Jedyny problem, jaki rozwiązywała Java, zniknął.
        I C++ jest szybki i wydajny. W przeciwieństwie do Javy.
        Teraz Java powinna zwyczajnie umrzeć, ale jacyś idioci nadal reanimują to zombie i krzyczą, że jest najlepsze.

        Od Javy gorszy jest tylko .net, który posiada wszystkie jej wady, a nie ma nawet zalety przenośności. Ale jak już pisałem, przenośność jako zaleta Javy też się skończyła.

      • javauberalles

        Przyznaj, że boli cie to, że rynek pracy dla programistów javy i .net jest większy i bardziej opłacalny. Jako komuś kto poza c++ niewiele potrafi masz zwykły ból dupy i tyle.

      • o_O

        Tak, ludzka głupota bardzo mnie boli, to prawda.

      • o_O

        A pracy dla programistów C++ jest wystarczająco dużo, do tego dobrze płatnej. W przeciwieństwie do klepania w Javie, gdzie najczęściej sadzają małpy przed kompem i płacą w bananach na godzinę.
        Zaświadczam ci, że "bólu dupy" z tego powodu nie mam w najmniejszym stopniu.

      • Starbit

        Java to język programowania nie może być ani wolna ani szybka. Można się czepiać standardowej implementacji czyli JVM, ale to że zjada dużo ramu to nie znaczy że jest wolna i mało wydajna.

        Podsumowując twoja wiedza na temat jest porównywalna z wiedzą statystycznego gracza w Minecrafta, polecam zagrać wygląda na to że dobrze dogadywałbyś się z tamtejszą gimbazą.

      • o_O

        Nie odwracaj kota ogonem. Dobrze wiesz, że "napisane w Javie" praktycznie zawsze znaczy, że zostanie skompilowane do bajtkodu i odpalane na JVM, a "napisane w C++" nie będzie interpretowane za pomocą jakiś wynalazków tylu Ch czy CINT, tylko zostanie skomilowane do natywnej binarki. Nie udawaj debila.

        Oracle/Open JVM ZARÓWNO zjada dużo RAMu jak RÓWNIEŻ jest powolne i mało wydajne. Nie użyłem implikacji tylko koniunkcji, więc czytaj ze zrozumieniem.

        Podsumowując, nie umiesz czytać ze zrozumieniem, pisać na temat, a obrazu dopełniają marne wrzuty o gimnazjalistach. Tragedia.

      • MikolajS

        To napisz taki silnik w C++ i zobaczymy czy będzie równie szybki.
        A co powiesz w takim razie o szybkości języków skryptowych skoro Java jest dla Ciebie za wolna?

      • o_O

        Ależ takie silniki już istnieją: idTech, Unreal, CryEngine, Unigine, …
        Żaden z nich nie został napisany w Javie.
        Zgadnij dlaczego?

      • pijaczek

        MikolajS mówił o takim o jakim mowa, a nie silnikach gier z nieporównywalnym budżetem. Jednak te przytoczone jak dobrze wiesz mają tylko ścisłe wnętrze pisane w C++ przez core team, a nad grami pracują już script coderzy, bo udostępnienie języka C++ (zamiast skryptów pluginy), programistą o nieznanych kompetencjach to zły pomysł.
        W wypadku jednak Presto o którym mowa, to jest to zwykły klient bazodanowy, który dłużej czeka na odpowiedź bazy przez sieć niż pracuje lokalnie – wydajność w tym wypadku nie ma znaczenia. Ważniejsze było raczej to, że niektóre bazy NoSQL, które presto też obsługuje mają API udostępnione tylko dla Javy i nie ma wielkiego sensu pisać takiego silnika który tylko gada z bazami danych w C++, bo wydajność jest nieistotna, a pisanie pół w Javie, pół w C++ i męczenie się z mechanizmem JNI (jedyne wyjście, aby pogadać z Apache HBase czy Apache Hive z C++) to w tym wypadku byłoby głupotą.

      • o_O

        1) Pisane są w C++ dla wydajności. Nie ważne przez kogo i z jakim budżetem. Kropka.

        2) A więc Java obok wszystkich swoich wad jest do tego wirusowa! Banda matołów popisała kawałki kodu w Javie, powpychała wszędzie, a teraz: "napiszmy w Javie, bo przecież program/biblioteka/komponent X już Javy używa". Zupełnie jak ekosystem microsoftu, tylko tu to bagno stworzyła społeczność Javy. Dziękujemy.

      • pijaczek

        1) Najważniejsze aspekty są pisane w C++ dla wydajności, ale przy niskim budżecie prawdopodobnie nic z tego by nie było (niski budżet to słabi programiści i silnik na każdym kroku by się wywalał). Dlatego im niższy budżet tym częściej wybierana jest Java.

        2) C/C++ jak każdy inny język też tak samo zaraża. Chcąc użyć biblioteki C/C++ z Javy też musisz użyć JNI (no w wypadku relacyjnych baz danych jest przygotowany interface standardowy i to wykorzystano tu do rozmowy z bazami pisanymi w C/C++). Jeśli piszesz w języku skryptowym to do API C++ też musisz robić bindingi (ala JNI).
        To nic nadzwyczajnego… po prostu nie da się zlinkować kodu natywnego z bitcode, ani z językiem skryptowym.
        W C++ przy różnych formatach plików binarnych jest problem z linkowaniem (przykładowo kod wypluwany przez kompilator microsoftu jako biblioteka czasami jest nie do wykorzystania w programie kompilowanym w GCC). Podobnie nie możesz sobie wykorzystać api C/C++ w języku D, a musisz sobie pisać ręcznie interface biblioteki.
        Ogólnie zawsze z łączeniem języków jest problem i C/C++ nie są tu lepsze – jedynie co to mogłeś się przyzwyczaić, że zazwyczaj to programiści Javy i języków skryptowych mają problemy (bo interface to programów/bibliotek zazwyczaj jest w C (nie C++, bo tu byłyby problemy z innymi językami) i wykorzystanie w C++ to żaden problem), a programiści C++ nie (jednak to się zmienia i w Androidzie mimo NDK z C++ nie masz możliwości dostania się do większości API – musisz robić JNI), z WinForms czy ModernUI (Windows Phone/RT/8) masz dostęp jedynie z API C#, a w MacOS/iOS do Cocoa masz dostęp jedynie z Objective C, inne mobilne systemy oparte o Linuksa które mają być zaprezentowane (łącznie z tymi opartymi na QML) mają API tylko z JavaScript.
        Tak już jest, że wybrany język przez twórce biblioteki zawsze utrudnia życie wszystkim którzy chcą jej użyć w innym języku.

      • Jest też boost::python i cython.
        W MetroUI są proste dynamiczne bindigi oparte na COM i listach API.
        W Linuksie jest GObject Introspection oparte na listach ABI dzięki którym można robić dynamiczne wywołania z większości języków.

        o_O nie przemyślał chyba swojej wypowiedzi w odniesieniu do QML i tego jak bardzo dziś się przydaje skryptowanie w aplikacjach. Nie wspominając o prototypowaniu.

      • pijaczek

        Nie do końca rozumiem co chciałeś powiedzieć przez boost::python i cython… tzn to, że z nimi można robić bindingi (jak w wypadku praktycznie każdego języka skryptowego), ale jest to porównywalnie denerwujące jak JNI

        Co do bindingów ModernUI to zapewne masz na myśli CLI (odpowiednik JNI), ale one nie są możliwe (w WinForms jeszcze były). Przy ModernUI to masz jedynie dostęp z poziomu C++/CX jednak nie jest to C++ i nie jest kompatybilny z nim (jest on rozszerzony i obsługiwany jedynie przez kompilator Microsoftu).

        Co do GObject Introspection to dynamiczność jest najgorszą z możliwych rzeczy przy API. W wypadku JNI też wszystko działa niestety dynamicznie w czasie runtime, a przez to kompilator nie wychwyci błędów i jest to upierdliwe do debuggowania. GObject Introspection to podobnie okropne rozwiązanie jak JNI.

        Wygląda to mniej więcej tak jak wykorzystywanie rozszerzeń w OpenGL (czyli odpytywania sterownika o posiadanie rozszerzenia i pobierania wskaźników na funkcje – jeśli się pomylisz i walniesz literówkę pobierając nic się nie zgłosi, a funkcja może być używana raz na 1000x testów – jak jednak trafisz to program się wywali i często jest problem z powtórzeniem sytuacji, aby debugger wychwycił w czym problem – trzeba wszystko sprawdzać bardzo uważnie) – dynamiczne pobieranie API to ZŁO w czystej postaci.

      • O ile niewygodę cythona mogę zrozumieć, to boost::python nie.

        Nie chodzi mi o C++/CX, które teraz się łączy z COM zamiast .net. Chodzi mi o to, że teraz zrobili tam listy obiektów COM do introspekcji. Z tego korzysta teraz ich JS i .NET.

        Z resztą zarzutów mogę się zgodzić, dlatego porzuciłem GTK. Python nie chciał mi zwracać nawet wyjątków tylko od razu segfaulty.

      • pijaczek

        Cythona akurat nie znam (tylko sprawdziłem jak działa na ich stronie), za to boost::python jak i Python/C API znam bardzo dobrze i to z obu stron (wywoływanie funkcji C++ z pythona i pythonowych funkcji z C++)… i wiesz co? Wolę już JNI.

        Co do COM to nie widzę nic nowego – zawsze .NET korzystał z tych "ponoć" niezależnych od języka plików (tzn zależnych od tego czy dla danego języka MS przygotował implementacje i udostępnił API), Co do "JS i .NET" to niepotrzebnie to rozwijałeś… .NET samo by wystarczyło JScript microsoftowy nie ma dostępu do obiektów COM (ma tylko wariant JScript .NET).
        Byłoby łatwiej gdybyś nazwał to co chcesz przekazać po imieniu jak przykładowo MIDL, COM Interop…

      • A nic, chodziło mi głównie o to, że w WinRT są pliki WinMD z opisem interfejsów dla łatwiejszego bindingowania COM w różnych językach. Z tego korzysta teraz .net i wariant JS dla Metro.
        Wcześniej .net starał się być sam dla siebie jak Java, a teraz bezpośrednio stara się korzystać z natywnych bibliotek przez COM jako swoich własnych interfejsów.
        http://arstechnica.com/features/2012/10/windows-8

      • pijaczek

        WinMD obsługują tylko implementacje Microsoftu. JS dla Metro to JScript for .NET – w żadnym innym nie możesz użyć tych plików, w C czy C++ też ich nie użyjesz – jedynie w niekompatybilnym z nimi C++/CX. Ogólnie nie jest to pomoc przy łatwiejszym bindowaniu w innych językach, a raczej przeszkoda w robieniu tego (możesz jedynie użyć namaszczonych przez Microsoft języków i tylko w ich implementacji).

      • o_O

        niski budżet to słabi programiści […] im niższy budżet tym częściej wybierana jest Java.

        Dziękuję za poparcie tego co cały czas mówię, że w Javie piszą marni klepacze kodu.

        Proszę tylko o ustosunkowanie się do tego:

        1) Koszty skopanej logiki są wielokrotnie wyższe niż tego, że ktoś źle jakąś klasę zaprojektował, bo można było przejrzyściej. Code monkeys to samobójstwo i potwarz dla jakości. Jeśli chcesz tym się chwalić przed klientem… "Mam kiepskich programistów, zrobią bubel, ale tanio!"

      • o_O

        Co do języków skryptowych, mają ogromną przewagę: kod można generować w czasie rzeczywistym i od razu nadaje się do wykonania. Na przykład kod JavaScript generowany z PHP. Albo kod PHP generowany przez jakiś inny program i podawany serwerowi www do wykonania.
        Nie potrzeba kompilacji. To ogromna zaleta. Wadą oczywiście jest narzut czasu interpretacji.

        Oczywiście każde rozwiązanie ma swój target.

        Poza Javą. Bo jaki zysk z czegoś co trzeba kompilować, a i tak jest wolne?
        Podaj mi jakiś przykład, gdzie Java jest technologicznie lepsza od innych rozwiązań.
        Skryptowa? Szybka? Oszczędza zasoby? Szybko się odpala? Nie wymaga kompilacji? Nie, nie, nie, nie, nie.
        Jedyna zaleta: przenośność bajtkodu. Ale to już przeszłość, dziś masz standardy C++ i przenośnie biblioteki. Dziś przenośność nie wymaga już atrapowych rozwiązań.
        Inna postulowana przez fandojów zaleta: składnia języka Java. Otóż C++ jest bardzo zbliżone jakościowojeśli chodzi o przejrzystość kodu i jego utrzymanie, a daje wielokrotnie szybsze binarki. Tylko trzeba umieć C++, a nie zatrudniać małpy za pół ceny, bo w Javie "nie da się napisać źle". Otóż się da, bo design to wierzchołek góry lodowej, najważniejsza jest logika, a ją słaby programista może skopać i w C++ i w Javie. A koszty skopanej logiki są wielokrotnie wyższe niż tego, że ktoś źle jakąś klasę zaprojektował, bo można było przejrzyściej.

      • Jon

        Java jest wolna. o_O pisze w asemblerze.

      • o_O

        Nie ma jak kretyński komentarz…
        Widząc twój tok rozumowania domyślam się, że gdy chcesz dostać się w jakieś miejsce to albo się czołgasz albo idziesz na rękach. Gratulacje.

      • Jon

        Asembler jest najlepszy, bo jest najszybszy. Co, nieprawda? Bije na głowę te wszystkie kretyńskie, wolne wynalazki.

      • o_O

        Owszem. Ale straszliwie się w nim pisze, a o utrzymywaniu takiego kodu trudno nawet mówić.

        C++ jest po prostu idealnym kompromisem. Wystarczająco szybkie po kompilacji, a jednocześnie bardzo przyjazne dla programisty.

        A Java? Troszkę przyjaźniejsza od C++ i to tylko dla tych, który po prostu nie rozumieją C++. I za jaką cenę? Straszliwej powolności, idiotycznego (na dzisiejsze warunki, kiedyś to był atut) bajtkodu, zjadaniu ton RAMu, wirtualnej maszyny, która nawet najbardziej wydajnie napisany kod zamieni w powolny bubel.

      • pijaczek

        W javie łatwiej i taniej się program rozwija (programista ma zrobić zadanie, a nie martwić się o wycieki pamięci). Implementacje Garbage Collection dla C++ (przykładowo Boehm GC który został włączony do GCC) są bardzo powolne (wolniejsze od Javy) właśnie ze względu na to, że nie zjada ton RAMu (Java i jej GC prealokuje przy starcie wielką ilość pamięci na raz, zamiast alokować wszystko osobno). OFC można zrobić dobry i szybki odpowiednik GC i zarządzać pamięcią w programie pamięcią przez zliczanie referencji wykorzystywanie mądrych wskaźników… jednak to więcej roboty bezsensownej dla programistów i muszą to robić lepsi programiści (drodzy, i nie tak łatwo dostępni, bo dobrego programistę nie jest tak łatwo znaleźć, a dodatkowo często niechętni do pracy w zadaniach które ich osobiście nie kręcą (po prostu dobry programista zazwyczaj jest wybrednym pracownikiem, bo zna swoją wartość)).

        Czasami łatwiej zainwestować w lepszy sprzęt niż większą ilość kasy zainwestować w lepszych programistów. Facebook to bardzo dobrze rozumie i woli zatrudniać masę tanich "code monkey" do PHP, ale kilku dobrych programistów do napisania tłumacza PHP do C++ i kod tworzony przez nisko wykwalifikowany personel przepuszczać przez HipHop for PHP, aby uzyskać wysokowydajny kod C++ skompilowany do natywnego kodu i uruchamiany przez FastCGI (dzięki temu działa to wydajnie, a programistów zajmujących się mało interesującymi rzeczami mają tanich).

      • o_O

        Wreszcie jakaś sensowna odpowiedź.

        Czyli Java to GC, tani niewykwalifikowani programiści i zasobożernośc rekompensowana mocniejszym sprzętem?

        Zarówno GC jak i "tani kod, droższy sprzęt" zdają się kręcić wokól tej trzeciej "zalety": tanich programistów.
        Bo nie muszą umieć użyć smart pointera (bardzo trudne), oraz są na tyle tani, że rekompesują koszty mocniejszego sprzętu koniecznego dla Javy.

        No to 2 uwagi:

        1) Koszty skopanej logiki są wielokrotnie wyższe niż tego, że ktoś źle jakąś klasę zaprojektował, bo można było przejrzyściej. Code monkeys to samobójstwo i potwarz dla jakości. Jeśli chcesz tym się chwalić przed klientem… "Mam kiepskich programistów, zrobią bubel, ale tanio!"

        2) Jeśli właściciel kodu i sprzętu jest jeden to OK – jego decyzja. Ale jeśli za tani kod płaci potem zewnętrzny użytkownik musząc kupować drogi sprzęt, żeby uciągnął te programy, to coś jest nie tak. To oznacza, że Java i .net nie nadają się absolutnie na desktop, a wyłącznie jako rozwiązania po stronie serwera. Kto pisze w Javie lub .net na desktop jest kanalią, która nie dba o swojego klienta i jakość dostarczonego mu oprogramowania, tak?

      • eridd

        Zdajesz sobie sprawę, że programista assemblera który zna go od lat może użyć podobnych argumentów do twoich i stwierdzić, że tylko małpa musi używać jakiegoś "kretyńskiego", "uproszczonego" C++ gdzie nie ma się "władzy nad kodem" i nie rozumie assemblera. Sam pisałem przez lata w assemblerze (teraz dalej piszę ale tylko do mikrokontrolerów) i pewnie to kwestia przyzwyczajenia, ale nie powiedziałbym, że piszę się tam straszliwie, a zarazem nie wmawiam nikomu, że assembler jest super, bo to nie ma sensu.
        To tak samo ze stwierdzeniem, że kod jest przyjazny dla programisty – to przecież czysto subiektywne odczucia, jeden będzie uważał, że C++ ma przejrzystą składnie, a inny stwierdzi, że COBOL jest lepszy – i kto będzie miał rację?

        Java jak Java – może nie jest demonem prędkości, ale istnieją testy wskazujące na to, że w niektórych zastosowaniach potrafi być szybsza od C++, ale tylko fani C++ muszą wciskać wszystkim kit, jak to Cpp jest wspaniałym językiem.

      • o_O

        Udajesz, czy na prawdę z tobą tak źle?

        W języku chodzi o poziom abstrakcji.
        W asemblerze nie ma go praktycznie wcale.
        W C++ i Javie ten poziom jest praktycznie identyczny, oparty na obiektowości.

        Im wyższy poziom abstrakcji, tym łatwiejsze utrzymanie kodu.
        Ale ta abstrakcja powoduje narzut w postaci nieoptymalnych binarek generowanych przez kompilator.
        W C++ znośnie nieoptymalnych, czasem nawet zbliżonych wydajnością do assemblera.
        W Javie nieakceptowanie nieoptymalnych, zarówno na poziomie czasu wykonania jak i zużycia pamięci, i nawet nie natywnych, tylko zapisanych nadmiarowym i zbędnym dzisiaj bajtkodem.

        Assembler to zupełnie inne narzędzie niż C++ i Java. C++ i Java są w tej samej lidze i Java sromotnie tu z C++ przegrywa.

      • eridd

        "Udajesz, czy na prawdę z tobą tak źle?"
        To z tobą jest źle i to bardzo źle. Ciągle powtarzasz regułki które pewnie mają już tyle lat ile C++. W czasach gdy jeszcze królował assembler zostałbyś zjechany pewnie od najgorszych i powiedziano by Ci, że te twoje poziomy abstrakcji może sobie włożyć gdzieś, bo przecież utrzymanie kodu assemblera jest też łatwe(eh pamiętam te opinie niby głupie ale coś w tym było), a zarówno mamy większą wydajność. Później wraz z rozwojem techniki i zanikaniem assemblera (a pamiętam jak śmiano się , że każdy amator może nauczyć się C więc co to za język) ludzie zaczęli sobie tłumaczyć dlaczego coś jest lepsze od drugiego, przy czym fanboje assemblera przeszli w ostateczności na C robią znowu taka samo abstrakcyjną propagandę jak poprzednio.

        Oczywiście to co piszę jest przegięciem w drugą stronę, i zdaje sobie sprawę, że pisanie sporego projektu w assemblerze to porywanie się z motyką na słońce, ale Ty również robisz to samo na siłę próbując pokazać jak to Java jest tragiczna. Zaczynam podejrzewać, że należysz również to tej ligi programistów którzy uważają, że Object Pascal to nie jest język programowania i C++ jest na 100% lepsze (chociaż mam nadzieję, że aż tak źle z Tobą nie jest).

        Zresztą to wszystko gdybanie i zakładanie, że piszemy idealny kod zarówno w C++ i Javie. Często jednak większość napiszę lepiej działający kod w takich językach jak Java, a w ostateczności nawet patrząc na narzut VM i tak okaże się, że dobrze napisany kod w Javie będzie działał lepiej niż średnio napisany w C++, ba większość klientów chcę aby "działało" i aby było robione szybko, a wtedy okazuję się, że jednak w Javie czas napisania/poprawienia jest zazwyczaj szybszy.
        PS: Nie uważam C++ za zły język, chociaż niektóre elementy mają swoje lata i przydałaby się jakaś nowa generacja – bo cóż technika poszła do przodu i to co było dobre 20 lat temu teraz jest upierdliwe.

      • o_O

        Chyba nic nie zrozumiałeś.

        Jeśli chodzi o abstrakcję, assembler to inna liga niż C++ i Java. Można używać asemblera, czemu nie. Ale jeśli do wyboru masz C+ i Javę, to nie ma większej różnicy jeśli chodzi o poziom abstrakcji, a jest ogromna jeśli chodzi o wydajność. Java po prostu do niczego się nie nadaje i nie ma żadnych zalet nad innymi rozwiązaniami, a tylko same wady.

        Co do taniości programowania w Javie, odpowiedz na moje pytania postawione już pod tym artykułem:

        1) Koszty skopanej logiki są wielokrotnie wyższe niż tego, że ktoś źle jakąś klasę zaprojektował, bo można było przejrzyściej. Code monkeys to samobójstwo i potwarz dla jakości. Jeśli chcesz tym się chwalić przed klientem… "Mam kiepskich programistów, zrobią bubel, ale tanio!"

        2) Jeśli właściciel kodu i sprzętu jest jeden to OK – jego decyzja. Ale jeśli za tani kod płaci potem zewnętrzny użytkownik musząc kupować drogi sprzęt, żeby uciągnął te programy, to coś jest nie tak. To oznacza, że Java i .net nie nadają się absolutnie na desktop, a wyłącznie jako rozwiązania po stronie serwera. Kto pisze w Javie lub .net na desktop jest kanalią, która nie dba o swojego klienta i jakość dostarczonego mu oprogramowania, tak?

      • Michał

        Poziom abstrakcji java i cpp jest podobna, ale to nie zmienia faktu, że w to java jest tańsza w utrzymaniu.

        Ciekawe to co piszesz, ale nie do końca uzasadniłeś wszystkie swoje tezy.
        – Dlaczego programista Javy = zły programista? A dlaczego programista cpp = dobry programista?
        – Dlaczego nigdzie nie bierzesz pod uwagę, że aby dobrze programować w cpp trzeba więcej poświęcić czasu niż aby dobrze programować w javie? (a co za tym idzie programista cpp = droższy programista)
        – Dlaczego niemożliwe jest napisanie dobrego programu w Javie (piszesz, że powstają same buble)? Natomiast dlaczego każdy program w cpp jest doskonały z definicji?
        – Dlaczego uważasz, że jeśli płaci się więcej za sprzęt (ew upgrade) to jest źle, a jeśli zapłaci się więcej za program w cpp to jest dobrze?
        – Dlaczego ludzie są zmuszeni do kupowania i używania złych i wolnych programów napisanych w javie? Java jest w jakimś stopniu wymuszana przez pewnych lobbystów? Chciałbym poznać Twoją opinię na ten temat.
        – Dlaczego uważasz, że we wszystkich dziedzinach szybkość wykonywania kodu i zużycie RAM jest najważniejsza?
        – Dlaczego uważasz, że czym język jest prostszy tym gorszy? (prostszy język = więcej rzeczy robionych jest automatycznie przez runtime – wystarczy spojrzeć na języki skryptowe, które działają na ogół jeszcze wolniej)

        Co do kwestii technicznych, to zupełna zgoda. Ja też wolałbym aby każdy mój program działał błyskawicznie, działał optymalnie pod względem zużycia cpu i ramu, posiadał wszystkie potrzebne funkcje i był łatwo rozszerzalny (nie interesuje mnie użyta technologia – może być to i sam asembler). Rzeczywistość jednak trochę odbiega odrobinę od wzniosłych i pięknych ideałów, bo jest jeszcze magiczny czynnik – pieniądz.

      • Chyba mało miałeś do czynienia z serwerami i technologiami, jakie się na nich wykorzystuje :)

      • vulpes

        … i pisze to osoba, która "distributed SQL query engine" tłumaczy jako "dystrybuowanym silnikiem zapytań" :/ come on! przecież każdy informatyk wie, że chodzi o "rozproszony", i dalej "low query latency" jako "bardzo niskich wyników zapytań", zamiast np. "niskich opóźnień dla zapytania"
        Czasem wolałbym czytać wiadomości w oryginale po angielsku, albo tłumaczenia maszynowe, niż wytwory pojawiające się na osworld.pl

      • je2u

        Brawa ! Zaraz ktoś pewnie "inteligentnie" zaznaczy – nie chcesz czytać – nie czytaj. Co jak co, rację przyznać trzeba !

      • o_O

        To także jest tragicznie powolne. Glassfish, Maven z jego wtyczkami, Java EE… masakrycznie wolne rozwiązania. Trzeba być idiotą, który nawet nie słyszał o zasadzie KISS, by tego używać. Gorszy jest tylko .net.

      • marcinsud

        o zasadzie KISS nie słyszeli też w KDE tak przy okazji

      • o_O

        Przykłady?

        KDE całkiem mocno trzyma się tej zasady jak na tak rozbudowane ŚRODOWISKO.
        I nie myl KDE z window managerem. Możesz porównać je z Gnome, Windows albo MacOS. Wtedy idealnie widać kto dąży do prostoty i niezależności rozwiązań.

      • marcinsud

        Większość programów wchodzących w skład środowiska KDE to przewymiarowane kobyły próbujące robić wszystko tylko nie to do czego zostały stworzone np. taki Amarok, digiKam czy Kdelive. Wyjątkiem od tej reguły jest K3B, ale pewnie dlatego, że jego rozwój jest luźno związany z KDE.

      • Starbit

        "KDE całkiem mocno trzyma się tej zasady"

        Lol, gdzie? Przykłady z samej plasmy:

        * widżety które można obracać ^^ – KISS,
        * kickoff czyli menu z windowsa – kiss,
        * activities, powielenie użyteczności "pulpitów" – kiss,
        * runner – oprócz uruchamiania programów w cholere innego spamu – kiss
        * pluginy plasmy – Unit Converter, Web history wtf? kiss

        Do tego z poza plasmy

        * Nepomuk – kiss
        * Akondai – kiss

      • pijaczek

        Starbit zastanawiam się po tym co napisałeś czy masz pojęcie czym jest reguła KISS.

        Wszystko co napisałeś w związku z plasmą nie ma z tą regułą nic wspólnego (poza tym, że piszesz bzdury jak "kickoff czyli menu z windowsa" – Kickoff był tworzony na długo przed wydaniem podobnego rozwiązania w Windowsie i w wielu dystrybucjach było to domyślne menu w KDE3 na długo przed wydaniem wersji 4 – prędzej mogłeś napisać "kickoff czyli menu które microsoft podpatrzyło")… a jeśli ma jak przykładowo obroty widgetów (jak i cała plasma) jest zrealizowana zgodnie z regułą KISS – budowa jest prosta i przemyślana, konfiguracja (łącznie z widgetem który postanowiłeś sobie obrócić) jest prosta i nie wymaga dodatkowych narzędzi (prosty składniowo plik tekstowy).

        Nepomuk, Akondai to akurat się zgadza trochę tą regułę łamią (ze względu na ilość danych i niską wydajność plików tekstowych) i stosują binarne pliki i bazy danych do przechowywania informacji (co jest na bakier z regułą KISS), ale mimo, to konfiguracja ich jest dalej rozwiązana wzorowo i zgodnie z regułą KISS.

        Gnome za to jest z regułą KISS sprzeczny od podstaw, bo wykorzystuje GConf zamiast łatwych, prostych, małych plików konfiguracyjnych w prostym formacie tekstowym.

      • Starbit

        dl;dr

        Możesz mi wmówić że jesteś kostką smalcu, ale nie wmówisz mi że ta kobylasta szkapa z poplątanymi zależnościami o imieniu KDE spełnia regułę KISS.

      • pijaczek

        Nie mam zamiaru nic wmawiać. Po prostu KDE bardzo poważnie traktuje tą regułę i to jest fakt. Problemem jedynie może być to, że nie wiesz czym jest reguła KISS i mylisz ją ze swoim wyobrażeniem o niej. Faktem jest, że prawie wszystkie dystrybucje, które regułę KISS szanują preferują KDE lub Xfce, a Gnome omijają z daleka (klasycznym wręcz przykładem dystrybucji szanującej KISS jest Slackware, który Gnome wyrzucił zupełnie już blisko dekadę temu). Gnome czy Unity (oba nawet nie słyszały o KISS) preferują za to te dystrybucje, które powstały na podstawie RedHat/Debian (ubuntu/fedora/suse/mageia…) i mają wspólne korzenie zaprzeczające KISS (już w tamtym wieku RedHat i Debian olali regułę KISS i osoby kontynułujący ich drogę dalej to robią).

      • Starbit

        A kto tu w ogóle wspominał o gnome, nie uważam żeby ani jedno ani drugie ani nawet xfce było zgodne z zasadą kiss. Zastanawiam się też jak bardzo libelarnie traktujesz tę zasadę, że uważasz kde za spełniające ją środowisko (KDE mogłoby zostać wywalone z repo Slackware tak samo jak gnome gdyby było tak samo kłopotliwe w aktualizacjach: http://forum.slackware.pl/viewtopic.php?f=8&t….

        Polecam zainstalowanie pakietu o wdzięcznej nazwie ratpoison, pomimo że jest to tylko menadżer okien i nie zajmie ci więcej miejsca niż kilka mega z zależnościami. Jeśli się postarasz używać go z kilkoma innymi programami, to zrozumiesz co to KISS.

        Jeżeli mówimy o tej samej zasadzie, w której trzymamy wszystko tak proste jak to się tylko da trzeba być kompletnym debilem żeby uznawać KDE i masę tych wszystkich udziwniaczy które zapewnia, zgodną z zasadą KISS.

      • pijaczek

        Ratpoison nie jest nawet o cal bliżej reguły KISS niż przykładowo KWin, jednak pokazuje jak bardzo się mylisz co do tej reguły – KISS to nie reguły nakazujące banalny prosty program napisany na kolanie bez żadnych możliwości i przemyślenia budowy, a właśnie odwrotnie – KISS to reguła wymyślona dla wielkich projektów, aby projektować ich architekturę prosto (nie myl ze sposobem działania programu od strony użytkownika, bo tu KISS nie ma zupełnie związku), programować przejrzyście i stosować pliki bez udziwnień, a edytowalne z poziomu edytora tekstowego i o prostej składni (bez udziwnień typu języki znaczników xml itp).
        Z KDE jedyne co z KISS się kłóci (i to tylko częściowo – tzn w sprawie zapisu danych) to Nepomuk, którego możesz sobie spokojnie wyłączyć i nie używać.

      • Starbit

        "prostej składni (bez udziwnień typu języki znaczników xml itp)"

        Czyli openbox wg. cb nie spełnia zasady KISS ale KDE tak – Bardzo pokrętne.

      • pijaczek

        Ofc, że OpenBox nie słucha reguły KISS i to nie tylko w tym miejscu i nikt z twórców Ci nie powie, że zasada KISS jest im bliska. Nie jest to w żadnym wypadku pokrętne, a jedynie nie rozumiesz reguły KISS (i przypisujesz ją programom, które wszystko co się da komplikują i są sprzeczne z regułą tylko dlatego, że są minimalistyczne od strony użytkowej (zupełnie niezwiązane z KISS, które jest związane z tworzeniem oprogramowania od strony programisty)).

      • Starbit

        Panie "Wielki Znafco" przeczytaj proszę poniższą definicję słownikową:

        "All design should be as simple as possible, but no simpler. […] This is not to say that features, even internal features, should be discarded in the name of simplicity. Indeed, the more elegant designs are usually the more simple ones. Simple also does not mean "quick and dirty." In fact, it often takes a lot of thought and work over multiple iterations to simplify. The payoff is software that is more maintainable and less error-prone. "

        Openbox, ratpoison jak najbardziej spełniają zasadę KISS jak i the unix way – nie ma w nich zbędnych dodatków, ani graficznych konfiguratorów (domyślnie), są odpowiedzialne tylko za jedną czynność i wykonują tą czynność dobrze. Trzymają się najprostszej drogi i mimo że jak powiedziałeś wydają ci się "minimalistyczne" wcale tak nie jest. Są proste ale mimo to mają wszystkie potrzebne użyteczności.

        Nie można tego niestety powiedzieć o KDE, które łamie ją na każdym kroku – wprowadzając całą masę graficznych konfiguratorów, elementy powielające czynność innych elementów, nakładki wprowadzające dodatkową kompleksowość. Nie mam tutaj oczywiście za złe że kde ma dużo ficzerów. To świetnie że jest funkcjonalne. Na obecnym poziomie niestety nie spełnia podstawowych standardów. Mam nadzieje że to się zmieni w przyszłości.

      • pijaczek

        Teraz to już nie rozumiem czy masz problemy ze zrozumieniem tekstu czytanego czy z językiem angielskim… mogę założyć jedynie to drugie i ci przetłumaczyć, bo czytać ze zrozumieniem cię nie nauczę.

        Projektowany kod powinien być najprostszy jak to możliwe, ale nie prostszy. Chodzi tu o łatwość w zarządzaniu i rozwijaniu kodu. Nie może się to jednak odbywać kosztem możliwości. KISS to dobrze zaprojektowany kod za pomocą prostych wzorców projektowych, łatwy w zrozumieniu i zarządzaniu. Nie oznacza to, że program ma być mały "napisany na kolanie bez żadnych możliwości i przemyślenia budowy" (Simple also does not mean "quick and dirty."). Prawdę mówiąc kod KISS wymaga czasami dodatkowej pracy, aby kod był prosty w utrzymaniu.

        OpenBox ma strasznie chaotyczną i nieprzemyślaną budowę (dirty), a dodatkowo mocno komplikuje sobie życie wybierając przykładowo xml.
        Ratoison z tego co przejrzałem źródła jest dużo bardziej przemyślany (co prawda kod nie jest tak dobrze utrzymany jak Kwin, ale KISS zdecydowanie się trzyma… jednak kosztem możliwości – nie możesz odciążyć procesora, i wszystkie operacje musi on robić, zamiast przerzucać to na GPU, na którym wszystkie operacje nie robią wrażenia).

        Graficzne konfiguratory nie mają żadnego problemu z regułą KISS (jeśli chodzi o ścisłość one też są zaprojektowanie zgodnie z nią) – to zupełnie z regułą rzecz nie związana (o ile do konfiguracji nie są wymagane te konfiguratory, bo przykładowo użyto binarne pliki konfiguracyjne, ale w wypadku KDE tak nie jest i wszystko masz konfigurowalne z poziomu plików tekstowych, a graficzne konfiguratory to tylko dodatki). Elementy powielające czynność innych elementów… zapewne mówisz o elementach jak Phonon, który jest właśnie przykładem wręcz wzorowym jak regułę KISS wykorzystywać. To jest dokładnie to co opisuje przytoczona przez ciebie "In fact, it often takes a lot of thought and work over multiple iterations to simplify.". Dzięki napisaniu Phonona programy mogą używać jednego API i mieć prostą budowę, a nie każdy program każdy miałby w sobie implementować to co udostępnia Phonon (czyli obsługę wielu frameworków, bo nie wiadomo który będzie wykorzystany – przez co zaśmieca się kod). Takie nakladki na frameworki jak Phonon zmniejszają skomplikowanie kodu i upraszczają zarządzanie wydzielając, bo są zaprojektowane zgodnie z regułami KISS i współdzieli się ten kod, zamiast zarządzać wiele forków takiego kodu w każdym programie korzystającym z multimediów.

      • Starbit

        Hmm.

        "All design should be" -> "Projektowany kod powinien być" ?

        Myślałem że all design znaczy każdy projekt a nie projektowany kod. To znaczące przekłamanie w twoim tłumaczeniu.

        Widzisz wprowadzę trochę zamentu. Nie wiem czy wiesz że zasada KISS dotyczy się nie tylko inżynierii oprogramowania. Co więcej nie zaglądałem do żadnego kodu w/w projektów.
        Ty cały czas odnosisz się do dowodów że KDE spełnia KISS od strony KODU. Ok, fajnie że zajrzałeś do środka i wiesz co tam się dzieje. Ale co kogo obchodzi ten kod jeśli nigdy nie będzie contributował do repo, a tylko używał binarek?

        KDE zostało zaprojektowane (z ang. design) w sferze UŻYTECZNOŚĆI (nie kodu) tak aby łamać całą zasadę KISS. Żaden mój wcześniejszy argument nie odnosił się do kodu, więc nie wiem czemu tak to podchwyciłeś.

      • pijaczek

        "Myślałem że all design znaczy każdy projekt a nie projektowany kod. To znaczące przekłamanie w twoim tłumaczeniu."
        KISS dotyczy projektowania programu (przyznaj znalazłeś ten tekst na jakiejś stronie programistycznej dotyczącej jedynie software development), nie projektowania UI (to już nie jest software development, a UI design i ten ma całą masę innych reguł jak powinien być projektowany).

        KISS dotyczy wielu rzeczy – jednak w kwestii oprogramowania tylko jednej. Ogólnie nie powinno Cię interesować jaki jest kod, ale nie powinieneś też mówić o rzeczach na których się nie znasz. Tzn czasami może Cię interesować przykładowo to, że program, który olał KISS może się zatrzymać w rozwoju i wszystko później trzeba będzie przepisywać od nowa, aby dalej się rozwijał (przykładem niech będzie GIMP), a program napisany zgodnie z KISS będzie się rozwijał bardzo dynamicznie i długo zwalniał nie będzie (przykładem niech będzie Krita).

        KDE zostało zaprojektowane (code design) od strony kodu zgodnie z regułą KISS. W UI/UX Design reguła KISS nie ma zastosowania.

      • KISS nie ma do rozwoju programu nic do rzeczy tylko ludzie. Z reszta każdy postrzega to inaczej w zależności od skila.

        Nawet najgorszy program jeśli ma jakąś wartość jest dynamiczne rozwijany patrz Libre/OpenOffice, Firefox i reszta syfu. Krakerzy też nie płaczą, że muszą grzebać w kodzie maszynowym. Ważne jaką wartość im to grzebanie da.

      • Starbit

        W każdym razie mój pojnt jest taki że zasady KISS nie można zwężać tylko do kodu. Dotyczy ona każdego aspektu życia.

        Można zaprojektować architekturę budynku zgodnie z KISS, zaplanować swój dzień zgodnie z tą zasadą. Tak naprawde to już Einstain działał zgodnie z tą zasadą kierując się maksymą "everything should be made as simple as possible, but no simpler".

        W kade miałem na że nie jest zaprojektowany tak by spełniał tę zasadę kiedy użytkownik wchodzi w nim w interakcje. Boli mnie mój wewnętrzny czujnki KISS kiedy go używam ;>

      • Ceniek

        A może mi ktoś wyjaśnić dlaczego programy napisane w C szybciej się uruchamiają od tych w C++? Czy to wolniejsze jest QT od GTK, a może kwestia kompilatora lub doświadczenia programisty. Niby program napisany w C++ może mieć dużo mniejszy kod od tego w C przy identycznym programie, a jadnak zauważam minimalnie szybsze działanie programów napisanych w C++. Wyjaśni mi ktoś co jest tego powodem?

      • pijaczek

        Zazwyczaj język C i C++ mają podobną wydajność. OFC w wypadku wykorzystania poliformizmu i metod wirtualnych narzut na wykonanie jest dużo większy (PS. w javie każda metoda jest wirtualna) niż wywołanie bezpośrednio danej metody. Programiści C++ jednak zazwyczaj myślą kilka razy czy warto wykorzystać polimorfizm, a jeśli uznają, że nie warto wydajność powinna być podobna być podobna do tej z C. Po prostu w C++ możesz robić niektóre rzeczy których w C nie możesz, i przykładowo nie istnieje w C obiektowość, więc nie ma mowy o metodach, a co dopiero wirtualnych, dziedziczonych przez inne obiekty… dlatego o ile w C nie da się niektórych narzutów czasowych (skalkulowanych (czasami się opłaca zmarnować ten narzut na szukanie w VTable, odpowiedniej do wykonania metody, bo łatwiej zarządzać kodem) czy nie) to w C++ da się (chociaż ofc nie trzeba).

      • Starbit

        W przypadku qt wpływ może mieć też wykorzystanie mechanizmu slotów do obsługi zdarzeń, dynamiczne własności i sposobu działania MOCa.

        Ale tutaj mogę nie mieć racji, tylko moje domysły. Nie zajmuję się tym na codzień.

      • pijaczek

        Mechanizm slotów/sygnałów w Qt ma bardzo mały narzut… tu obawiałbym się bardziej o wydajność GTK, ze względu na to, że jego mechanizm sygnałów w GObject ma dużo większy narzut, a sama implementacja obiektowości i klas z wirtualnymi metodami (też GObject) ma znacznie większy narzut niż funkcje wirtualne w języku w którym są one standardem, a nie muszą być one "emulowane" za pomocą języka bez wsparcia dla nich.
        MOC działa na etapie prekompilacji – przetwarza kod C dodatki od Qt (język C nie wie co zrobić z sygnałem/slotem) na kod C gdzie dodawana jest implementacja slotów/sygnałów w oparciu o kod wejściowy i nic więcej – sam MOC nie ma negatywnego wpływu na wydajność (ma pozytywny względem alternatywnych możliwości implementacji)… ma wpływ tylko na czytelność i przejrzystość kodu.

      • W design-ie to się nie nazywa czasem minimalizm?
        Bo tak mi się wydaje po tym co piszesz. W KISS chodzi, że coś łatwo uzyskać, a w minimalizmie, że coś ma tylko niezbędne opcje skrojone w sam raz do użytku.

      • pijaczek

        Dokładnie tak – w KISS chodzi o to, aby starać się robić prosto rzeczy skomplikowane, a w minimalizmie chodzi o to aby to efekt był prosty, a uzyskać go można nawet skomplikowanymi drogami (zupełne przeciwieństwa).

      • Starbit

        kiss == prostota designu. Minimalizm to jeśli rezygnujesz z wymaganych użyteczności jak naprzykład w Nautilusie > 3.6 gdzie mondrale z projektu GNOME wywalili większość wymaganych funkcji w imie ich interpretecji minimalizmu. No kiss to z ich strony nie jest.

        "simple as possible, but no simpler" sentencja klucz do zrozumienia KISS ;>

    • Pingback: Facebook uwalnia środowisko programistyczne Nuclide - OSWorld.pl()