Jaki język programowania wybrałby wróżbita? ;)

1

Wyobraźcie, że umiecie przewidzieć przyszłość. To jakie według Was języki programowania będą się rozwijać a jakie umierać? ;)

Do założenia tematu zainspirował mnie ten temat:
https://www.quora.com/If-you-could-predict-one-language-that-will-take-over-the-programming-industry-over-C++-Java-Python-etc-which-would-it-be-Ruby-Perl-Haskell-Go-etc

a najbliżej mi do tej wypowiedzi ;)
"Perl is already dead.

Ruby will slowly die. It will die a death somewhat similar to Perl's but with less rancor and fewer people dancing on its grave. Basically Python's adoption by the science/mathematics crowd has relegated Ruby to being a language for Ruby nuts and Rails shops. This is all very similar to Perl's fate.

Python is crippled by its unthreadability. It's not going to take over. It's not going to die. It is going to linger on possibly with everyone not using version 3.x for the rest of time...

Functional languages will take market share away from Python in web back-end world and in data science world but will in no sense take over -- just as Common Lisp and Scheme never went mainstream neither will Clojure or Haskell, et. al.

Rust, Go, Dart, D, etc. will die outright. They will die deaths similar to, say, Dylan's death before them, orphaned by their creator or parent corporation without enough interest to be saved by the open source world at large.

C#'s future is bound to Microsoft's future. If Microsoft pulls off an eleventh hour miracle (and never count Microsoft out) and remains vital then C# will thrive. If Microsoft goes down, C# goes down with it.

Java will hobble on in pathos and ignominy.

Javascript is the only language that is written into browsers. Given the plodding pace of the browser implementation racket, it is the only language that will ever be written into browsers. This effectively makes it immortal -- no matter what happens with its bullshit server-side renaissance.

C++ will live on and on, bruised and scarred but unvanquished."

4

Gówniany temat, nie sposób przewidzieć, bo po 1. pojawiają się nowe języki, a dwa, stare wcale nie umierają. Ja widzę inny proces. Mianowicie odwrotność monopolizacji rynku przez dany język. Wróżbita zamiast stawiać na 1 język "przyszłości", powinien nauczyć się inżynierii oprogramowania, projektowania dobrej architektury i dobrych praktyk programistycznych, bo te nie zmieniają się z języku na język (tzn zmieniają, ale kluczowe elementy pozostają), to da sobie radę. Zresztą w przesiadce na coś nowego zwykle nie ma nic złego - bo w każdym nowym języku zazwyczaj pisze się łatwiej. Gorzej musieć się przesiadać na coś poprzedniego :P

0

Luźny temat, a nie gówniany. Właśnie chodzi o czysto subiektywne opinie jak to wszystko się będzie rozwijać ;)

5

R? :)

1
katelx napisał(a):

R? :)

R jest poza konkurencją bo jak wiadomo nie ma nic lepszego.

1

A może wybrał by Rust, jest już szybszy niż C++ i goni C
http://benchmarksgame.alioth.debian.org/u64q/rust.html

0

ja mysle, ze hybrydy jak Scala będą rosnąć w siłę lub ładnie się integrować w inne środowiska ;]

1
Biały Terrorysta napisał(a):

Wyobraźcie, że umiecie przewidzieć przyszłość. To jakie według Was języki programowania będą się rozwijać a jakie umierać? ;)

To wszystko zależy przede wszystkim od czynników ekonomicznych. Póki Microsoft będzie miał silną pozycję na rynku, to C# będzie popularny. Póki Oracle, Google i IBM będą mieli silną pozycję na rynku, to Java będzie się rozwijała. Ale może być też tak, że te 3 firmy przestaną istnieć, a Oracle i Javę wykupi jakaś inna firma i będzie dalej rozwijała Javę. Może być jeszcze tak, że Google do Android Studio wprowadzi jakiś inny język, np. Scalę albo wymyślą swój własny język i zaczną pomału rezygnować z Javy.
Myślę, że Objective-C nie ma przed sobą przyszłości, ale za to Swift będzie się rozwijał tak długo jak długo będzie istniał Apple i będą się sprzedawały ich produkty. Mogę się mylić, ale wydaje mi się, że Apple chce wymienić Objective-C na Swifta, choć do tego jeszcze bardzo długa droga.
Myślę, że JavaScript ma przed sobą przyszłość, choć nie przepadam za tym językiem dlatego nie cieszy mnie to.
Zastanawia mnie PHP. Wszyscy narzekają na ten język, ale patrzę, że firma Zend Technologies cały czas rozwija ten język.
Myślę, że C++ wciąż będzie popularny.

