Má Python budoucnost?

[JardaP .]

Panove, uvedomte si, ze nemyli-li se astronomove, Zeme ma pred sebou pouhych nekolik miliard let, nez bude sezehnuta  rozpinajicim se Sluncem a nejspise uz dlouho pred tim bude neobyvatelna. Na konci z ni zbyde sezehnuta planeta bez vody a prakticky bez atmosfery. Logicky budoucnost Pythonu nemuze byt delsi. ;-)

[Reklama]

[BoneFlute]

Mi to celé kazíš. Jsem se těšil jak si Kit zase naběhne...

To by ses načekal. Původně jsem ti chtěl napsat, ať si to strčíš do /dev/null, ale byl by to zbytečný příspěvek.

Zásadní výhoda testů je jejich separátnost. Tudíž můžeš dělat věci, které s typama jdou hůř¹. Jedním z pravidel TDD je, že se píše kód nebo testy; nikdy dohromady. Což vede k tomu, že se dá podchytit kdy ti implementace odjíždí od kontraktu.

Jako obvykle ses nevytasil s ničím světoborným. Tohle přece víme.

Četl jsem, že kdysi Enšpígl poradil krejčím, aby po navléknutí nitě do jehly nezapomněli udělat na jením konci uzlík.

Jsem rád, žes mě nesklamal :-)

[gl]

Záleží v jak blbém jazyce píšeš. Existují jazyky, který maj tak vymakanej systém typů, že se těžko vymejšlí, co ještě otestovat.

Největší fór je, že kdyby si opustil svůj dogmatickej svět, kde se testy píšou protože se píšou, tak by si objevil situace, kde testy jsou skutečně lepší než promakanej systém typů (za určitejch podmínek). Jenže to ti nechám jen jako hádanku. Zatím soudím, podle tvého vyjadřování, že netušíš :-P

V kterých situacích je lepší testovat?

Mi to celé kazíš. Jsem se těšil jak si Kit zase naběhne...

Zásadní výhoda testů je jejich separátnost. Tudíž můžeš dělat věci, které s typama jdou hůř¹. Jedním z pravidel TDD je, že se píše kód nebo testy; nikdy dohromady. Což vede k tomu, že se dá podchytit kdy ti implementace odjíždí od kontraktu.

¹ S typama to jde taky, třeba Elm má dost zajímavou featuru. Jen nevím, nakolik je to prototyp a nakolik production ready.

Implementace může odjíždět od kontraktu vždy. Výše jsi psal, že testování je lepší jen v některých situacích. V kterých situacích dokáže promakaný typový systém zabránit všem logickým chybám?

Ta featura na kterou vede odkaz se týká automatického určování čísla verze (snad jsem to pochopil správně). Jak to souvisí s testováním?

[mikrom]

A proc vubec musite vsichni pouzivat stejne IDE? To pouzivate nejake IDE-specific veci (fuj), nebo jaky je duvod?

Hovori sa tomu firemne standardy a stabna kultura. To sa vo vacsich firmach pozaduje vies ?

My sa dohodne, ake nastroje budeme pouzivat a potom to aj zdokumentujeme. To  znamena, ze mame interne manualy na vsetko, napriklad pre pripad, ze niekto dostane novy PC, tak otvori iba manual a tam ma step-by-step ake pluginy v STS si treba naisntalovat, jak si nastavi SourceTree, .. atd, aby na danom projekte mohol co najrychlejsie zacat pracovat. Plus mnoho dalsich navodov, napr. jak sa pouziva GitFlow, jak sa builduje SNAPSHOT, jak sa builduje release, ... atd. Je to pre pripad zastupitelnosti clenov teamu, aby si to skuseny kolega nemusel vsetko drzat v hlave alebo novy kolega nieco nedojebal.

Keby sme pripustili situaciu, ze Franta Noef bude pouzivat nestandardny nastroj, a potom nam zahlasi, ze nieco mu v nom nefunguje, tak mu ziadny iny kolega ktory pouziva standard nebude vediet s tym pomoct. A Franta Noef, namiesto toho, aby robil nieco uzitocneho zabije den tym, ze bude skumat jak si to svoje IDE nastavi, aby mu vsecko fungovalo jak ma.
A potom snad Frantu chyti depresia, ze to tu nezvlada, alebo ze ho nejako tyranizujeme a da nam vypoved, ked sme uz s nim pocitali a investovali tisice EUR do jeho vzdelavania. To by bol pruser.

Snad to teraz uz lepsie chapes - tych nastrojov je hodne a su zlozite a obcas su s nimi problemy - dal som ti tam i nejake linky.
Nejde vobec o to, ktore IDE je sracka, ale vyzaduju sa standardy a zastupitelnost.
V projektoch je vela prachov a manageri vyzaduju, ze vsecko musi byt standardizovane a zdokumentovane. Security s oblubou pouziva, ze je to pre pripad, keby cely team sedel v jednom lietadle.

