Tia ... jeszcze więcej klepaczy kodu
Era Informatyzacji się kończy więc trzeba jeszcze podgonić ryneczek... tzn na tym ZAROBIĆ .
Intel już okrakiem wycofuje się z 10nm w 2018 !!!
No albo chcą przeciągnąć 14 nm ile się da ... albo faktycznie widzimy koniec ery krzemu.
Co by oznaczało że 10 nm ( o ile się pojawi, bo tu zaczynają się wątpliwości) będzie końcem .... pierwotnie mówiło się o 5nm ale w środowiskach znawców (fizycy) mówi się że zjawiska zachodzące w takich rozmiarach <10nm powodują że ICki nie chcą działać. W sumie ta bariera pojawiła się dość nagle.
Nie podniecał bym się wypowiedziami innych firm które się to chwalą że tłuką w 10nm a nawet mniej, wic polega na tym kto jak liczy te nm jednemu wyjdzie 14 innemu 10 a jeszcze inny tak zmierzy ze panie ale tu u mnie najcieniej jest 5 nm wiec nie no jak my mamy 5nm.
Intel jest najbardziej zaawansowany i to oni zawsze wyznaczali drogę i nie ma tu żadnego ale.

Tak, a mechanicy samochodowi będą wkrótce niepotrzebni, bo samochody dawno przestały szybciej jeździć. Co mają nanometry Intela do informatyzacji?

Chyba po takich kursach, ale dziennikarskich musi być ekipa reakcyjna.

Gorszego steku bzdur dawno nie czytałem. Za wprowadzanie klienta w błąd są paragrafy. Miejcie to na uwadze.

Teraz nawet po 35zł

Tu jest mowa o początkach (po to to szkolenie), a początkujący zarabia mniej (a przynajmniej jeśli nie jest naprawdę dobrze ogarniający temat)

Wchodząc przez stronę

A aj mam coś takiego:
Zniżka dla nowych klientów — tylko przez 6 godzin!Zmień swoje życie dzięki nauce. Ponad 55 000 kursów, każdy za 35 zł.
I faktycznie pokazuje mi 35zł.

Ty niemowlaku zapewne wiesz. Popracuj sobie w środowisku, gdzie twoje rozwiązanie kompiluje się parę godzin godzin, a ponad 500 artefaktów (WAR, EAR, JAR, pakiety z flow XML), deployuje przez następne parę godzin, a to tylko dlatego, że nie jesteś w stanie przeładować na gorąco jednego z modułów, bo zupełnie już biblioteka, czy runtime frameworku zostały źle napisane, a jak wiadomo JVM ma od samego początku błędy z działaniem class loaderów, szczególnie tam gdzie są static final, a mnogość już zbędnych bibliotek (i zależności do nich) dalej przeraża (np. niesławne xml-api.jar dla Java 1.3/1.4).

3. Pythona bardzo lubiłem - niestety niewiele już pamiętam i boję się, że to wcale nie problem, bo on nie działa natywnie w przeglądarkach (tj. bez pluginu z runtimem Python), więc zaczyna być... zbędny. Może istnieje kompilator Python->JavaScript...
4. Oracle nie poprawi wydajności publicznej JVM dla x86 względem tego co oferuje Spark, póki dalej produkuje serwery na Spark, bo to byłby strzał w kolano. Trzeba sprawdzić jakie mają plany.
5. JS/TS+Node.JS stała się faktem - w UI nie zaklniesz już rzeczywistości, a backend jeszcze się broni.
7. Wsteczna kompatybilność Java ogólnie jest, ale nie jest pełna, a do tego musisz wraz z Java zmieniać i hardware (np. jak masz serwery na komercyjnych UNIX) i często wersje produktów (np. serwerów aplikacyjnych), bo albo nie ruszają na nowej Java, a jak już je rozprujesz, zdekompilujesz, podmienisz biblioteki, czy wręcz zmodyfikujesz klasy (wbrew licencji), aby ruszyły, to i tak produkcyjnie tego nie użyjesz, bo nie ma na to supportu.

Nie zrozum mnie źle, ja bardzo lubię Java (choć chyba bardziej jednak C++, czy nawet czysty C), ale jestem daleki od zachwycania się nią i przestaję po woli widzieć sensu jej istnienia (OK, jeszcze jest Android), bo TypeScript i Node.JS (lub coś podobnego), prawie na pewno z czasem posprząta po stronie server-side. Nikt już przecież nie używa w nowych projektach JSF, JSP, ani żadnej innej javowej technologii renderowania HTML po stronie serwera, a o Applet i Swing już dawno zapomnieliśmy.