Ciekawie sytuacja by wyglądała gdyby ktoś spuścił bomby atomowe na Stany Zjednoczone i nagle Dolina Krzemowa przestałaby istnieć. Ciekawe które języki wtedy by pozostały i dalej by się rozwijały, a które przestałyby istnieć? :)

0

Nie wierzę w nowe języki.
Go. Dart. Rust.
Może jestem ignorantem, i może jakbym zaczął się ich uczyć, to uznałbym, że są to super języki przyszłości. Ale w tym momencie dla mnie to wygląda tak, że ktoś tworzy języki programowania albo dla zabawy, albo wierząc, że język jest srebrną kulą, która rozwiąże wszystkie problemy (komentuję zjawisko tworzenia nowych języków, a nie języki same w sobie).

Zastanawia mnie PHP. Wszyscy narzekają na ten język, ale patrzę, że firma Zend Technologies cały czas rozwija ten język.

nie wiem na czym polega ten rozwój, ale wg mnie idea rozwoju danego języka jest bardziej praktyczna niż tworzenie nowych języków. Widzę jak się JavaScript rozwinął od niepozornego języka, w którym nic nie było i wiele rzeczy robiło się partyzancko albo nie wygodnie do wygodnego i ekspresywnego języka (arrow functions <3 ), w którym na dodatek jest napisanych mnóstwo bibliotek, z których można skorzystać.

Które języki wymrą?
Wg mnie CoffeeScript. Zostanie może językiem of choice dla programistów Pythona czy Ruby'ego, którzy nie znają JSa, ale w dobie ES6 raczej CoffeeScript nie daje dużej wartości dodanej (skoro JavaScript w wersji ES6 już jest mocno ekspresywnym i wygodnym językiem).

TypeScript być może umrze, być może się utrzyma. Mógłby umrzeć, o ile Flow od Facebooka zdobędzie popularność (bo o ile się nie mylę, to używając ES6 oraz Flow można uzyskać podobny efekt co TypeScript). Ale być może popularność TypeScriptu się utrzyma. Angular 2 promuje TypeScripta (i Darta, ale tym się bym nie przejmował).

Używany we Flashu ActionScript to też raczej już język przeszłości (chociaż ciężko powiedzieć, czy JavaScript, ActionScript i TypeScript to inne języki, czy tylko dialekty EcmaScriptu)

Być może z JavaScriptem stanie się jak z Lispem - bedzie ileś konkurujących ze sobą dialektów i używanych do innych celów. W tej czy innej formie, przed JavaScriptem jest duża przyszłość.

0

JavaScript, fajnie jakby umarł :P

Mnie ciekawi jak Python sie bedzie rozwijal, ostatnio chyba nieco zwolnil tempa. W sumie z nowych rzeczy w Pythonie to Type Hints, fajny ficzer. Albo http://mypy-lang.org/ experimental optional static type checker.

Ale ogolnie dynamicznie typowane jezyki to zlo.

1

Gdybym miał strzelać - to przeżyje każdy i żaden. Rzeczy proste i wtórne będzie się wyklikiwać, a do rzeczy poważniejszych będzie się używać DSLi. I w jednym i drugim przypadku pod spodem będzie zapewne siedziało coś, co i teraz jest dosyć popularne.

0

Ktoś poruszył temat benchmarkow.

To według mnie zależy kto je robi. ;)
Czesto to kod w w jednym języku porównany do innego języka ze źlo zoptymlizowanym kodem.

np. node.js vs java jakos srednio chce mi sie wierzyc jak to jest porownywalny lub nawet szybszy.

1

Jaki język programowania wybrałby wróżbita? ;)

Wyobraźcie, że umiecie przewidzieć przyszłość. To jakie według Was języki programowania będą się rozwijać a jakie umierać?

Przecież to są zupełnie różne pytania. Aby były tym samym pytaniem, należy dodać zasadę, że "wróżbita wybiera język który będzie się rozwijać", albo odwrotną "wróżbita wybiera język który będzie umierać".

0

Czyli wszystko zależy od maszyny wirtualnej a nie języka (chociaż V8, na którym stoi NodeJS jest akurat dość szybką maszyną wirtualną). -

True. Ale, żeby bylo zabawniej widzialem testy udowadniające jak to Scala jest szybsza lub wolniejsza od Javy.
A JVM ten sam :P

1

Chciałbym połączenia erlanga z C-influenced składnią, która chula na JVM. NIe znalazłem jeszcze takiego.

0