[BoneFlute]

Implementace může odjíždět od kontraktu vždy.

No tak to je snad jasné. Ale u testů si toho snáz všimneš, protože ti spadnou.

Výše jsi psal, že testování je lepší jen v některých situacích. V kterých situacích dokáže promakaný typový systém zabránit všem logickým chybám?

Ta otázka je divně položená.
Promakaný typový systém dokáže zabránit všem logickým chybám, které dokáže podchytit.
Testování (ruční) dokáže zabránit všem logickým chybám, které kontroluješ.
Statický typový systém je podmnožina testování.
(Ale to jsem měl za to, že chápem.)

Ta featura na kterou vede odkaz se týká automatického určování čísla verze (snad jsem to pochopil správně). Jak to souvisí s testováním?

Testování stejně jako statické typování slouží (mimo jiné) k definování kontraktu. Podle rozdílu kontraktu se dá určit, který číslo v semver změnit. O tom byl ten odkaz.

[Reklama]

[BoneFlute]

A proc vubec musite vsichni pouzivat stejne IDE? To pouzivate nejake IDE-specific veci (fuj), nebo jaky je duvod?

Hovori sa tomu firemne standardy a stabna kultura. To sa vo vacsich firmach pozaduje vies ?

My sa dohodne, ake nastroje budeme pouzivat a potom to aj zdokumentujeme. To  znamena, ze mame interne manualy na vsetko, napriklad pre pripad, ze niekto dostane novy PC, tak otvori iba manual a tam ma step-by-step ake pluginy v STS si treba naisntalovat, jak si nastavi SourceTree, .. atd, aby na danom projekte mohol co najrychlejsie zacat pracovat. Plus mnoho dalsich navodov, napr. jak sa pouziva GitFlow, jak sa builduje SNAPSHOT, jak sa builduje release, ... atd. Je to pre pripad zastupitelnosti clenov teamu, aby si to skuseny kolega nemusel vsetko drzat v hlave alebo novy kolega nieco nedojebal.

Keby sme pripustili situaciu, ze Franta Noef bude pouzivat nestandardny nastroj, a potom nam zahlasi, ze nieco mu v nom nefunguje, tak mu ziadny iny kolega ktory pouziva standard nebude vediet s tym pomoct. A Franta Noef, namiesto toho, aby robil nieco uzitocneho zabije den tym, ze bude skumat jak si to svoje IDE nastavi, aby mu vsecko fungovalo jak ma.
A potom snad Frantu chyti depresia, ze to tu nezvlada, alebo ze ho nejako tyranizujeme a da nam vypoved, ked sme uz s nim pocitali a investovali tisice EUR do jeho vzdelavania. To by bol pruser.

Snad to teraz uz lepsie chapes - tych nastrojov je hodne a su zlozite a obcas su s nimi problemy - dal som ti tam i nejake linky.
Nejde vobec o to, ktore IDE je sracka, ale vyzaduju sa standardy a zastupitelnost.
V projektoch je vela prachov a manageri vyzaduju, ze vsecko musi byt standardizovane a zdokumentovane. Security s oblubou pouziva, ze je to pre pripad, keby cely team sedel v jednom lietadle.

Jsem příznivcem přesného opaku. Díky tomu, že Franta Noef (a nejenom on) používá své nástroje, tak je jednak kladen tlak na to, aby se do firemní dokumentace uvádělo co se robí, a nikoliv jak se to robí. Druhak se v praxi ukazuje, že heterogenní struktura pomáhá objevování vícero bugů, což znamená kvalitnější produkt tak nějak samo od sebe.

Standardy (více), a štábní kultura (méně) jsou rozhodně užitečná věc. Ale zrovna v případech které popisuješ je to jen projev lennosti, bez žádných objektivních výhod. IMHO.

No ale pointa je v tom, že pokud vám to tak funguje, a vyhovuje, ať je vám přáno. Ale já bych si u vás pracovat nepřál.

[mikrom]

Jsem příznivcem přesného opaku. Díky tomu, že Franta Noef (a nejenom on) používá své nástroje, tak je jednak kladen tlak na to, aby se do firemní dokumentace uvádělo co se robí, a nikoliv jak se to robí. Druhak se v praxi ukazuje, že heterogenní struktura pomáhá objevování vícero bugů, což znamená kvalitnější produkt tak nějak samo od sebe.

Ale ked napises do DOK iba co a nenapises jak, tak mozno niekto nebude vediet to jak. Mame vyvojarov, ktori su dobri v business problematike, ale nechcu moc riesit technicke veci. Ked nieco nevedia, pozru do  manualu ...

