nieznasz sie na niczym a chcesz pieniedzy

Bajki opowiadasz, ja właśnie na OU już na drugim roku miałem w ramach zajęć opracowywanie kompletnego systemu do obsługiwania lotniska (rezerwacja biletów, zarządzanie siatką połaczeń itd). Zależnie od wybranych kursów możesz się nauczyć więcej lub mniej. Powodzenia życzę przy próbie 'przejścia' algorytmów sztucznej inteligencji na 3 lewelu...

'czego można się nauczyć w College w UK'
Bo to odpowiednik technikum zwykłego. W Polsce też po Technikum Informatycznym programistą nie będziesz, jeżeli sam się nie douczysz...

Zajrzałem, rzeczywiście jest metoda 'at' na std::vector. Jest tak rzadko używana, że nie skojarzyłem, że coś takiego może być. Skoro jest tak rzadko używana to ciekawe czy kompilatory mają dla niej specjalne optymalizacje? W językach gdzie sprawdzanie indeksów tablic jest standardem kompilatory mają zarówno wyliczanie poprawności indeksów na etapie kompilacji (tam gdzie się da) jak i generowanie specjalnych konstrukcji zmniejszających narzut (np for w Javie na indeksach od A do B w tablicy o długości N jest zmieniany przez JITa na dwa fory: jeden od A do min(N, B), gdzie nie trzeba sprawdzać indeksów i drugi od N do B, gdzie sprawdzanie indeksów jest włączone).