3. Istnieje kompilator Pythona do JavaScriptu: https://www.transcrypt.org/ ale to chyba rozwiązanie niszowe - po co pisać w Pythonie skoro i tak jest kaczo typowany tak jak JavaScript? Istnieje też kompilator Javy do JavaScriptu, czyli Google Web Toolkit pozwalający pisać w Javie jednocześnie backend i frontend. Szał na GWT jednak dawno minął i teraz króluje połączenie Java na backendzie + JS/TS na frontendzie.
4. Oracle promuje SPARCa w inny sposób - obniżając koszt licencji na ich sztandarowy produkt (bazę danych) w przypadku odpalania jej na procesorach od Oracle. Koszty licencji bazy Oracle często przewyższają koszty sprzętu, więc Oracle ma duże pole do popisu. Nie widziałem żadnych wiarygodnych artykułów o tym rzekomym sztucznym ograniczaniu wydajności Oracle JVM na procesorach x86. Zresztą OpenJDK (który ma wydajność identyczną z Oracle JDK w większości zastosowań) jest na licencji GPL i taki np Intel czy AMD mogłoby to sforkować i zoptymalizować.
5. Hobbystycznie kodzę w http://www.scala-js.org/ i to rozwiązanie ma moim zdaniem bardzo dużo sensu. W Scala.js pisze mi się bardzo wygodnie, sam kompilator jest mocno niezawodny, a IDE daje tak samo dobre wsparcie jak dla kodu Scalowego pod JVMa.
7. Node.JS jest jeszcze młody, więc i problemy ma raczej wieku dziecięcego. Jednak jeśli ktoś stworzy Node.JS Enterprise Edition to problemy też będą w wersji Enterprise Edition (oczywiście o ile jakiś menedżer się nabierze na takie hasełka i w nie wpakuje). Problemy przy podbijaniu wersji zależności czy platformy zależą bardziej od skomplikowania i rozmiaru aplikacji (włączając w to ową platformę i zależności) niż od języka. https://en.wikipedia.org/wiki/Dependency_hell istnieje na każdej platformie i każdym języku. Node.JS 'niby to' rozwiązuje ten problem poprzez podłączanie wielu lokalnych kopii zależności ( http://blog.timoxley.com/post/20772365842/...dency-overheads ) ale to jest tylko iluzoryczne rozwiązanie problemu. Nawet jeśli np NPM podłączy mi bibliotekę 'kolekcje' (fikcyjna biblioteka na potrzeby rozważań) w wersjach v1 i v2 jednocześnie jako zależności z modułów odpowiednio A i B to program sypnie się, gdy będę chciał przekazać kolekcję v1 wyciągniętą z modułu A do modułu B.

Zgadzam się z przedmówcą. Liznąłem programowania w PHP, JavaScript, a zwykła Java to jeszcze więcej. Sam kurs co najwyżej podstawy może zarysować, później dochodzi ogrom własnej pracy w poznanie dokumentacji. Dlaczego coś działa lub nie, a jest to bardzo częstym problemem w trakcie nauki.

Pisząc stronę html w połączeniu z php i podłączając to do bazy danych MSSQL więcej czasu spędziłem czytając dokumentację niż pisząc kod.

To prawda, teraz już 35zł. Oj PCLabbersi

3. Tak mi się wydawało, że jest, bo link https://www.transcrypt.org znam, choć nigdy go nie używałem. Co do GWT, to należy to przemilczeć, choćby z tego względu, że Java jako język nigdy specjalnie nie nadawał się do tworzenia UI, co GWT obnażyło, komplikując mocno kod, cały proces wytwórczy i ograniczając możliwości. Względnie najlepiej tworzyło mi się UI w Java z użyciem SWT+JFace.
4. Problem istniał i był podnoszony za czasów Sun Microsystems - obecnie nie wiem. Co do forkowania, to nie do końca, bo ważna jest zgodność na poziomie bytecode, a taka optymalizacja moim zdaniem wiązała by się z innym bytecode, albo jakąś sprytną jego dynamiczną optymalizacją, aby nie opierał się tylko o stos.
5. Ja miałem w planach przyjrzeć się http://www.scala-js.org, ale czas nie pozwala. To może być to.
7. Zgadzam się, ale deweloperzy JavaScript tego nie wiedzą, że to nie do końca nadaje się do Enterprise i będą się chcieli wykazać, zastępując deweloperów Java, zastępując nas, więc musimy przeniknąć w ich szeregi

