Załóżmy, że cofacie się w czasie i znowu jesteście piękni i młodzi. Jesteście sobie studentami na 2/3 roku i lubicie programować. Jaką technologię wybralibyście do rozwoju w 2020 i dlaczego?
0
2
Haskell. Bo to Haskell.
Ewentualnie zastanawiam się nad mercury-m, ale coś mi nie pasuje w nim.
0
necioo napisał(a):
Załóżmy, że cofacie się w czasie i znowu jesteście piękni i młodzi.
Czemu znowu? Ja tam dalej jestem piękny i młody. A odpowiadając na pytanie - PHP - bo bez względu na czas zawsze jest hipsterskie.
0
Jak bym poszedł w coś z C#, Python, Java, ale nie przywiązuj do tego zbyt wielkiej wagi. To się bardzo szybko może zmienić jak pójdziesz do pracy.
1
Skoro cofam się w czasie to po co mam sobie mówić czego mam się uczyć w roku 2020? No chyba, że cofam się o kilka dni, ale wtedy nie będę już studentem. Chyba, że chodzi Ci o cofnięcie o kilka lat i wtedy mam mówić sobie jaki wybiorę język w 2020, ale czy to nie jest poryte jeszcze bardziej? Żadna technologia w takim przypadku nie pomoże.
4
UglyMan napisał(a):
Jak bym poszedł w coś z C#, Python, Java, ale nie przywiązuj do tego zbyt wielkiej wagi. To się bardzo szybko może zmienić jak pójdziesz do pracy.
Niech zgadnę, do tego lubisz oglądać w TV najnowsze filmy, takie jak "Titanic" i "Kevin sam w domu"?
necioo napisał(a):
Załóżmy, że cofacie się w czasie i znowu jesteście piękni i młodzi. Jesteście sobie studentami na 2/3 roku i lubicie programować. Jaką technologię wybralibyście do rozwoju w 2020 i dlaczego?
Kotlin, bo nie irytuje na pierwszy rzut oka.
21
proste ze java i nauka oop na zwierzatkach i autach
0
necioo napisał(a):
Załóżmy, że cofacie się w czasie i znowu jesteście piękni i młodzi. Jesteście sobie studentami na 2/3 roku i lubicie programować. Jaką technologię wybralibyście do rozwoju w 2020 i dlaczego?
Wtedy nie szedłbym 100% w programowanie, tylko poszedłbym bardziej w social media, bo gwiazdy social mediów mogą liczyć na zarobki sporo większe niż programiści.
3
A odpowiem tak z nudów, może komuś ta odpowiedź da chociaż trochę do myślenia co każdego dnia właśnie traci :D
Wybrałbym clojure, bo:
praca na wskaźnikach < ukrywanie wskaźników pod obiektami < praca z obiektami ze wsparciem GC < praca na wartościach
Języki z perspektywy maszyny nie są poteżniejsze, one są coraz gorsze. Natomiast język jest poteżniejsze dla człowieka gdy ten język ma coraz więcej ograniczajacych reguł, ponieważ właśnie wtedy staje się bardziej przewidywalny, i prostszy w pojęciu, co dzisiaj jest kluczem w tworzeniu kodu za hajs (oczywiście tu przyjmuje za pewnik, że poziom prostoty i przewidywalność nie powinien zarazem odbierać możliwości tworzenia programów ogólnego przeznaczenia).
Operowanie wartościami bardzo upraszcza pracę, bo wartość nie może sama z siebie się zmienić, gdy operujesz na wartościach nie myślisz o miejscach w pamięci (a w przypadku obiektów nadal musisz ponieważ, obiekty mają swój zmienny stan, który również może zależeć od innych obiektów).
Niemodyfikowalne wartości ma pewnie też haskell i scala, ale w przypadku tych języków nie potrafię się przekonać, ponieważ nie zawsze czuję potrzebę pisania kodu zgodnego z FP (czyli sprowadzania efektów ubocznych do izolowanych miejsc w projekcie), bo to zależy od rodzaju i złożoności projektu, ani też nie czuję potrzeby, by zawsze wszystkiemu nadawać odgórnie stosowną reprezentację, wolę pierw by program z czasem nabrał kształt i wtedy można wyznaczać ograniczenia, ale takie rzeczy to skromnie powiem, że widzę dopiero po pewnym czasie.
Dodatkowym umilaczem jest REPL i podejście zorientowane na dane. To trochę uczy człowieka, by za bardzo nie odlatywać z abstrakcjami. Program, który w każdym miejscu pobiera dane i pluje dane jest bardzo łatwy do skumania, taki REPL jest ożywionym programowalnym debuggerem, który pozwala wywoływać funkcje, aktualizować je, nasłuchiwać dane, pracować bazą czy przeglądarką w interaktywny sposób.
Natomiast podejście zorientowane na dane, mówi o tym, że dane są lepsze niż kod, bo gdy dane opisują co ma robić program, to łatwiej jest program zmieniać edytując dane niż kod, co więcej w trakcie uruchomienia są one przezroczyste, dane są widoczne i można je dodatkowo przetworzyć w nieoczekiwany sposób. Ja je lubię, bo dzięki nim mogę opisać efekty uboczne, co ułatwia mi tworzenie większych rzeczy. Dodatkowo poprzez dane mozna opisać DSL i wiele bibliotek w clojure taka drogę obiera więc praca z biblioteką na ogół wymaga dostarczenia jej danych :-) Całość fajnie się zazębia i w połączeniu testami rekompensuje mi z nawiązką brak statycznego typowania.
5
Gdybym miał cofnąć czas to nie uczyłbym się zbytnio programowania, bazowałbym na podstawach wyniesionych ze studiów, a poszedłbym od razu w naukę platformy AWS/GCP ponieważ w niej wyspecjalizowani goście zarabiają grubo więcej niż programiści. Kolejną sprawą jest to, że AWS/GCP szybko nie umrze, więc pieniądz pewny na kolejne 10 lat w przód, a jakby nie patrzeć to też IT.
4
Jeśli cofamy się w czasie i zakładamy że mam startować w 2010 to dalej wybrałbym Javę. Był to jedyny statycznie typowany język z GC w którym można było zarobić na Górnym Śląsku
Jeśli zakłądamy że jestem 10 lat młodszy i startuję dziś to celowałbym bardziej w Kotlina i Scalę. Dziś już nie chce mi się przekwalifikowywać z wizją spadnięcia z seniora na mida. Poza tym dalej w okolicy mało firm robiących backend w Kotlinie czy Scali więc byłbym przywiązany.
Jeśli chodzi o hobbystyczne programowanie to nie uczyłbym się Perla czy innych dziwnych rzeczy tylko od razu wziął się za Haskella
Jeśli chodzi o rzeczy nieprogramistyczne to bardziej zmuszałbym się do nauki angielskiego. W tej chwili jest to główna rzecz która blokuje mi podwyżkę (i ewentualną pracę zdalną w Haskellu dla USA czy UK)
2
Nadal wybrałbym front+php, potem, po zdobyciu funduszy i stałych klientów zaatakował Unity+C# plus blendera/daz 3d stworzył własne studio gamingowe i trzepał hajs $ wzbogacając to o stronę en z płatnościami za access (co wiąże się ze skillami front+php), czyli taki samograj w którym tylko doglądasz jak ciasto rośnie.
Reszta plebsu niech robi na etacie :P
15
czysteskarpety napisał(a):
Nadal wybrałbym front+php
Czyli syndrom sztokholmski powiadasz
1
czysteskarpety napisał(a):
Nadal wybrałbym front+php, potem, po zdobyciu funduszy i stałych klientów zaatakował Unity+C# plus blendera/daz 3d stworzył własne studio gamingowe i trzepał hajs $ wzbogacając to o stronę en z płatnościami za access (co wiąże się ze skillami front+php), czyli taki samograj w którym tylko doglądasz jak ciasto rośnie.
Jest lepszy pomysł z tym blenderem - w gaming musisz jeszcze opłacać pryszczatych nerdów więc koszta większe. Dam ci lepszy: porn render farma, trochę zdolności plastycznych a później można już zwyczajnie trzepać hajs na dewiantach. Minimalny wkład własny (trochę Ryzenów + RTXów), praktycznie nieskończone zapotrzebowanie, trochę assetów a w przyszłości jacyś stażyści po ASP. Trzeba tylko się wstrzelić w jakąś niszową dewiację co by konkurencja była mniejsza.
2
...studio gamingowe, a pozniej praca w sobotę ;)
1
pan_krewetek napisał(a):
A odpowiem tak z nudów, może komuś ta odpowiedź da chociaż trochę do myślenia co każdego dnia właśnie traci :D
Wybrałbym clojure
Świetna rada pomagająca skutecznie uniknąć zatrudnienia.
Ezoteryczne technologie warto poznawać jak już się ma stabilne zatrudnienie.
0
jesteście piękni
Zostaję tiktokerem i śmieję się z 20k miesięcznie
2
Rust
Jako ostateczne rozwiązanie kwestii niepracowania przy CRUDach
:P
0
Gdybym cofnął się w czasie to chyba już bym znał technologię bo przychodzę z przyszłości? Ale gdybym w teorii „wczytał save” to bym poszedł na inne studia.
0
Wczoraj coś takiego przeczytałem:
http://problemypolskiejbranzy.it/null/ile-zarabia-programista-15k/
więc raczej nie wybrałabym programowania ponownie
5
- Kubernetes
- Operatory
- Docker - must have + cri-o - od siebie
- Helm
- Terraform
- Tekton
- Juju/Maas - któryś z tych + Ansible
- Fluentd
- Jakiś lekki, fajny, kompilowany i przyjemny język - Rust/Go/
- Jakąś bazę danych - zapewne Postgres
3
Nie wiem jak bym myślał jak junior, ale pewnie to samo w czym robię - Erlang/Elixir. Może nie są to super popularne technologie, ale mocno rozwojowe i po części niwelują potrzebę całego bełkotu Kubernetes. No i Postgres, jako, że to jest baza danych, która oferuje praktycznie wszystko co trzeba do czasu aż nie urośniesz na tyle, że potrzeba specjalnych rozwiązań (FTS, kolejki, "document store", KV store, spatial data, time series, etc.).
3
hauleth napisał(a):
Nie wiem jak bym myślał jak junior, ale pewnie to samo w czym robię - Erlang/Elixir. Może nie są to super popularne technologie, ale mocno rozwojowe i po części niwelują potrzebę całego bełkotu Kubernetes. No i Postgres, jako, że to jest baza danych, która oferuje praktycznie wszystko co trzeba do czasu aż nie urośniesz na tyle, że potrzeba specjalnych rozwiązań (FTS, kolejki, "document store", KV store, spatial data, time series, etc.).
Ciężko mi się nie zgodzić z. Natomiast na pewno nie nazywałbym tego bełkotem. Co innego jak masz apkę serwującą gify z kotami, a co innego gdy pracujesz w projekcie na kilka milionów ruchu. Z pakowaniem się w Kubernetes jest ten sam problem jak pakowanie wielkich yolo bibliotek/frameworków typu React na front blogaska albo stronki z newsami.
Kubernetes jest rozwiązaniem dla typowego ogromnego enterprise. Do mniejszych rzeczy można zaprzęgnąć sobie MicroK8s albo K3s opartego o K3os. Są to mniejsze zasobowo rozwiązania oferujące praktycznie to samo. Nie twierdzę, że warto ich używać od razu ale warto pomyśleć pod kątem użycia później.
hauleth napisał(a):
np. mamy hot reload, gdzie możemy zaktualizować aplikację bez ubijania połączeń
A gdzieś poza Elixirem to jeszcze występuje? Bo to o czym mówisz to abstrakcyjny temat. I jeżeli tylko Elixir ma takie fajne rzeczy to już wiadomo dlaczego ludzie pakują aplikacje w kontener. Jak weźmiesz 100 programistów z randomowych firm i zapytał czy wiedzą co to Elixir to pewnie 90 nie będzie miało pojęcia.
3
purrll napisał(a):
A gdzieś poza Elixirem to jeszcze występuje? Bo to o czym mówisz to abstrakcyjny temat. I jeżeli tylko Elixir ma takie fajne rzeczy to już wiadomo dlaczego ludzie pakują aplikacje w kontener.
W zasadzie nie jest to funkcjonalność Elixira, ani nawet Erlanga tylko BEAMa (Wirtualnej Maszyny Erlanga)
Jak weźmiesz 100 programistów z randomowych firm i zapytał czy wiedzą co to Elixir to pewnie 90 nie będzie miało pojęcia.
Tu jest właśnie pewien paradoks Erlanga. Świetny język (nawet na to że dynamicznie typowany) z niesamowicie złym marketingiem. Elixir ma już trochę lepszy marketing. Erlang ma też dziwną składnię i dziwne koncepty jeśli chodzi o bazy danych (był to język projektowany do programowania routerów). Elixir za to jest bardziej projektowany do pisania normalnych korpo aplikacji i klepania stronek z Postgresem. Składnie ma wzorowaną na Rubim przez co kradnie mu trochę programistów znudzonych powolnością Rubiego
Myślę że Elixir może jeszcze trochę namieszać. No ale to dalej język dynamicznie typowany więc nie chciałbym go dotykać. Ale ja czekam na Hamler czyli język kompilowany na BEAM o składni Haskella
5
Do mniejszych rzeczy można zaprzęgnąć sobie MicroK8s albo K3s opartego o K3os. Są to mniejsze zasobowo rozwiązania oferujące praktycznie to samo.
Albo zwyczajnie użyć supervisora systemowego, jak systemd. Wyjdzie praktycznie to samo, a mniej babrania, bo masz to gotowe w systemie od początku.
A gdzieś poza Elixirem to jeszcze występuje?
W game developmencie się tego używa by nie trzeba było restartować całej gry co zmianę, ale to jest trochę inna para kaloszy. IIRC Java chciała coś takiego oferować, ale niespecjalnie to wyszło. Lispy i Smalltalk często mają dostępną taką opcję.
I jeżeli tylko Elixir ma takie fajne rzeczy to już wiadomo dlaczego ludzie pakują aplikacje w kontener.
Kontenery nie mają tutaj nic do rzeczy. To samo co oferuje k8s z podmianą podów można ogarnąć samymi VMkami czy nawet w obrębie jednego systemu, wystarczy trochę wiedzy. (socket activation, xinetd, rozwiązania używane od dawna).
Jak weźmiesz 100 programistów z randomowych firm i zapytał czy wiedzą co to Elixir to pewnie 90 nie będzie miało pojęcia.
Prawda, ale weźmiesz dowolny pakiet jaki przeszedł przez internet i masz 90% szans na to, że przeszedł przez węzeł kontrolowany przez Erlanga (dane za Cisco).
W zasadzie nie jest to funkcjonalność Elixira, ani nawet Erlanga tylko BEAMa (Wirtualnej Maszyny Erlanga)
Formalnie to jest właściwość Erlanga, BEAM naturalnie musi ją wspierać, tak samo jak wszystkie inne implementacje.
Erlang ma też dziwną składnię
Wynika to z historii, bo Erlang zaczynał jako biblioteka do Prologa. Składnia zwyczajnie potem została.
dziwne koncepty jeśli chodzi o bazy danych
Nie rozumiem o co Ci tutaj chodzi? Mówisz o Mnesii? Cóż, to jest DB oferowana w "standardzie" ale wcale nie jedyna możliwa do użycia w Erlangu. Więc nie za bardzo wiem jak się do tego odnieść.
był to język projektowany do programowania routerów
Centralek telefonicznych, nie routerów. To, że teraz się to praktycznie łączy w jedno nie oznacza, że zawsze tak było.
No ale to dalej język dynamicznie typowany więc nie chciałbym go dotykać.
Well, to dynamiczne typowanie po części jest wymuszone tym jak działają procesy w Erlangu. Dodatkowo poprzez izolację błędów nie jest to tak upierdliwe jak w innych językach (błąd w jednym procesie wcale nie musi oznaczać eskalacji, jeśli to jest sporadycznie występujący błąd, to bez problemu aplikacja sobie z tym poradzi).
Z tego co rozmawiałem z Erlangowcami 5 lat temu to te systemy do sprawdzania typów są średnie, ale może się to już poprawiło
Różnie bywa. Dialyzer sprawdzi tylko "happy path" nie jest to w pełni system typów. Jednak bardzo często jest to wystarczające rozwiązanie.
4
To ja się chyba właśnie tak cofnąłem w czasie bo z końcem tego miesiąca kończę przygodę z Javą i zaczynam z Elixirem :)
8
Zdecydowanie Rust.
Teraz uczę się Rusta i jest to pierwszy język od wielu lat przy którym odczuwam te same emocje co kiedyś na początku gdy pisałem pierwsze programy.
Jest to relatywnie prosty język, ze świetnym stosunkiem możliwości do stopnia skomplikowania i najlepszymi komunikatami kompilatora jakie kiedykolwiek istniały w historii informatyki. I bez sztucznych ograniczeń - można korzystać z całego API systemu operacyjnego, z bibliotek C, C++, Pythona, Javy, można zejść do poziomu asma ale można też pisać na poziomie abstrakcji Haskella albo nawet wyżej (procedural macros).
Poza tym walka z kompilatorem, którą często trzeba stoczyć, zanim się człowiek nauczy w tym pisać, właśnie przypomina mi stare dobre czasy. Tu nie jest łatwo, ale za to efekty są wyśmienite.
0
Na pewno nie Python i JavaScript bo dostać w tym pracę jest baaaaardzo trudno. Jest przesyt juniorów. Ja wziąłbym coś niszowego, może Go, Dart/Flutter.
3
Oczywiście, że Perl. Ja nie wiem, co to za pytanie...