Jeśli komputer ma mało pamięci, a środowisko wymaga przewidywalnych i szybkich odpowiedzi to tracing GC (w tym hybrydowe GC w stylu zliczanie referencji + tracing GC do cykli jak w Pythonie: https://rushter.com/blog/python-garbage-collector/ ) w ogólności się nie nadaje. Tracing GC usuwa obiekty z pewnym opóźnieniem, by jego koszt się amortyzował i był niski, więc jest narzut pamięci na długo żyjące śmieci. Nie ma znaczenia jaki jest język o ile ma tracing GC - Java, C#, JavaScript, Python, etc

Migracja z Javy do C++ z powodu GC? Hmm, skoro działało przez pewien czas w Javie to być może innym rozwiązaniem byłoby zastosowanie lepszego GC? Do Javy dopiero powstają GC o bardzo niskich opóźnieniach:
http://openjdk.java.net/projects/shenandoah/
http://openjdk.java.net/projects/zgc/
Ten drugi ma eksperymentalne buildy tutaj: http://jdk.java.net/zgc/ (pierwszy ma gdzieś indziej)
Oba są nadal w fazie eksperymentalnej, więc oczywiście ciężko je już teraz rekomendować, ale ogólnie zdecydowanie powinny zwiększyć ilość przypadków, w których użycie Javy ma sens. Pauzy są na poziomie kilku milisekund, więc moim zdaniem z takim GC to można by nawet jakiegoś CoDa czy Battlefielda w Javie napisać.

1. od c++ 11 czyli od jakiś 7 lat, masz dość mocny przymus używać std::vector.
2. odśmiecanie? Są gc dla c++ ale tu nie o to chodzi. C++ teraz mocno trzyma się w szeroko pojętym embedded i tu nie mówię o czymś pokroju rdzeni a5 a normalnych komputerach przemysłowych z wielordzeniowymi arm czy mips. Trzeba tu wydajności pod każdym względem, a przy dużych obciążeniach takie rzeczy jak gc mogą sprawiać problemy(i był akcje migracji niektórych części softu z java => c++). Masz inteligentne wskaźniki, trzeba tu oczywiście uważać bo to nie gc ale to lepsze niż operacje na gołych wskaźnikach(w framework qt relacja rodzic-dziecko). C++ nie jest i nie powinien w wszystkim naśladować java czy c#. Z resztą obecnie c++(wraz z stl) jest już dość skomplikowany.

w UK niestety jest drogo i szkolenie nie jest na zbyt wysokim poziomie.
tak zwany open univerity (studia zaoczne) kosztuje 1700 funtow za semestr i możesz to robić przez 6 lat a i tak gowno z tego wyciagniesz chyba, ze poswiecisz wiele czasu na samodzielną nauke poprzez tworzenie własnego portfolio, mówiąc po ludzku praktyka i jeszcze raz praktyka

Istnieją takie dokumenty:
The JavaTM Language Specification
The Java® Virtual Machine Specification
Można je przejrzeć tutaj:
https://docs.oracle.com/javase/specs/
JVM od Microsoftu ZTCP zastępował rozwiązania ze specyfikacji własnymi rozwiązaniami, a konkretnie chodziło np o kwestię wykorzystania bibliotek natywnych czy też natywnego API w ogólności.


Mimo iż standardowe implementacje są zwykle pisane w C/ C++ to istnieją takie produkty jak:
PyPy - JIT do Pythona napisany w RPythonie
Rubinius - coś podobnego dla Ruby'ego
GraalVM/ Truffle - pisany w Javie JIT do w zasadzie wszystkiego:
http://openjdk.java.net/projects/graal/
https://github.com/oracle/graal
http://www.oracle.com/technetwork/oracle-l...view/index.html

Przeszkodą jest zwykle wygoda (i produktywność) programisty oraz przydatność dla zastosowań korporacyjnych. COBOL jest (jak na dzisiejsze standardy) mocno niewygodny i dlatego umiera mimo iż korpo bardzo go lubiły. Z drugiej strony jest np sporo niby wygodnych języków kaczo typowanych, ale kacze typowanie utrudnia statyczną analizę kodu, która w projektach o wielkości rzędu miliona linii kodu jest absolutnie niezbędna. Wadą C++ jest to, że sporo rzeczy nie jest sprawdzane z automatu, np indeksy tablic, poprawność wskaźników, wiele rzeczy nie jest zarządzane automatycznie jak np odśmiecanie pamięci w tle, leniwe ładowanie kodu, wiele rzeczy nie jest też dostępnych jak np (nielubiana przeze mnie) refleksja i dynamiczne wzbogacanie bajtkodu. Wzbogacanie bajtkodu jest trochę czymś innym od generowania kodu w ogólności, bo wzbogacanie opiera się na transformacji kodu już istniejącego - dzięki temu, że bajtkod Javy zawiera sporo informacji, które wylatują z kodu natywnego na etapie kompilacji to taka transformacja ma sens.


Wymazywanie typów jest tak naprawdę wszędzie poza .NETem. Tylko w .NET możesz sobie np sprawdzić w czasie wykonania jaki jest typ akceptowanych elementów dla pustej kolekcji referencji do obiektów. Niektórym bardzo brakuje 'new T()', ale można to obejść za pomocą constructor reference: https://gist.github.com/piotrpo/c198713abf...54a364786fa8dde
Wymazywanie typów w Javie pozwala na implementację dużo bardziej skomplikowanych genericsów w Scali zachowując przy okazji dużą dozę interoperacyjności między Scalą i Javą. Stosując się do pewnych zasad można w Scali pisać API, które wygląda rozsądnie z poziomu Javy. Przykładem tego jest Javowe API do Akki: https://akka.io/docs/
W .NETu nie jest różowo i te alternatywne języki dla C# nie wprowadzają jakichś dużo większych możliwości. Np F#-owi brakuje typów wyższych rzędów.

Tutaj jest natomiast dyskusja, którą prowadziłem i w niej między innymi bronię wymazywania typów (oraz odśmiecania pamięci w tle zamiast zliczania referencji): https://users.scala-lang.org/t/what-are-so...-languages/2556
Zapraszam do dyskusji

a co mam piernik do wiatraka ?ja dalem odp. co nie ma nic wspolnego, ale temat prac sie rozwnial jaka to dobra praca nie jest gdzie sa lepsze, ale co ma wspolnego bycie pulkownikiem w wojsku do osoby pracujacej na calym swiecie wykonujaca konkretne zlecenia to nie czaje

znam czolgistow bo sis gwiazdy jest pulkownikiem nie ma czasu na zycie prywatne. a we urlop to osrodek ze szkoleniami tez wojskowy

Najlepiej byc spawaczem podwodnym xD znasz angielski robota na calym swiecie i zarobek taki ze po roku sobie mozna Lambo kupic (o ile sie przeżyje xD)

Takie kursy to dobry wstęp do zapoznania się z podstawami programowania. Należy jednak mieć świadomość, że bezpośrednio po skończeniu nie będziemy gotowi na pracę programisty. To co ważne to informacja że Java to sam goły język. W pracy prawie zawsze używa się go razem z jakimś frameworkiem np Spring. Programowanie to bardzo ciekawe zajęcie, ale musimy być gotowi na ciągłą naukę. Żeby być dobrym specjalistą potrzebujemy paru lat nauki.

Nokia 3310 to żadne ograniczone urządzenie tylko potężna kobyła.

Przecież Java działa i na kartach płatniczych oraz kartach SIM w telefonach. (.Net zresztą też). Normalnie w chipie swojej karty kredytowej/debetowej masz JCVM i sobie piszesz applety. Oczywiście wirtualna maszyna jest ograniczona bo to wszystko musi się zmieścić na tych kilkudziesięciu kilobajtach, ale nic nie stoi na przeszkodzie aby w pralce Java też była

A... Udemy. Czy to ta firma, która przy okazji poprzedniego 'artykułu' oferowała w promocji dla PCLabowiczów kurs... drożej niż ich ogólna, promocyjna cena? Tak, to chyba ta.

Respect młody . Takie ogarnięcie w gimbazie to naprawdę poważne podejście do tematu. Ja chodziłem do szkoły jak jeszcze nie było gimnazjum, ale pod koniec podstawówki to najwyżej pierwsze komputery składałem. To był początek lat 90, ale i tak szacun.

Nie miałbym nic przeciwko sponsorowanym wpisom, gdyby ktoś się do nich faktycznie przyłożył. Przecież można było napisać coś dłuższego o samej Javie i do tego dołożyć informacje o kursie. A tak mamy tylko wpis, na który wszyscy reagują alergicznie.

Sam C# bardzo często wyprzedza Javę jako język, to fakt. Chociażby generyki i upośledzony type erasure w Java. Ale jeśli porównać całe ekosystemy, koledzy, którzy mają porównanie, bo po kilka lat pracowali i w tym, i w tym, są bardzo jednogłośni. Nie zgodzę się więc, że Java jest popularna, bo jest stara. Cobol też jest stary i był twardo używany w bankach inwestycyjnych, a jednak się nie uchował. Dla mnie to właśnie ekosystem stanowi o jej sukcesie. Dlatego też na JVM ciągle powstają nowe języki - bo ekosystem daje wielkie możliwości. Nie twierdzę jednak, że .NET nie daje. Tam powstał F#. Dlatego nie jestem fanem wojny .NET vs JVM. Oba te środowiska są tak samo popularne i oba dają wielkie możliwości. Nie uważam jednak, że jest to z powodu ich wieku. Jest to z powodu ich dojrzałości i możliwości.


To akurat nie jest prawdą w przypadku Polski. Polska branża IT jest bardzo młoda, a programiści Java czy C# rzadko są po trzydziestce (albo właśnie dobijają). Na początku było o wiele więcej programistów PHP. A jednak w kilka lat proporcje odwróciły się.


Jeśli pisany system to kulfon (monolit) zlepiony na gumę do żucia z milionem zależności, albo jeszcze gorzej - z bibliotekami, które wołają JNI, to pewnie tak było. Ale obecnie, jeśli ktoś robi w mikroserwisach, nie ma najmniejszego problemu, by jakiś klocek przenieść na inny system operacyjny. I to jest fakt, nie marketing. Wielokrotnie to robiłem i starczyło wyłącz, włącz, a kolejka przechowywała komunikaty w czasie, gdy jeden moduł był wyłączony. Nie ma powodu, aby ta sama binarka Javy inaczej działała na Windowsie, a inaczej na Linuxie. Mogą być różnice związane z systemem operacyjnym takie, jak system uprawnień, system plików, ale to nie jest kwestia Javy. Żeby sama Java działała inaczej musiałaby być krzywa JVM, która na przykład inicjuje domyślnie boolean na true zamiast false. Ale dlatego wybiera się takie JVM, które są zgodne ze standardem.


W takim, że trzeba się niewiele narobić. Obecnie jest Spring Boot, który po wypakowaniu ZIPa i dopisaniu kilku (dosłownie) linijek kody daje działający webserwis RESTowy. Bo framework z pudła daje un/marshalling, obsługę HTTP, Dependency Injection, dostęp do bazy danych, transakcje, kontener aplikacji i inne. Oczywiście jest w tym sporo magii i nie nauczysz się w dwa dni. Ale jak już wiesz, jak poprawnie to wszystko stosować, możesz bardzo szybko tworzyć kolejne moduły systemu w świecie mikroserwisów.


Nie wiem co by było, gdyby. Jasne, że takie narzędzia mogłyby powstać dla C++. Ale losy potoczyły się inaczej.


Będę powtarzał do znudzenia. Rekrutacja nie jest tylko po to, aby pracodawca sprawdził moje umiejętności. Dla mnie to jest przede wszystkim czas, kiedy to ja mogę ocenić, czy chcę tu pracować. Jeśli rekrutacja jest nieprofesjonalna - dziękuję. To jest zadanie firmy zadbać o to, by ich HR wiedział, na co zwracać uwagę i umiał odpowiadać na podstawowe pytania kandydata. HR na pewno może sprawdzić angielski, może wypytać o doświadczenie (czy testowali kod, czy miał kontakt z klientem, czy zna ideę Continuous Integration), może wyczuć, czy ktoś sympatyczny, czy buc. A przede wszystkim zapytać, czy kogoś w ogóle interesuje zmiana pracy. Reszta należy do technicznej rekrutacji. Ja z kolei oczekuję, że rekruter odpowie mi na takie pytania, jak: monolit czy mikroserwisy; skład i rozmiar zespołów; lokalizacja biura i co ono oferuje; openspace czy osobne pokoje; jakie są pokoje do konferencji; czy są delegacje i ile; czy mogę wybierać technologie, czy betonuje je architekt; jakie podejście ma firma do refactoringu; czy jest support 24/7; jakie podejście do nadgodzin; elestyczne godziny pracy; jaka forma zatrudnienia i widełki.

Oczywiście, odnoszę się po prostu do wypowiedzi Namonaki.

Po pierwsze trzeba zaczac, ze do roznych zastosowan sa rozne jezyki programowania. Raczej nikt nie pisze aplikacji webowych w C++ ani nikt tez nie pisze solvera w javie.

Ale po co używać C++ skoro można użyć Javy czy .NETa? Bardzo często wydajność nie ma większego znaczenia - jeśli masz np. aplikację webową która dobrze się skaluje (tzn, by obsłużyć większą liczbę klientów wystarczy droższy serwer) a niemal cały czas związany z obsługą procesu jest zżerany przez bazę danych to jaka będzie korzyść z pisania wszystkiego bardziej niskopoziomowo?

Nie, nie dlatego jest popularna. Jest popularna głównie dlatego, że jest technologią będącą na rynku znacznie dłużej niż inne technologie tego typu. Przez to jest znacznie więcej specjalistów w niej piszących z doświadczeniem niż w innych technologiach.
Te rzeczy, co wymieniłeś, które niby robią Twoim zdaniem z Java taką popularną technologię w innych technologiach jak .NET chociażby miałeś już od dawna z pudełka. Sam język JAVA bardzo powoli się też rozwija. Jak w .NET miałeś lambdę już od 2007 roku, to w JAVA pojawiła się na dobre w wersji 1.8 dopiero 4 lata temu.
Poza tym ta wieloplatformowość Javy to marketing i nic poza tym. Kiedyś próbowałem odpalić wielką aplikację webową napisaną w JAVA na Linuxie - wcześniej pracowała bez problemu na Windowsie. I wiesz co? G z tego wyszło, bo aplikacja działała inaczej na Linuxie niż na Windows. Pojawiały się dziwaczne błędy, których naprawianie nie było zabawne