PCLAB MA PROCENTA HAHA takie kursy sa niesttey zadarmo teżw sieci. Pozatym do pracy po takim kursie nikt Was nie weźnie bez doświadczenia. Poczytać sobvie infomracje można ale trzeba je zastosować w praktyce. To dwie różne sprawy.

pclab urwac procent chce Pozatym do pracy po takim kursie nikt Was nie weźnie bez doświadczenia. Poczytać sobvie infomracje można ale trzeba je zastosować w praktyce. To dwie różne sprawy.

OTWÓRZCIE SOBVIOE NA INNEJ PRZEGLĄDARCE, WYCZYŚCIE PARAMETRY Z LINKU TO ZOBACZYCIE KURS PO 35 ZŁ niezłe jaja

Absurdalny argument. Jak na razie Node.js absolutnie nie zagraża Javie i innym sprawdzonym w biznesie rozwiązaniom. Żeby korporacyjne biznesy przeniosły się na Node.js to najpierw JSowi hipsterzy musieliby przepisać z Javy czy C# biznesowe biblioteki np finansowe. Tylko jaki niby znajdą powód, by ktoś to sfinansował? Niewielka redukcja duplikacji kodu przy łączeniu backendu z frontendem? To zdecydowanie zbyt mało. Żeby przenieść Javowe molochy z masą funkcjonalności do JavaScriptu trzeba wielu lat. Najpierw musi się znaleźć ktoś kto sprawdzi czy w ogóle Node.js nadaje się do tworzenia rozbudowanych aplikacji. Z tego co czytałem to Node.js jest raczej używany do niewielkich aplikacji bądź jako powiedzmy frontend backendu, czyli ta część która jest najbliższa użytkownikowi. Node.js można wtedy użyć do walidacji danych i wstępnego renderowania strony, a obrabianie ciężkich danych zostawić częściom systemu napisanym w Javie czy C#. Inaczej mówiąc - Node.js jest jak na razie używany mniej więcej w tych miejscach co Python, Ruby czy PHP.

Ponadto rozwój Node.js zdaje się wyhamowywać. Według indeed nawet Scala go dogania i niewiele jej już brakuje: https://www.indeed.com/jobtrends/q-node.js-q-scala.html - jeśli pokazany trend się utrzyma to za jakieś 2 lata popularność Node.js i Scali będzie mniej więcej równa.


GWT ZTCP miało być swego rodzaju imitacją Swinga - w sensie GWT miało mieć podobną mechanikę. Dzięki temu ludzie, którzy tworzyli wcześniej UI w Swingu mieli się w GWT łatwo odnaleźć. Szybko się jednak zorientowano, że nie tędy droga. Mimo tego GWT żyje dalej jako część frameworka Vaadin: https://vaadin.com/ . W .NETu też jest podobna technologia, nazywa się ASP.NET WebForms i też jest aktualnie traktowana jako przestarzała mimo, że przez wiele lat była w świecie .NETu bardzo popularna.


Cały czas powtarzasz jak mantrę, że bajtkod oparty o stos w czymś przeszkadza, a w szczególności że przeszkadza w optymalizowaniu bajtkodu Javowego na x86, a na SPARCa nie. Jeśli weźmiemy pod lupę architektury x86 i SPARC oraz trzy najpopularniejsze bajtkody czyli Javowy bajtkod, .NETowy CIL i LLVMowy bitkod to:
- wszystkie trzy nie są zorientowane na żadną konkretną architekturę. Kompilacja każdego z tych bajtkodów do kodu maszyny docelowej jest skomplikowana.
- kod maszyny docelowej raczej nie będzie w stanie przypominać oryginalnego bajtkodu ze względu na to, że te bajtkody mają zupełnie różne ograniczenia niż maszyny docelowe, np bitkod LLVMa zezwala na nieograniczoną liczbę rejestrów.
- zarówno x86 jak i SPARC opierają się na zbiorze wielu rejestrów i nie są maszynami stosowymi. Wobec tego sposoby optymalizacji kodu wynikowego dla obu architektur nie mogą się znacząco różnić.
- jedyna architektura jaką kojarzę, która wspierała sprzętowe wykonywanie bajtkodu Javy to ARM. Rozszerzenie które mam na myśli to https://en.wikipedia.org/wiki/Jazelle . ARM dawno jednak z tego zrezygnowało, bo sprzętowe wykonywanie bajtkodu Javowego jest mniej efektywne niż kompilowanie go (nawet w locie) do normalnego kodu ARMowego. Decyzja ta jest o tyle ważna, że przecież najwięcej kodu Javowego wykonywanego przez zwykłych użytkowników stanowią aplikacje na Androida na komórkach z procesorami właśnie od ARMa.
- .NETowy CIL tak samo jak Javowy bajtkod jest oparty w całości o stos. Za https://en.wikipedia.org/wiki/Common_Intermediate_Language : 'CIL is an object-oriented assembly language, and is entirely stack-based.' Czyżby Microsoft też miał sabotować wydajność na x86? To byłby już absurd, biorąc pod uwagę to, że poza x86 .NET jest praktycznie nieużywany (Windows Phone zdechł, a innych sposobów na wykonywanie CILa poza x86 nie kojarzę).

