Przeczytałem dzisiaj jeden artykuł w którym ktoś prognozował przyszłość IT , i generalnie wydźwięk z tego był taki że w niedalekiej przyszłości potrzeba będzie więcej analityków , PM , ludzi znających biznes aniżeli programistow ze względu na to jak samo programowanie będzie wyglądać . Co o tym myślicie ? Przy rozwoju AI , data science , chmury - czy to nie będą gorące tematy a programowanie i klepanie CRUDOW " legnie w gruzach " ? ;) A może jednak programowanie nigdy nie dojdzie do poziomu kiedy zostanie wyparte ? Zapraszam do luźnej pogawędki ;)
co miesiac przychodzi ktos kto pisze dokladnie to co Ty
co miesiac, odpowiedz jest taka sama
ktos to AI musi napisac
oraz
Kiedys sie klepalo w asm dzis masz nowsze jezyki, to co kiedys tworzyles w 10 dni dzis jestes wstanie stworzyc w 10 minut. Przez to zapotrzebowanie (biznes) rowniez rosnie na bardziej zlozone produkty
oraz
ktos musi utrzymywac juz istniejace produkty, nikt nie bedzie przepisywal software'u bo po prostu sie nie oplaca
EOT
Pewnie, że programowanie zostanie wyparte, na szczęście analitycy zostaną wyparci wcześniej :-D :-D
Zwykle takie artykuły piszą ludzie którzy nie mają pojęcia w tym temacie i wydaje im sie że to się wszystko jakoś magicznie samo dzieje ;)
Niemniej przecież historia pokazuje że cały czas automatyzuje się proste rzeczy a ludzie skupiają sie na robieniu rzeczy bardziej złożonych. Mamy języki wysokiego poziomu, frameworki, biblioteki, ale pracy nie jest wcale mniej, a więcej. Bo dzięki temu informatyka może rozwiązać więcej problemów i wchodzi w więcej dziedzin życia. I tworzymy zwyczajnie badziej złożony soft, a nie szybciej prosty soft.
Ostatnio czytałem o Raspberry Pi. Minikomputer powstał z inicjatywy grupy profesorów, którzy uważają że poziom programowania spada i programiści oddalają się od maszyn...
https://www.komputerswiat.pl/poradniki/sprzet/raspberry-pi-historia-minikomputera/3wrd656
Dawniej komputery posiadali ci, którzy sporo wiedzieli o budowie i zasadach ich działania, którzy potrafili je odpowiednio programować i wykorzystać. Komputerami zajmowali się głównie pasjonaci, którym elektronika nie była straszna, a kawałek kodu był dodatkiem do tej elektroniki. Wynikiem prac tych pasjonatów były zadziwiająco sprawne programy. Po latach nie trzeba być elektronikiem ani nawet inżynierem aby programować komputery. Brak potrzeby poznawania sprzętu sprawia, że ludzie nie pogłębiają wiedzy w tej dziedzinie. W zasadzie najważniejsze jest opanowanie obsługi urządzenia czy programu, a dla programisty - narzędzia do tworzenia aplikacji. Wynikiem prac dzisiejszych programistów są słabo zoptymalizowane programy ledwo wykorzystujące możliwości urządzenia.>
PHP umiera :/
Nie Przejmuj się @czysteskarpety , AI, jak powstanie, na pewno nie będzie się babrać w PHP, zostawi to ludziom:-)
lion137 napisał(a):
Nie Przejmuj się @czysteskarpety , AI, jak powstanie, na pewno nie będzie się babrać w PHP, zostawi to ludziom:-)
Ja bym nie był tego taki pewien. AI już zaczęła przejmować co najgorsze w ludziach.
Pewno jakiś junior robot po bootcapmpie.
Przy rozwoju AI , data science , chmury - czy to nie będą gorące tematy a programowanie i klepanie CRUDOW " legnie w gruzach " ? ;)
No to zamiast CRUDów będzie pisanie formatek w TensorFlow XD
i generalnie wydźwięk z tego był taki że w niedalekiej przyszłości potrzeba będzie więcej analityków , PM , ludzi znających biznes aniżeli programistow ze względu na to jak samo programowanie będzie wyglądać .
Może i będzie więcej, co nie znaczy, że będzie potrzeba. Posłów jest 460 w Polsce, a nie potrzeba ani jednego... Jest wiele niepotrzebnych zawodów, które jakimś cudem się utrzymują przy życiu. Może nawet ci programiści, którzy zostaną bezrobotni w erze AI, a będą sprytni, po prostu przekwalifikują się na PMów albo wymyśli się jakieś nowe bezsensowne zawody typu "Assistant to the Regional Manager".
Ja ostatnio czytalem artykul ze przyszlosc pracy jest kobieca, bo mezczyzni sie "wyautomatyzuja" poprzez pisanie AI. Zostana tylko miejsca pracy dla osob z "adaptability, improvisation, emotional intelligence, and implicit knowledge", czyli kobiet. Tega gloszona przez nasza rodaczke swoja droga. Juz zamowilem sobie miejsce na cmentarzu i sznur, bo co ja tu bede siedzial i smutkowal jak mnie AI wygryzie a nigdzie indziej nie dostane pracy ze wzgledu na plec.
Jak w 1900 roku we Francji wyobrażano sobie rok 2000?
https://publicdomainreview.org/collections/france-in-the-year-2000-1899-1910/
Jakoś te bootcampy inaczej dzisiaj wyglądają...
Przyszłość programowania to Swift i Crystal, ponieważ są najnowszymi językami programowania z 2014 roku, do tego Mikroserwisy.
To już było. Przykładem technologii, która miała pozbawić programistów pracy były języki 4 generacji, czyli specjalizowane języki wysokiego poziomu, próbujące się zbliżyć składnią do języka naturalnego (albo chociaż mieć tę składnię przystępną dla "ludzi"). Przykłady takich języków to SQL
, R
, Delphi
. Pomysł jest z początku lat 80 ubiegłego stulecia, programistów mamy o rzędy wielkości więcej niż wtedy.
gk1982 napisał(a):
Wynikiem prac dzisiejszych programistów są słabo zoptymalizowane programy ledwo wykorzystujące możliwości urządzenia.
Święte słowa. Co prawda już w czasach Amigi, ktoś kiedyś napisał, że gdyby z A500 wycisnąć tyle teoretycznie niemożliwych i niezakładanych nawet przez samych twórców cudów, ile się udawało z ZX Spectrum czy C64, to Amisia chyba wyleciałaby w kosmos, ale ten trend się pogłębia.
30 lat temu wystarczyła maszyna z 1MB RAM i kilkumegahercowym procesorem, żeby udźwignąć graficzne UI, teraz ładuje się Androida na potężnej (chociaż malutkiej) maszynie smarwatcha, po to, żeby wyświetlić kilka ikonek. A później się człowiek dziwi, czemu te urządzenia tak krótko działają na baterii.
Wynikiem prac dzisiejszych programistów są słabo zoptymalizowane programy ledwo wykorzystujące możliwości urządzenia.
Programiści gier wyciskają z kart graficznych siódme poty i stosują setki trików. Tutaj się to nie sprawdza
Berylo napisał(a):
Wynikiem prac dzisiejszych programistów są słabo zoptymalizowane programy ledwo wykorzystujące możliwości urządzenia.
Programiści gier wyciskają z kart graficznych siódme poty i stosują setki trików. Tutaj się to nie sprawdza
Bo oni jeszcze działają "na linii frontu" i po prostu muszą. (Inna sprawa, że co do optymalizacji współczesnych gier wydawanych na PC też można by dyskutować). Ale mnóstwo innych typowych zastosowań komputerów, z którymi radzono sobie jeszcze pod DOS-em jest realizowanych na zasadzie: potrzebny jest młotek, więc zamontujmy tu kombajn.
Coś w tym jest np. progs Cruciala do pokazywania SMART waży ponad 200MB i ładuje się pół minuty :)
Małe programiki można pieścić w nieskończoność w domowym zaciszu. Duże programy natomiast wymagają konkretnego inwestora i zespołu, który będzie rozwijał projekt przez wiele lat. Wydanie super-zopytmalizowanego prostego programu na maszynę czy system operacyjny sprzed 10 lat to bezsens z komercyjnego punktu widzenia. Ponadto szczerze wątpię, by dekady temu programy działały szybciej. Miałem kiedyś Pentium 133 MHz, 40 MiB RAM i Windowsa 98 niedługo po przełomie tysiącleci. Przeglądanie Internetu na tym to był dramat mimo iż JavaScriptu na stronach były wtedy skromne ilości. Jak brakowało RAMu to widziałem na własne oczy jak kontrolki w oknach się po kolei odrysowują - tak to wolno działało. Emacs powstał w 1976 roku i był swego czasu bardzo popularny. Przez swoją ociężałość był określony mianem "eight megabytes and constantly swapping" - skraca się to do "emacs", a 8 megabajtów oznaczało ilość dostępnego RAMu.
Jeśli chodzi o same demka (obojętne na Amigi czy nie) kontra gry AAA to czy demoscenowcy nie pracują przypadkiem jako programiści gier? A może ich talent się marnuje?
Wibowit napisał(a):
Miałem kiedyś Pentium 133 MHz, 40 MiB RAM i Windowsa 98
Nie wiem, jakieś ty strony wtedy oglądał. Przygodę z Internetem zaczynałam od P100 z 8 (albo) 16 MB RAM i Win95. Zasadniczym problemem była wydolność modemu, bo większe fotki potrafiło wczytywać nawet kilkadziesiąt sekund, ale strony jako takie renderowało mi dosyć sprawnie.
A z tą ekonomią jest trochę tak, jak z paleniem węglem. Oczywiście, że producentowi bardziej opłaca się zbudować Frankensteina rozmiarów słonia, któremu się po wierzchu dopisze obsługę otwierania słoików i wypuścić to jako super-otwieracz, ale gdyby ktoś kiedyś policzył, ile watów leci w kosmos z uwagi na takie podejście, to może by się okazało, że UE zamiast zabraniać żarówek żarnikowych powinna wspierać jakoś specjalizowane programy i platformy.
Freja Draco napisał(a):
Święte słowa. Co prawda już w czasach Amigi, ktoś kiedyś napisał, że gdyby z A500 wycisnąć tyle teoretycznie niemożliwych i niezakładanych nawet przez samych twórców cudów, ile się udawało z ZX Spectrum czy C64, to Amisia chyba wyleciałaby w kosmos, ale ten trend się pogłębia.
Co komu przyjdzie z napisanego w asmie, zoptymalizowanego pod konkretny sprzęt i szybko działającego CRUDa? To kwestia zwykłej matematyki - lepiej zapłacić 10 000 USD więcej za chmurę, niż ileś tam dziesiąt razy 120 000 USD za dodatkowych programistów.
30 lat temu wystarczyła maszyna z 1MB RAM i kilkumegahercowym procesorem, żeby udźwignąć graficzne UI, teraz ładuje się Androida na potężnej (chociaż malutkiej) maszynie smarwatcha, po to, żeby wyświetlić kilka ikonek. A później się człowiek dziwi, czemu te urządzenia tak krótko działają na baterii.
I jaką rozdzielczość była w stanie wyświetlić ta wspaniała maszyna, w porywach 240 x 320 x 4b ? Abstrahując od użyteczności smartwatch'y - takie Android Wear ładuje się tam jednak po coś trochę innego niż wyświetlenie kilku ikonek. To zresztą dość często spotykane przeświadczenie, że uruchamianie GUI z animacjami, kolorowymi obrazkami z działającą w tle komunikacją i masą innych procesów, albo renderowanie HTML to nic nieznaczące obciążenie w porównaniu do jakiegoś działającego na serwerze CMS'a serwującego gify z pierdzącymi kotami, czy tego słynnego CRUD'a. Chociaż potwierdza to tezę, że coraz mniej rozumiemy jak działa sprzęt.
piotrpo napisał(a):
Co komu przyjdzie z napisanego w asmie, zoptymalizowanego pod konkretny sprzęt i szybko działającego CRUDa? To kwestia zwykłej matematyki - lepiej zapłacić 10 000 USD więcej za chmurę, niż ileś tam dziesiąt razy 120 000 USD za dodatkowych programistów.
Mam znajomą, która programuje mikrokontrolery, więc komuś się nadal opłaca.
Sama też chętnie używałabym programowalnego smatłocza, który działałby przez rok a nie przez jeden dzień.
Abstrahując od użyteczności smartwatch'y - takie Android Wear ładuje się tam jednak po coś trochę innego niż wyświetlenie kilku ikonek. To zresztą dość często spotykane przeświadczenie, że uruchamianie GUI z animacjami, kolorowymi obrazkami z działającą w tle komunikacją i masą innych procesów, albo renderowanie HTML to nic nieznaczące obciążenie w porównaniu do jakiegoś działającego na serwerze CMS'a serwującego gify z pierdzącymi kotami, czy tego słynnego CRUD'a. Chociaż potwierdza to tezę, że coraz mniej rozumiemy jak działa sprzęt.
No właśnie, pytanie brzmi: po co ta masa procesów? I czy jedynym sposobem na wyświetlanie prostych grafik i tekstu jest renderowanie tego za pomocą html+css? Jakoś 20-letnie telefony potrafiły to robić bez odpalania pod spodem zasobożernego systemu operacyjnego.
ZTCP to kiedyś na tym forum zaciekle broniłem tezy, że Eclipse da się napisać w asemblerze. Teoretycznie da się, więc miałem rację :] Nawet istnieją już IDE napisane w asmie, np: https://fresh.flatassembler.net/
No właśnie, pytanie brzmi: po co ta masa procesów? I czy jedynym sposobem na wyświetlanie prostych grafik i tekstu jest renderowanie tego za pomocą html+css? Jakoś 20-letnie telefony potrafiły to robić bez odpalania pod spodem zasobożernego systemu operacyjnego.
Jak chcesz mieć bajery graficzne w UI to dobrze byłoby mieć akcelerator grafiki. Kiedyś miałem telefon (ZTE Blade) na Androidzie bez karty graficznej. UI potwornie zamulało. Potem miałem Galaxy S2, tam była już karta graficzna, więc UI śmigało. Gdyby okodować całe GUI w czystym asmie to może i bez karty graficznej można by mieć płynne UI - niekoniecznie dlatego, że klepanie w czystym asmie da lepsze wyniki niż optymalizacje w kompilatorze, ale dlatego, że jak już się koduje w asmie to wydajność stawia się na pierwszym miejscu.
Jeśli nie chcesz mieć bajerów graficznych to możesz kupić stary telefon, stary telewizor, stary samochód, itd Konsumeci jednak wolą świecidełka i głosują na nie portfelem.
Nie wiem jaka jest przyszłość programowania, ale wiem, że by się przydało programistom coś takiego
I to nie tylko do pracy w Emacsie.
Jak to bez karty graficznej: https://www.mgsm.pl/pl/katalog/zte/bladea452/ZTE-Blade-A452.html. :D
Freja Draco napisał(a):
Mam znajomą, która programuje mikrokontrolery, więc komuś się nadal opłaca.
Sama też chętnie używałabym programowalnego smatłocza, który działałby przez rok a nie przez jeden dzień.
Tak, też programowałem coś na uC, tylko zakres zastosowań (i złożoności projektu) jest nieco inny niż w przypadku np systemu bankowego, gdzie nagle się okazuje, że lepiej poświęcić parę cykli zegara w serwerze, niż kazać programistom szukać wycieków pamięci (tak, uproszczenie).
No właśnie, pytanie brzmi: po co ta masa procesów? I czy jedynym sposobem na wyświetlanie prostych grafik i tekstu jest renderowanie tego za pomocą html+css? Jakoś 20-letnie telefony potrafiły to robić bez odpalania pod spodem zasobożernego systemu operacyjnego.
To już kwestia rozważań typu po co mi 55" TV z rozdzielczością 4K jak wystarczyłby 20" czarno-biały CRT. Odpowiedź na pytanie sprowadza się do stwierdzenia, że ludzie chcą urządzeń, które są zawsze on-line, mogą wyświetlić sms'a, albo policzyć kroki w ciągu dnia, czy co tam to jeszcze robi.
Wibowit napisał(a):
Jeśli nie chcesz mieć bajerów graficznych to możesz kupić stary telefon, stary telewizor, stary samochód, itd Konsumeci jednak wolą świecidełka i głosują na nie portfelem.
No niestety. A później marudzą, że bateria pada po niecałej dobie.
Tymczasem w roku 1995, Casio VDB200B-1
piotrpo napisał(a):
To już kwestia rozważań typu po co mi 55" TV z rozdzielczością 4K jak wystarczyłby 20" czarno-biały CRT. Odpowiedź na pytanie sprowadza się do stwierdzenia, że ludzie chcą urządzeń, które są zawsze on-line, mogą wyświetlić sms'a, albo policzyć kroki w ciągu dnia, czy co tam to jeszcze robi.
Jedni chcą, drudzy nie chcą. Dla mnie ciekawym przykładem urządzenia jest dekoder telewizji kablowej. Mam taki, który po włączeniu do prądu potrzebuje chyba ze dwie minuty na start. A jedyne oczekiwanie, jakie stawiam temu urządzeniu, to możliwość przełączania kanałów. Wygląd grafiki mnie nie obchodzi, bo chcę oglądać to, co przygotował nadawca telewizyjny, a nie producent oprogramowania dekodera. Jest cała rzesza ludzi, którzy bardzo chętnie oddaliby tę niby to wyższą jakość grafiki, aby w zamian dostać urządzenie reagujące szybciej.
Mały Ogórek napisał(a):
Jak to bez karty graficznej: https://www.mgsm.pl/pl/katalog/zte/bladea452/ZTE-Blade-A452.html. :D
Nie trafiłeś z modelem, bo chodziło o ten: https://www.mgsm.pl/pl/katalog/zte/blade/
W sumie jak teraz patrzę na specyfikację to karta graficzna jest, aczkolwiek telefon działał tak jakby jej nie było :P UI mocno zamulało. Może miałem jeszcze gorszy model?
Freja Draco napisał(a):
Wibowit napisał(a):
Jeśli nie chcesz mieć bajerów graficznych to możesz kupić stary telefon, stary telewizor, stary samochód, itd Konsumeci jednak wolą świecidełka i głosują na nie portfelem.
No niestety. A później marudzą, że bateria pada po niecałej dobie.
Tymczasem w roku 1995, Casio VDB200B-1
W sensie czym tu się podniecać? Tym, że można spędzić cały dzień na obsłudze tego dziadostwa? Normalny człowiek chce przeglądać, wklepywać i używać dane jak najszybciej, więc wybierze smartfona do takich rzeczy.
Co do trzymania na baterii to telefon na Androidzie potrafi mi wytrzymać i kilkanaście dni jak go mało używam. Dopiero jak zacznę dużo korzystać z telefonu to rozładowuje się szybciej. Ale czego się można spodziewać? Ekran jest duży i jasny, więc sam z siebie ciągnie dużo prądu (nie ma tu znaczenia jak wydajne klepiemy programy, ekran zawsze ciągnie tyle samo prądu). Natomiast apki do obsługi smsów, książki telefonicznej, notatek i tego typu rzeczy wcale szybko baterii nie zarzynają. Włączone wi-fi non-stop też ciągnie prąd (dlatego wyłączam).