Scala potrafi być szybsza niż Java w szczególnych przypadkach. Po prostu ma pewne mechanizmy, które potrafią generować lepszy bajtkod (np. makra, value-types, specjalizacja generyków albo RCO)

Potrafi być szybsza jak i wolniejsza. Przyjąłbym, że performance jest porównywalny.

0

@Krolik zgadzam sie i do tego pilem. Mozna napisac w scali tak, ze bedzie wolniej niz w java, ale bedzie to wina programisty.

Ale faktycznie moze nie wyrazilem sie jasno i byc moze faktycznie scala moze byc nieco szybsza.

0

Moim zdaniem w dobie coraz większych zarobków dobrych programistów oraz coraz większej mocy obliczeniowej wszelkich urządzeń, nawet petelni, coraz większe znaczenie będą miały języki z wysokim poziomem abstrakcji, pozwalające tworzyć oprogramowanie szybko, a nie konicznie najszybsze. Mam tu na myśli języki funkcyjne (funkcjonalne).

Oczywiście nie zastąpią one języków imperatywnych we wszystkich zastosowaniach, nie mam co do tego wątpliwości.

0

Moim zdaniem w dobie coraz większych zarobków dobrych programistów oraz coraz większej mocy obliczeniowej wszelkich urządzeń...

Zmartwię Cię, ale ze wzrostem mocy obliczeniowej jest ostatnio coraz bardziej krucho. Ostatnio Intel chwali się nowymi procesorami Skylake i w materiałach prasowych podaje dwukrotny wzrost wydajności względem Sandy Bridge, który ma prawie 5 lat.

Za to jak popatrzysz na pamięć, to tu jest jeszcze gorzej - opóźnienie się nie zmieniło prawie w ogóle przez ostatnie 5 lat i nadal wynosi ok. 70-90 ns niezależnie od tego, czy używasz DDR2, DDR3 czy przetaktowanych DDR4. Jedyne co się poprawiło, to przepustowość, ale... bez rewelacji. 4 lata temu kupiłem do laptopa pamięci 1600 MT/s, teraz producenci zapowiadają laptopy z DDR4 2400 MT/s, a w jakiejś dalszej nieokreślonej przyszłości może najdroższe modele będą mieć DDR4 2666. Typowe laptopy do kupienia w sklepach nadal mają DDR3 1333 lub 1600. Czyli mamy ok. 1,5x wzrost przepustowości w 4 lata.

... coraz większe znaczenie będą miały języki z wysokim poziomem abstrakcji, pozwalające tworzyć oprogramowanie szybko, a nie konicznie najszybsze. Mam tu na myśli języki funkcyjne (funkcjonalne).

Wcale nie jestem przekonany czy języki czysto funkcyjne pozwalają tworzyć oprogramowanie szybciej niż imperatywne. Ponadto w tej chwili niemal każdy język imperatywny ma też elementy wzięte z języków funkcyjnych i różnice się trochę zatarły. Wydaje mi się, że jeszcze bardzo długo programowanie obiektowe z domieszkami programowania funkcyjnego będzie dominującym paradygmatem. Nie zmienia się wygrywającego składu.

0

@Krolik: Nie stwierdziłem, że będzie dominować, tylko że będą zyskiwały coraz większe znaczenie. W językach funkcyjnych można rozwiązywać problemy szybciej (w znaczeniu czasu implementacji), lecz wymaga to zmiany sposobu myślenia - co dla wielu ludzi może być "nie do przeskoczenia".

Języki imperatywne przejmują cechy języków funkcyjnych z jakiegoś konkretnego powodu - zapewne takie podejście jest w pewnych sytuacjach bardziej korzystne.

Z całą pewnością istnieją problemy, które "łatwiej" rozwiązać imperatywnie, oraz takie, które "łatwiej" rozwiązać wykorzystując programowanie funkcyjne. Przykładami mogą być np. RB Tree, które w Ocamlu czy Haskellu można zaimplementować w kilkudziesięciu linijkach (razem z operacjami balansowania, dodawania elementów, usuwania...). Oczywiście złożoność asymptotyczna pozostaje taka sama, co więcej, korzystamy z trwałych (niemutowalnych) struktur danych. Przykładem, gdzie języki funkcyjne mogą zawodzić są np. elementy systemu wymagające niskich czasów dosępu - nie wyobrażam sobie sterownika karty graficznej napisanego w języku funkcyjnym.

Zgadzam się, że programowanie imperatywne będzie dominować. Programowanie funkcyjne będzie jednak zyskiwać na znaczeniu.

0