Ponadto wciąż nie pokazałeś przykładu na to, by HotSpot miał jakieś problemy z efektywnym wykorzystaniem rejestrów procesora x86. Podlinkowałem wcześniej artykuł o tym jak wypisać kod asemblerowy generowany przez JVMa, więc każdy może zweryfikować twierdzenia o generowanym kodzie. Ja sam przez dobrych parę lat siedziałem w czystym asemblerze dla x86, więc śmiało możesz mi pokazywać kod asemblerowy. Jak byłem jeszcze nastolatkiem (i fanatykiem asemblera) to nawet postawiłem stronę: http://asembler.republika.pl/ Czekam na przykłady

Mi się wyświetla cena 35 pln jesli pominę pclab

Trudno będzie mi się odnieść w skrócie do takiego elaboratu
7. Ten uśmieszek na końcu mojej wypowiedzi jednak coś znaczył. Nie stanie się to w 5 lat, czy może nawet 10, ale trend zmierzania do posiadania uniwersalnych deweloperów, mogących robić frontend, backend, może i middleware, oraz procedury składowane, pozostaje faktem - szczególnie w ujęciu Scrum, gdzie każdy jest deweloperem i każdy potrafi wszystko. Technologie oparte o JavaScript oferują to już dziś. Może będzie to TrueScript, a może Scala.js, ale raczej nie Java, bo od zaszłości nie będzie w stanie się łatwo uwolnić, a Oracle Corporation to jednak beton (w dobrym i złym sensie), który będzie wszelkie większe zmiany traktował personalnie, jako naruszające ich dobra/inwestycje, a IBM to równie silny 'hamulcowy'.
3. Ogólne założenie GWT było: pozwolić deweloperom Java robić robotę web deweloperów ze znajomością JavaScript. Podobnie było z JSF, tylko JSF miało dodatkowe założenie: sprzedać jak najwięcej serwerów, bo rendering HTML był bardzo wydajnościowo-żerny, a Sun produkował właśnie serwery.
4. Już ~16 lat temu istniały specjalizowane wielordzeniowe (48 czy 64 rdzenie) rozwiązanie sprzętowe do wykonywania bytecode Java - niestety nazwy nie pamiętam.
Co do optymalizacji wykonywania bytecode, to przykładu Ci ot tak z głowy nie podam, a szukać nie mam teraz czasu. Zasadniczy problem jaki widzę, to gdy operuje się tylko na stosie, jest to założenie, które dużo upraszcza, bo wiadomo że po każdym przekazanym argumencie trzeba posprzątać stos, a gdy przekazuje się to przez rejestry, to jest kwestią mocno dyskusyjną przez jakie, przez ile rejestrów, ale zakładając, że bytecode pozostaje po staremu, wydaje się to w sumie możliwe, że JIT zawsze będzie optymalizował to w ten sam sposób między wywołaniami bytecode-bytecode, ale co z konwencją wywoływania JNI i kodu natywnego JVM, którego JIT przecież nie kompiluje, ani nie jest w stanie (jak na razie) zrekompilować z asm do asm, zniemiając konwencję wywołania na jakąś wersję __fastcall? Trochę robi się ryzykownie, tak to optymalizować i to jeszcze w zależności od architektury i typu procesora.

Mi wyświetla 35 zł