Sme samozrejme otvoreni aj novym myslienkam, a keby sa Franta Noef ukazal napr. po roku ze je totalny guru a ze jeho standard je lepsi a vyhodnejsi, pretoze nam podstane zvysuje produktivitu, tak by sme ho iste prijali a boli mu za to vdacni. Len by to musel aj zdokumentovat.

Standardy (více), a štábní kultura (méně) jsou rozhodně užitečná věc. Ale zrovna v případech které popisuješ je to jen projev lennosti, bez žádných objektivních výhod. IMHO.

Nemyslel by som, ze to je lenivost. Tieto vsetky administrativne veci, ako mat vsetko zdokumnetovane vyzaduje dost effortu - samozrejme popri tom co este programujes. Ja si myslim, ze je to tym, ze firma chce radsej istotu, ako nejaky pokrok.
Vyhodou je napr. zastupitelnost, nahraditelnost - nepotrebujes ziadnych guru, vies vymenit vyvojarov jako baterky. 
 

Ale já bych si u vás pracovat nepřál.

Chapem ta, kto je zvyknuty na iny pristup nemusi mat na toto zaludok ...
Ja napriklad neznasam kravatu, pretoze mam pocit, ze ma skrti

[BoneFlute]

Sme samozrejme otvoreni aj novym myslienkam, ...

To by snad ani nebyla mladá progresivní firma s neformální kulturou, kdyby tam tuhlenctu hlášku nedala :-)

[bsmk]

@Mikrom:
pravdepodobne precujete pre ten typ firmy ktory zamestnava tzv 'lopaty', pretoze potrebujete bud:
1. programatorov s praxou, ale bez vlastnych nazorov, skusenosti a zvykov
2. junior programatorov ktorych zaucite tak, ze su v podstate neuplatnitelni mimo vasej firmy pokial sa nevzdelavaju v sukromnom case.

pracoval som hned po skole v podobnej 'velkej firme', dost dlho mi trvalo kym som si uvedomil ze tam stracam cas, dakujem neprosim

[noef]

Hm, ale Franta Noef by v prve rade nenastoupil do vasi firmy, pokud se vynucuje neco, s cim nesouhlasi. Jak tedy dosahujete toho pokroku, kdyz nabirate jen lidi, co s tim musi souhlasit, naucit se to pouzivat a mozna za rok muzou zkusit neco maleho zmenit? To by museli mit firmu hodne radi, aby pretrpeli rok a pak mozna neco zmenili. Ale protoze pises, ze je potreba mit moznost vymenovat vyvojare jak baterky, tak to opravdu pusobi, ze chcete jen lopaty. Ale lopatam de tak maximalne o penize a teple misto, rozhodne nebudou posouvat firmu dal a stejne jako firma je vidi jako lehce nahraditelne, oni budou taky firmu videt jako lehce nahraditelnou - precejen pokud jim staci patlani vyvoj v jekomkoliv jazyce a IDE s jakymikoliv nastroji, tak nebudou mit zadny problem vas nahradit.

@Mikrom:
pravdepodobne precujete pre ten typ firmy ktory zamestnava tzv 'lopaty', pretoze potrebujete bud:
1. programatorov s praxou, ale bez vlastnych nazorov, skusenosti a zvykov
2. junior programatorov ktorych zaucite tak, ze su v podstate neuplatnitelni mimo vasej firmy pokial sa nevzdelavaju v sukromnom case.

pracoval som hned po skole v podobnej 'velkej firme', dost dlho mi trvalo kym som si uvedomil ze tam stracam cas, dakujem neprosim

+1

[manag]

Zase lopaty dostanou svejch 60 tisíc a připadaj si jako vývojáři, protože Franta od pásu má 16 Fakt cena hraje u lopat velkou cenu a dnes je moderní vzít radši více lopat než méně vývojářů.

[JardaP .]

@manag: Podle toho, co pises, tak musis byt totalne spickovym machrem vyvojarem aspon za pul melounu.

[davkol]

Tolik neberou ani v Silicon Valley.

[JardaP .]

Manag neni Silicon valley, urcite je lepsi.

[Ivan Nový]

Panove, uvedomte si, ze nemyli-li se astronomove, Zeme ma pred sebou pouhych nekolik miliard let, nez bude sezehnuta  rozpinajicim se Sluncem a nejspise uz dlouho pred tim bude neobyvatelna. Na konci z ni zbyde sezehnuta planeta bez vody a prakticky bez atmosfery. Logicky budoucnost Pythonu nemuze byt delsi. ;-)

Samozřejmě, že budoucnost Pythonu může být delší, když opustí sluneční soustavu :-))) Některé sekvence RNA, nebo DNA už trvají více než 3 miliardy let.