Python najbolj vroč programski jezik

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:)

Lonsarg je 4. avg 2018 ob 23:36 izjavil:

jukoz je 4. avg 2018 ob 09:54 izjavil:

Lonsarg je 4. avg 2018 ob 09:10 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.

janig je 5. avg 2018 ob 00:07 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.

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.

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? :))

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

Še vedno zadevo poganja C, ne Python.

krneki0001 je 5. avg 2018 ob 18:49 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.

hruske je 5. avg 2018 ob 18:38 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.

SimplyMiha je 5. avg 2018 ob 19:11 izjavil:

Mavrik je 5. avg 2018 ob 18:53 izjavil:

SimplyMiha je 5. avg 2018 ob 18:50 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.

BigWhale je 5. avg 2018 ob 11:45 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 5. avg 2018 ob 11:45 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.

krneki0001 je 5. avg 2018 ob 20:12 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).

janig je 5. avg 2018 ob 20:27 izjavil:

krneki0001 je 5. avg 2018 ob 20:12 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?

fm13 je 5. avg 2018 ob 21:40 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.

janig je 6. avg 2018 ob 00:00 izjavil:

krneki0001 je 5. avg 2018 ob 22:42 izjavil:

janig je 5. avg 2018 ob 20:27 izjavil:

krneki0001 je 5. avg 2018 ob 20:12 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.

krneki0001 je 6. avg 2018 ob 01:30 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?

jype je 6. avg 2018 ob 10:25 izjavil:

louser je 6. avg 2018 ob 03:58 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.

Mavrik je 6. avg 2018 ob 10:23 izjavil:

krneki0001 je 6. avg 2018 ob 01:30 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

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

krneki0001 je 6. avg 2018 ob 12:22 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?

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.

Python je za kalkulacije super.

Še boljši je Fortran.

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

ZaphodBB je 6. avg 2018 ob 18:27 izjavil:

Tako je vsi revolucionarji obrajtamo Kotlin!!

HAI 1.2
CAN HAS STDIO?
VISIBLE "HAIL ZAPHODBB!"
KTHXBYE