Ja jestem pewny jednego. Nie wygra najlepszy, ale najtańszy, najpopularniejszy, najpowszechniej używany.
Zawsze tak było i będzie tak do końca świata.

Z tych nowych wynalazków, które zawdzięczamy llvm to wątpię by coś podbiło świat. Poza nową składnią te języki nie ofiarują nic na tyle rewolucyjnego, by zupełnie wygryźć starych graczy.

1

Przykładami mogą być np. RB Tree, które w Ocamlu czy Haskellu można zaimplementować w kilkudziesięciu linijkach (razem z operacjami balansowania, dodawania elementów, usuwania...)

Ależ liczba linii kodu nie jest wyznacznikiem trudności napisania czy czytania kodu. Co z tego, że w Haskellu możesz napisać coś w 1/3 wielkości kodu imperatywnego, jak w tych 1/3 po prostu znacznie więcej się dzieje. Jest większa gęstość informacji, co z kolei spowalnia pisanie i czytanie. W rezultacie wychodzi prawie na to samo.

Poza tym w kodowaniu większość czasu schodzi na samo zastanawianie się, jak coś ma działać, a nie na klepanie kodu. Na wpisywanie kodu poświęcam 1% czasu w pracy, więc dla produktywności nie ma tak dużego znaczenia czy linii jest 100 czy 30. Dużo większe znaczenie dla produktywności mają dobre biblioteki i dobre narzędzia. To ładnie, że w Haskellu można napisać RB Tree w 5 linijkach, ale w Javie szybsze RB Tree jest w bibliotece standardowej i dzięki temu nie muszę go pisać. A niepisanie kodu będzie zawsze szybsze niż napisanie 5 linijek.

Z resztą posta się jednak zgadzam - wydaje mi się, że paradygmat funkcyjny będzie się dalej popularyzował, ale raczej w wersji "soft" (Java/Scala/C#/Python tj. OOP + obiekty immutable + lambdy), a nie "hard" (Haskell, OCaml).

PS.
Rust jest na pewno ciekawy, ale niestety jego twórcom udało się dokonać rzeczy niemal niemożliwej, czyli stworzyć kompilator powolniejszy od kompilatora Haskella i Scali (które słyną ze swej powolności). I taka jedna drobna rzecz potrafi zniwelować cały zysk z produktywności wynikający z np. fajnego zarządzania pamięcią i braku wieczorów spędzonych przy debugowaniu segfaultów.

0
Krolik napisał(a):

Poza tym w kodowaniu większość czasu schodzi na samo zastanawianie się, jak coś ma działać, a nie na klepanie kodu.

100% racji. Ale w przypadku języków funkcyjnych ideę często można zapisać wręcz dosłownie. Drzewa czerwono-czarne są trudne do zrozumienia dla początkujących programistów. Poprawne zaimplementowanie ich w np. C++ czy Javie wymaga rozpatrywania wielu przypadków, drabinek if-ów itd. Spójrzmy na implementację balansowania drzew czerwono-czarnych we wspomnianym Haskellu:

Deklaracja całej struktury drzewa:

data Color = R | B deriving Show
data RB a = E | T Color (RB a) a (RB a) deriving Show

Balansowanie:

balance :: RB a -> a -> RB a -> RB a
balance (T R (T R a x b) y c) z d
     || (T R a x (T R b y c)) z d
     || a x (T R b y (T R c z d))
     || a x (T R (T R b y c) z d) = T R (T B a x b) y (T B c z d)
balance a x b = T B a x b

Dla kogoś, kto zna ten język, zrozumienie stojącej za tym idei jest trywialne. Odtworzenie idei z kodu w Javie może stwarzać problemy.

// Kody pisane na szybko, proszę się nie czepiać ewentualnych niedociągnięć ;)

0

Dla kogoś, kto zna ten język, zrozumienie stojącej za tym idei jest trywialne. Odtworzenie idei z kodu w Javie może stwarzać problemy.

Dobrze zgoda, ale teraz spróbuj napisać w tym języku aplikację biznesową. Powodzenia.

Piszesz zbyt ogólnie. Niektóre języki/technologie sprawdzają się lepiej do danego typu zadania.

0
Sarrus napisał(a):

Niektóre języki/technologie sprawdzają się lepiej do danego typu zadania.
Tak, od początku o tym mówiłem :) Myślę, że w pewnym sensie doszliśmy do tego samego stanowiska. Cieszę się z interesującej dyskusji z Tobą.

0

A czy trzeba sie ograniczac do jednego paradygmatu?

1 użytkowników online, w tym zalogowanych: 0, gości: 1