» »

Python najbolj vroč programski jezik

1
2
3

Isotropic ::

to verjetno firme, ki jim IT oz. development ni primarna dejavnost oz. ti analitiki delajo kaj specializiranega in ne dev?

Lonsarg ::

Seveda. Da bi firma z primarno dejavnostjo IT delala kaj v Pythonu bi bilo precej nenavadno:) No naročniki so vseh, morda kdo tudi izrecno naroči da hoče v Pythonu:)

Zgodovina sprememb…

  • spremenil: Lonsarg ()

Isotropic ::

web, django itd.
za kakšne manjše projekte sicer verjetno nebi bil problem...

krneki0001 ::

Lonsarg je izjavil:

jukoz je izjavil:

Lonsarg je izjavil:

Python je super za raziskovaono in analitično delo. Za pisat kodo za dejanske produkcijske sisteme pač me.


Lonsarg ima izkušnje s teoretičnimi produkcijskimi sistemi. Izkušenj z dejanskimi produkcijskimi sistemi pač ne.

Koliko firm pa si videl, da še nisi videl najbolj pogostega primera, kjer imajo analitiki in podobni oddelki Python (med drugim tudi interna produkcija brez podpore ITja), če pride do ITja pa se zadeve implementira v C#.


Ne drži čisto. Ogromno firm ima data warehouse (statistike, analitika, poročila) narejen v pythonu. Zato ker se zahteve spreminjajo celo na dnevni bazi in samo skripte popraviš, pri C# moraš pa buildat cel paket. In ja celo IT podpira tak sistem, ker je hitrejši in predvsem manj kompliciranja.
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster

janig ::

Ja sej, kaj bi sploh pridobil, ce bi sel to prepisovat v C#? Razen compile type safety, ki pa lahko z integration testi pokrijes.

AndrejO ::

janig je izjavil:

Ja sej, kaj bi sploh pridobil, ce bi sel to prepisovat v C#? Razen compile type safety, ki pa lahko z integration testi pokrijes.

V bistvu to pokriješ z unit testi ...

Pri majhnih projektih ne pridobiš nič. Ko pa začne projekt rasti po obsegu in kompleksnosti, pa se moraš vprašati kakšna je cena pisanja in vzdrževanja testne kode, če bi lahko enako funkcionalnost dobil "brezplačno" že z prevajalnikom.

Projekti, ki so rasli organsko, pogosto ostanejo pri tem, kar pač imajo, preprosto zato, ker je tudi cena kompatibilnega prepisovanja v drug jezik zaradi obsega in kompleksnosti predraga. Rešitev iz te zagate v ne-IT podjetjih je ta, da se potem da neko funkcionalnost razviti ponudniku tovrstnih rešitev, v IT podjetjih pa se začne pisati verzijo 2.0 potem, ko PM na projekt ne more dobiti več niti enega programerja, ker vsi raje dajo odpoved, kot pa zapravijo najbolj produktivna leta svoje kariere v pisanju testov, kot nadomestkov za prevajalnike.

fm13 ::

AndrejO je izjavil:


Pri majhnih projektih ne pridobiš nič. Ko pa začne projekt rasti po obsegu in kompleksnosti, pa se moraš vprašati kakšna je cena pisanja in vzdrževanja testne kode, če bi lahko enako funkcionalnost dobil "brezplačno" že z prevajalnikom.

Andrej, za obsežnejši projekt uporabiš Mypy. Zadevo podpirajo npr. Atom, PyCharm, VS Code... tako da zgornji pomislek bolj ali manj odpade.

BigWhale ::

Unit testi niso 'nadomestilo' za prevajalnik. V nobenem primeru. Type safety nekoliko olajsa razvoj in v teoriji nek kasnejsi debugging ampak nikakor pa
odpravlja unit testov. Unit teste se vedno pises in jih moras pisati. Se vedno nardis unit test, ki preveri input parametre.

Jaz sem delal na kar nekaj projektih, ki so bili pisani v Cju ali C++, kjer smo delali hardcore test driven development in smo teste pisali preden si spisal funkcijo.

Ce se gres test driven development, potem je overhead Python vs. C++ minimalen.

krneki0001 ::

BigWhale je izjavil:

Jaz sem delal na kar nekaj projektih, ki so bili pisani v Cju ali C++, kjer smo delali hardcore test driven development in smo teste pisali preden si spisal funkcijo.


Jaz to vedno počnem. Sicer v cobolu, ampak...
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster

hruske ::

En data scientist zelo lepo razloži zakaj uporabi Python za implementacijo HDBSCAN clustering algoritma. Za tiste, ki ne boste pogledali grafkov - najprej mu Python nudi scikit-learn knjižnico, ki že vsebuje infrastrukturo za primerjavo clustering algoritmov, numpy pa omogoča hitro računanje z matrikami. Ko je želel algoritem pohitriti, je uporabil Cython, ki ti kodo v Pythonu prevede v C ter skompajla (brez da bi se moral ročno ubadat s pointerji in alociranjem pomnilnika), ter poiskal ustreznejši algoritem za dani problem, tako da je na koncu njegova Python knjižnica dva velikostna reda hitrejša od "high-performance" implementacije v Javi.

Ampak ne, Python ni programski jezik, ane? :))
Rad imam tole državico. <3

SimplyMiha ::

je uporabil Cython, ki ti kodo v Pythonu prevede v C

jype ::

Tako je - nobene C kode mu ni bilo treba pisati, kar ga je naredilo približno stokrat bolj učinkovitega.

krneki0001 ::

"dva velikostna reda hitrejša od "high-performance" implementacije v Javi?"

Od kdaj je pa java merilo za hitrost?
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster

SimplyMiha ::

Še vedno zadevo poganja C, ne Python.

Mavrik ::

SimplyMiha je izjavil:

Še vedno zadevo poganja C, ne Python.


Ta stavek kaže fundamentalno nerazumevanje delovanja Cythona... in programiranja nasploh. C ne "poganja" v tem primeru prav nič.

krneki0001 je izjavil:

"dva velikostna reda hitrejša od "high-performance" implementacije v Javi?"

Od kdaj je pa java merilo za hitrost?


Odkar ima enega najhitrejših VMov z JIT/PGO.
The truth is rarely pure and never simple.

Zgodovina sprememb…

  • spremenil: Mavrik ()

hruske ::

krneki0001 je izjavil:

"dva velikostna reda hitrejša od "high-performance" implementacije v Javi?"

Od kdaj je pa java merilo za hitrost?


Noben jezik ni zagotovilo za hitrost. Obstajajo boljše in slabše implementacije algoritmov ki rešujejo dani problem. Tudi ni rečeno, da počasnejši algoritem ni ustrezen.

Lahko pišeš v najhitrejšem C-ju, kot je npr. Linux kernel, pa se ti zaradi nečesa tako trapastega kot so hash key collisioni upočasnijo vsi kontejnerji na sistemu. Ampak ta rešitev je bila čisto OK, dokler pač nismo začeli na en sistem tlačit krdela kontejnerjev.

Je pa res, da lahko razvijalec v katerem izmed jezikov, ki se izvajajo hitro, uporabi naivne implementacije rešitev za svoje probleme pa bo vsaj na njegovem razvojem sistemu še vedno delovalo hitro tudi za srednje velik nabor podatkov.
Rad imam tole državico. <3

SimplyMiha ::

Mavrik je izjavil:

SimplyMiha je izjavil:

Še vedno zadevo poganja C, ne Python.


Ta stavek kaže fundamentalno nerazumevanje delovanja Cythona... in programiranja nasploh. C ne "poganja" v tem primeru prav nič.


Cython prevede Python v C. Je tako? Se mogoče motim?

janig ::

hruske je izjavil:

En data scientist zelo lepo razloži zakaj uporabi Python za implementacijo HDBSCAN clustering algoritma. Za tiste, ki ne boste pogledali grafkov - najprej mu Python nudi scikit-learn knjižnico, ki že vsebuje infrastrukturo za primerjavo clustering algoritmov, numpy pa omogoča hitro računanje z matrikami. Ko je želel algoritem pohitriti, je uporabil Cython, ki ti kodo v Pythonu prevede v C ter skompajla (brez da bi se moral ročno ubadat s pointerji in alociranjem pomnilnika), ter poiskal ustreznejši algoritem za dani problem, tako da je na koncu njegova Python knjižnica dva velikostna reda hitrejša od "high-performance" implementacije v Javi.

Ampak ne, Python ni programski jezik, ane? :))

Ne ni pravi jezik! Pravo programiranje ni, da kaj pametnega napises, pravo programiranje je telovadba s pointerji v upanju, da ti uspe kaksna pointer magic mahinacija, da bo tvoj program hitrejsi od java implementacije. Ce pa tu in tam se malo assemblerja vrines si pravi car, in bo end user skakal od veselja, ker se bo program za 0.001 sekunde hitreje izvedel.

Zgodovina sprememb…

  • spremenil: janig ()

AndrejO ::

fm13 je izjavil:

AndrejO je izjavil:


Pri majhnih projektih ne pridobiš nič. Ko pa začne projekt rasti po obsegu in kompleksnosti, pa se moraš vprašati kakšna je cena pisanja in vzdrževanja testne kode, če bi lahko enako funkcionalnost dobil "brezplačno" že z prevajalnikom.

Andrej, za obsežnejši projekt uporabiš Mypy. Zadevo podpirajo npr. Atom, PyCharm, VS Code... tako da zgornji pomislek bolj ali manj odpade.

Niti ne odpade, ko se pogovarjaš o količini kode s katero se soočajo meni bolj domača podjetja.

hruske ::

SimplyMiha je izjavil:

Mavrik je izjavil:

SimplyMiha je izjavil:

Še vedno zadevo poganja C, ne Python.


Ta stavek kaže fundamentalno nerazumevanje delovanja Cythona... in programiranja nasploh. C ne "poganja" v tem primeru prav nič.


Cython prevede Python v C. Je tako? Se mogoče motim?


Ne, Cython prevede s tipi označen Python v binarno kodo, tako da se tisti del kode ne rabi interpretirat. Povedano drugače - omogoča ti da pospešiš časovno kritične dele kode brez da bi rabil vso kodo pisat v katerem izmed bolj štorastih jezikov.
Rad imam tole državico. <3

jype ::

janig je izjavil:

end user skakal od veselja
Če bo dočakal release.

AndrejO ::

BigWhale je izjavil:

Unit testi niso 'nadomestilo' za prevajalnik. V nobenem primeru. Type safety nekoliko olajsa razvoj in v teoriji nek kasnejsi debugging ampak nikakor pa
odpravlja unit testov. Unit teste se vedno pises in jih moras pisati. Se vedno nardis unit test, ki preveri input parametre.

Nikjer nisem napisal, da prevajalnik nadomesti unit teste ali unit testi prevajalnik. Dejstvo pa je, da je velik del unit testov (in tudi opazen del integration testov) pri Pythonu žal posvečen preverjanju, da aplikacija med izvajanjem ne bo počepnila zaradi malenkostne napake programerja ali pa spremembe v neki knjižnici s katero sicer nimaš nič, razen tega da jo uporabljaš.

BigWhale je izjavil:

Ce se gres test driven development, potem je overhead Python vs. C++ minimalen.

Noben izmed teh dveh jezikov ni ravno cvetka, ko pridemo do tega koliko stvari je možno odložiti na prevajalnik namesto na programerja. Pa tudi test-driven developmenta se na rabiš iti, da to opaziš, če si le količkaj dosleden pri tem, da imaš za svojo kodo spisane vsaj osnovne teste.

Mavrik ::

SimplyMiha je izjavil:

Mavrik je izjavil:

SimplyMiha je izjavil:

Še vedno zadevo poganja C, ne Python.


Ta stavek kaže fundamentalno nerazumevanje delovanja Cythona... in programiranja nasploh. C ne "poganja" v tem primeru prav nič.


Cython prevede Python v C. Je tako? Se mogoče motim?


Ne, Cython uporabi C kot vmesno obliko med prevajanjem v strojno kodo. :)
The truth is rarely pure and never simple.

krneki0001 ::

Mavrik je izjavil:

Odkar ima enega najhitrejših VMov z JIT/PGO.


Lahko ima najhitrejšega, ampak vse je odvisno od programerjev. Če je slabo sprogramirano nič ne pomaga.

Koliko milijonov transakcij na sekundo lahko tak VM z JIT/PGO obdela?
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster

krneki0001 ::

Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster

janig ::

krneki0001 je izjavil:

Koliko milijonov transakcij na sekundo lahko tak VM z JIT/PGO obdela?

Precej, ce napises kodo, ki se jo da enostavno paralelizirat in laufa v clustru namesto na mainfraimu (ce so te transakcije neodvisne med sabo).

fm13 ::

AndrejO je izjavil:

fm13 je izjavil:

AndrejO je izjavil:


Pri majhnih projektih ne pridobiš nič. Ko pa začne projekt rasti po obsegu in kompleksnosti, pa se moraš vprašati kakšna je cena pisanja in vzdrževanja testne kode, če bi lahko enako funkcionalnost dobil "brezplačno" že z prevajalnikom.

Andrej, za obsežnejši projekt uporabiš Mypy. Zadevo podpirajo npr. Atom, PyCharm, VS Code... tako da zgornji pomislek bolj ali manj odpade.

Niti ne odpade, ko se pogovarjaš o količini kode s katero se soočajo meni bolj domača podjetja.

OK, pač delaš z miljoni vrstic kode in ti python ne ustreza...

S tvojega linka sem sicer izvedel le, da Dropbox opušča razvoj svojega runtime-a (Pyston) ter da performančno kritične dele kode menja z učinkovitejšimi, napisanimi npr. v Go. A si hotel povedati še kaj drugega?

krneki0001 ::

janig je izjavil:

krneki0001 je izjavil:

Koliko milijonov transakcij na sekundo lahko tak VM z JIT/PGO obdela?

Precej, ce napises kodo, ki se jo da enostavno paralelizirat in laufa v clustru namesto na mainfraimu (ce so te transakcije neodvisne med sabo).


Koliko pa je to precej? 500? 1000? na sekundo?
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster

janig ::

krneki0001 je izjavil:

janig je izjavil:

krneki0001 je izjavil:

Koliko milijonov transakcij na sekundo lahko tak VM z JIT/PGO obdela?

Precej, ce napises kodo, ki se jo da enostavno paralelizirat in laufa v clustru namesto na mainfraimu (ce so te transakcije neodvisne med sabo).


Koliko pa je to precej? 500? 1000? na sekundo?

Kolikor rabis. Ce rabis vec, "dodas" vec nodeov v cluster, ce manj pa jih "vzames ven" (ce to lahko paraliziras).
Ja vem kaj mislis. Na mainframu bo COBOL outperformal javo v batch processingu, ker je bil narejen lih za ta namen.

AndrejO ::

fm13 je izjavil:

S tvojega linka sem sicer izvedel le, da Dropbox opušča razvoj svojega runtime-a (Pyston) ter da performančno kritične dele kode menja z učinkovitejšimi, napisanimi npr. v Go. A si hotel povedati še kaj drugega?

Samo to, kar sem že napisal. Python je odličen jezik, ima pa svoje omejitve, ki jih je dobro poznati.

BigWhale ::

AndrejO je izjavil:

Python je odličen jezik, ima pa svoje omejitve, ki jih je dobro poznati.


Seveda, saj to velja za prav vse programske jezike, od prvega do zadnjega. Torej zadnji del, da je potrebno poznati omejitve.

Ampak, ljudje, ki ponavadi hitijo razlagati o pocasnosti Pythona, ga ponavadi ne poznajo dovolj dobro in vecino stvari govorijo na pamet. Tisti, ki ga mogoce poznajo dovolj dobro, pa se spet sklicujejo na neke robne primere, ki jih verjetno 80% ljudi pri nas ne bo nikoli doseglo, kaj sele preseglo.

Disqus je bil do leta 2014 komplet napisan v Pythonu, sedaj so sicer nekatere stvari prepisali v Go ampak takrat so imeli 8 milijard pageview-ov na mesec in 50.000req/s.

krneki0001 ::

janig je izjavil:

krneki0001 je izjavil:

janig je izjavil:

krneki0001 je izjavil:

Koliko milijonov transakcij na sekundo lahko tak VM z JIT/PGO obdela?

Precej, ce napises kodo, ki se jo da enostavno paralelizirat in laufa v clustru namesto na mainfraimu (ce so te transakcije neodvisne med sabo).


Koliko pa je to precej? 500? 1000? na sekundo?

Kolikor rabis. Ce rabis vec, "dodas" vec nodeov v cluster, ce manj pa jih "vzames ven" (ce to lahko paraliziras).
Ja vem kaj mislis. Na mainframu bo COBOL outperformal javo v batch processingu, ker je bil narejen lih za ta namen.


Ne, ne mislim tega. Ko sem nazadnje debatiral z developerjem iz ene avstrijske banke, kjer imajo tak sistem kot ga opisuješ v javi, so obdelali uspešno nekje 1.5 milijona finančnih transakcij na uro. To je okoli 400 na sekundo.
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster

louser ::

jype je izjavil:

Tako je - nobene C kode mu ni bilo treba pisati, kar ga je naredilo približno stokrat bolj učinkovitega.

Jo je pa moral nekdo drug. Ampak le enkrat. Kar je nekako tudi point programiranja.

Zgodovina sprememb…

  • spremenilo: louser ()

Mavrik ::

krneki0001 je izjavil:


Ne, ne mislim tega. Ko sem nazadnje debatiral z developerjem iz ene avstrijske banke, kjer imajo tak sistem kot ga opisuješ v javi, so obdelali uspešno nekje 1.5 milijona finančnih transakcij na uro. To je okoli 400 na sekundo.


O kakih tranzakcijah ti sploh tu konstantno govoriš? Kaj majo tranzakcije (nekaj kar je omejeno z I/O in hitrostjo baze) veze s tem kako se koda v jeziku izvaja?
The truth is rarely pure and never simple.

jype ::

louser je izjavil:

Jo je pa moral nekdo drug.
Saj Python je napisan v C.

hruske ::

jype je izjavil:

louser je izjavil:

Jo je pa moral nekdo drug.
Saj Python je napisan v C.


Originalni Python je napisan v C, zato mu pogosto pravijo CPython. MicroPython je tudi v C. Potem je še Jython, napisan v Javi in omogoča lažjo uporabo Java knjižnic, IronPython pa je podobno za .NET. PyPy je napisan kar v Pythonu, ki se prevede v nekaj velikih C fajlov, ki prekompajlani ven pljunejo interpreter z JIT compilerjem (čista magija). Pa Google ima nekje še en prevajalnik, ki Python 2.7 kodo prevede v Go kodo.
Rad imam tole državico. <3

drola ::

win64 je izjavil:

Zanima me kaj pomenijo ikonice na sliki pod stolpcem types?
Kot razumem: če je phython(najbrž poganjan na linux napravi) označen kot embedded, potem so tudi vsi ostali na seznamu lahko...


Python ima kljukico pod embedded, ker obstaja https://micropython.org/ - implementacija Pythona za mikrokrmilnike.
https://drola.si

krneki0001 ::

Mavrik je izjavil:

krneki0001 je izjavil:


Ne, ne mislim tega. Ko sem nazadnje debatiral z developerjem iz ene avstrijske banke, kjer imajo tak sistem kot ga opisuješ v javi, so obdelali uspešno nekje 1.5 milijona finančnih transakcij na uro. To je okoli 400 na sekundo.


O kakih tranzakcijah ti sploh tu konstantno govoriš? Kaj majo tranzakcije (nekaj kar je omejeno z I/O in hitrostjo baze) veze s tem kako se koda v jeziku izvaja?


Recimo finančne transakcije:
begin transaction
    debit checking account
    credit savings account
    update history log
commit transaction
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster

BigWhale ::

krneki0001 je izjavil:


Recimo finančne transakcije:


Traktorji so bedni, ker gredo po ravnem sam 80km/h. Rabis fucking deset ur, da prides do Dalmacije. Totalno neuporabni.

Tko nekak se slisi tvoje konstantno nabijanje o teh transakcijah. Irrelevant je, tud ce bi implementacija tega kar omenajs v pythonu delala stokrat pocasneje kot v tvojem priljubljenem jeziku, katerikoli ze to je.

The right tool for the right job, je nekaj kar bo vedel vsak mal bolj izkusen programer in ne bo rinil z glavo skozi zid.

Probaj za foro implementirat Disqus v Cobolu in sporoci tvoje rezultate o hitrosti.

jype ::

Python itak njegovega cobola pelje scat na vsakem ovinku, zato pa tolk histerično otresa z njim.

krneki0001 ::

BW, si falil?
Jaz sem spraševal za javo, ki ima "najhitrejši VM" (kakor je gor nekdo omenil). Ne za python.
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster

Mavrik ::

krneki0001 je izjavil:



Recimo finančne transakcije:
begin transaction
debit checking account
credit savings account
update history log
commit transaction


Ne razumem zakaj misliš da je to kakršno koli relevantno merilo? Dolžina tranzakcije je odvisna od SQL stavka, tipa baze, vsebine baze in kupa drugih spremenljivk. Predvsem pa v večini primerov hitrost izvajanja nima nobene veze s programskim jezikom, ki RDBMS pokliče. S tje ti je padla ideja, da je lahko to kakršnokoli merilo primerjanja jezikov?
The truth is rarely pure and never simple.

BigWhale ::

krneki0001 je izjavil:

BW, si falil?
Jaz sem spraševal za javo, ki ima "najhitrejši VM" (kakor je gor nekdo omenil). Ne za python.


Saj vseen za kater jezik gre. Ravno to govorim. :)

krneki0001 ::

Ni res, je kr dost važno kateri jezik. Pythona recimo ne boš uporabljal za "core" bančništva, medtem ko bi nekateri radi to počeli v javi.
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster

hruske ::

Ubistvu je Python kar fajn za to. Vse računaš s centi in ker ima Python neomejeno natančna cela števila se ne rabiš bati, da boš prištel 1000 EUR na en račun in bo imel človek kar naenkrat -922.337.203.685.431,1201 EUR na računu.
Rad imam tole državico. <3

Unknown_001 ::

Python je za kalkulacije super.

Še boljši je Fortran.
Wie nennt man einen Moderator mit der Hälfte des Gehirnis ?

Begabt

Jarno ::

hruske je izjavil:

Ubistvu je Python kar fajn za to. Vse računaš s centi in ker ima Python neomejeno natančna cela števila se ne rabiš bati, da boš prištel 1000 EUR na en račun in bo imel človek kar naenkrat -922.337.203.685.431,1201 EUR na računu.


Brez skrbi, preverjanja vrednosti so skrbno implementirana.
Kolikor razumem, gre za tekoče delovanje sistema na izbrani arhitekturi.
Kaj pa boš tam pocal z generičnim podpornim jezikom, pa je že vprašanje načelnosti (like we cen do it).
Pred Pythonom je bila Java in nekateri so prerokovali revolutivni UntergangTM (Dr M.L. npr.) in deklasacijo ostalih jezikov.
#65W!

jype ::

Zdaj je Kotlin the shit in vsaj v primerjavi z Javo je res revolucija.

ZaphodBB ::

Tako je vsi revolucionarji obrajtamo Kotlin!!
"Naši dedje so se borili za to, da lahko odločamo
o lastni usodi - ne o usodi drugih ljudi." -jype

Unknown_001 ::

ZaphodBB je izjavil:

Tako je vsi revolucionarji obrajtamo Kotlin!!


HAI 1.2
CAN HAS STDIO?
VISIBLE "HAIL ZAPHODBB!"
KTHXBYE
Wie nennt man einen Moderator mit der Hälfte des Gehirnis ?

Begabt
1
2
3


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

IEEE: najpriljubljenejši jezik je Python

Oddelek: Novice / Ostala programska oprema
225961 (3478) Qushaak
»

Najbolj priljubljeni in osovraženi programski jeziki (strani: 1 2 )

Oddelek: Novice / Ostale najave
6921440 (16358) Kenpachi
»

Python najbolj vroč programski jezik (strani: 1 2 3 )

Oddelek: Novice / Ostala programska oprema
12225996 (20350) BigWhale
»

začetki programiranja

Oddelek: Programiranje
356724 (4799) Mavrik
»

programski jezik

Oddelek: Programiranje
303442 (2813) noraguta

Več podobnih tem