Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Gabriel Mlocik 27. 07. 2019, 13:59:24

Název: Váš názor na kombinaci několika technologií
Přispěvatel: Gabriel Mlocik 27. 07. 2019, 13:59:24
Zdravím, čo si myslíte o kombinácii eletron.js a golangu, s tým že bych k tomu pripojil ešte redis a noSQL databázu (couchdb alebo mongodb)?
Videl som že kolem toho vznikajú nejaké nové technológie, ako Equanox/gotron . Má zmysel takéto použitie pre desktop aplikáciu slúžiacu podobne ako redakčný systém od wordpressu?

*Viem že teraz asi touto otázkou naserem polovicu programátorov. :-D Ale jakožto programátor ktorý sa primárne zaujíma o jazyky JS a GO (ale taktiež sa trocha zaujíma aj o C a Scala), tak ma projekt gotron hodne zaujal. https://github.com/Equanox/gotron
Název: Re:Váš názor na kombinaci nekolik technologii.
Přispěvatel: jsl 27. 07. 2019, 22:45:25
Odpověď na to je jednoduchá. Odzkoušet to můžete. I po silnici III. třídy se dá jezdit letadlem nebo lodí. Otázkou je, jak Vám to bude moc drhnout nebo kolidovat s něčím dalším.
Název: Re:Váš názor na kombinaci nekolik technologii.
Přispěvatel: PetrK 28. 07. 2019, 12:21:47
Tento pristup naprosto schvaluju, cim vice takovychto bastliru, tim vic roste cena nas dobrych hochu co delame vonavoucke standardni aplikace v Jave jiz nekolik dekad 8) Takze jen do toho.

Jojo hosi, ne nadarmo jsou Java a jeji plagiat od Microsoftu nejpouzivanejsi platformy jiz nekolik desetileti  8)
Název: Re:Váš názor na kombinaci nekolik technologii.
Přispěvatel: Gabriel Mlocik 28. 07. 2019, 13:31:36
 ;D

čakal som takú reakci, ale že tam povieš "vonavucke ... v jave" tak to ma odrovnalo, Javu považujem za nejhorší a nejvíc humusácky jazyk vůbec.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: František Ryšánek 28. 07. 2019, 22:55:53
Cílevědomým bastlením = systematickým procházením slepých uliček, se člověk ledacos naučí. Občas i nějakou zapadlou perlu objeví... ale i zkušenost "tudy fakt ne" má svou hodnotu.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: gill 29. 07. 2019, 11:45:22
Psát Electron UI v Go je podle mě zbytečná komplikace. Raději bych se snažil použít klient server architekturu. V Elektronu se běžně používá.
Název: Re:Váš názor na kombinaci nekolik technologii.
Přispěvatel: Jaromír Adámek 29. 07. 2019, 15:29:07
;D

čakal som takú reakci, ale že tam povieš "vonavucke ... v jave" tak to ma odrovnalo, Javu považujem za nejhorší a nejvíc humusácky jazyk vůbec.

Připojuji se a podepisuji v plném rozsahu :D.
Ještě jsem nepotkal produkční ani neprodukční Java aplikaci, která by nedumpovala na paměť :).

Pro mě je Java synonymem žumpy.

Akorát to má jedinou výhodu, že cokoliv na Javě nepotřebuje naplánovat restarty, protože se to jednou za tři týdny otočí samo... lehne na paměť :D.

Java je takový ekvivalent časované bomby.

Ale jistě Java programátoři jsou placení dobře, stejně jako teď kdokoliv, kdo dělá v COBOLu. Mimochodem na mém posledním pohovoru byli nadšeni z toho, že jsem před 36ty lety programoval v BASICu :D, protože to nějaká banka používá dodnes!
Název: Re:Váš názor na kombinaci nekolik technologii.
Přispěvatel: Ondrej Nemecek 29. 07. 2019, 18:43:30
;D

čakal som takú reakci, ale že tam povieš "vonavucke ... v jave" tak to ma odrovnalo, Javu považujem za nejhorší a nejvíc humusácky jazyk vůbec.

Připojuji se a podepisuji v plném rozsahu :D.
Ještě jsem nepotkal produkční ani neprodukční Java aplikaci, která by nedumpovala na paměť :).

Pro mě je Java synonymem žumpy.

Což je ve vláknu o Eletronu dost vtipný komentář :D Eletron není moc krásná technologie a nenáročná na zdroje také úplně není. Ale chápu že zážitky z EJB a Jbossu se jen tak nezapomínají a staly se jaksi součástí koloritu, takže se nesmí propást žádná příležitost si zašpičkovat na téma java a paměť.

IMHO ony ty technologie mírně konvergují, paměťová náročnost Qt aplikací, Electron aplikací a JavaFX aplikací je dnes často srovnatelná, tj. poměrně vysoká. Komfort vývoje bude pravděpodobně také srovnatelný. Ostatní ekosystém se liší a podle něj by si měl tazatel vybírat - dle vlastních preferencí.

To je ale jen takový pokec.

Pokud mám mít nějakou věcnou a praktickou připomínku, tak snad jedině že doporučuju v každém prostřední nejdřív projít konvenční cestu a pak teprve zkoušel alternativu (v podobě gotron apod.) Protože bez zkušenosti se standardem nebude mít dotyčný na alternativu náhled a nezjistí, zda a jaký má potenciál či problémy. Ale chce to hodně času.

Jinak bych se spíš ptal přímo uživatelů těch systémů, na root se moc konkrétních připomínek tazatel asi nedočká.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Zdenek Henek 29. 07. 2019, 19:16:31
Zvaž toleranci zákazníka na chyby a délku jejich řešení. Podle toho dávej do svých řešení novinky.

Pokud ti výjde, že zákazník není moc tolerantní a případné chyby u zákazníka nebude z časových důvodů možné řešit, tak bych použil, co znáš nejlépe. I kdyby to měla být ta kritizovaná java.

U technologií se dívám také na jejich podporu po celou dobu předpokládaného životního cyklu aplikace. Pokud bude aplikace úspěšná může ji někdo používat i deset let. Zvládneš tomu dělat za rozumné peníze support?

Zdravím, čo si myslíte o kombinácii eletron.js a golangu, s tým že bych k tomu pripojil ešte redis a noSQL databázu (couchdb alebo mongodb)?
Videl som že kolem toho vznikajú nejaké nové technológie, ako Equanox/gotron . Má zmysel takéto použitie pre desktop aplikáciu slúžiacu podobne ako redakčný systém od wordpressu?

*Viem že teraz asi touto otázkou naserem polovicu programátorov. :-D Ale jakožto programátor ktorý sa primárne zaujíma o jazyky JS a GO (ale taktiež sa trocha zaujíma aj o C a Scala), tak ma projekt gotron hodne zaujal. https://github.com/Equanox/gotron
Název: Re:Váš názor na kombinaci nekolik technologii.
Přispěvatel: Idris 29. 07. 2019, 19:19:19
;D

čakal som takú reakci, ale že tam povieš "vonavucke ... v jave" tak to ma odrovnalo, Javu považujem za nejhorší a nejvíc humusácky jazyk vůbec.

Připojuji se a podepisuji v plném rozsahu :D.
Ještě jsem nepotkal produkční ani neprodukční Java aplikaci, která by nedumpovala na paměť :).

Pro mě je Java synonymem žumpy.

Akorát to má jedinou výhodu, že cokoliv na Javě nepotřebuje naplánovat restarty, protože se to jednou za tři týdny otočí samo... lehne na paměť :D.

Java je takový ekvivalent časované bomby.

Ale jistě Java programátoři jsou placení dobře, stejně jako teď kdokoliv, kdo dělá v COBOLu. Mimochodem na mém posledním pohovoru byli nadšeni z toho, že jsem před 36ty lety programoval v BASICu :D, protože to nějaká banka používá dodnes!
Aneb jak pravil po akvizici Sunu klasik: “Java’s fate rests on Oracle’s ability to polish poo.” :)
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: rooobertek 30. 07. 2019, 09:34:02
Pri nových veciach sa ti ľahko môže stať, že za pol roka ti skončí podpora a potom budeš musieť rozmýšľať, čo ďalej. Za dva roky to už ani neskompiluješ, lebo z nejakého dôvodu budeš potrebovať aktuálnejšie verzie iných nástrojov a tie si nebudú rozumieť s mŕtvym jazykom. Ja už som sa pár krát popálil, ale našťastie to väčšinou nebolo nič kriticky dôležité. Len to bola strata času, ktorý som mohol investovať do učenia sa niečoho iného.

Na druhú stranu, keby sa každý držal iba overených technológií, tak teraz asi všetci píšeme vo Fortrane a nikdy nevzniklo alebo sa nerozšírilo C, Java, PHP, Go... (nehodiace sa prečiarkni)
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondrej Nemecek 30. 07. 2019, 09:58:12
Zrovna u javascriptu mají frameworky leckdy jepičí život, ekosystém se taky dost mění. Pokud se tomu člověk věnuje na 100% procent, tak to asi nevadí, protože sleduje trend. Jako bokovka se to ale moc nehodí, režie se sledováním hype je značná.

To je třeba důvod, proč může být pro dost projektů java atraktivní. Spojuje progresivitu se stabilitou. Člověk si vybere jvm jazyk podle toho, jaké featury chce v jazyce mít, využije bohatý ekosystém, knihovny atd., zkompiluje do bytekódu a spustí nad jvm. To funguje už dnes. Pokud dozraje Graalvm budou možnosti ještě lepší. Je sice pravda, že s modulární javou se taky spousta věcí rozbilo, ale obvykle stačilo přidat pár přepínačů a funguje to dál bez dalších změn.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Idris 30. 07. 2019, 11:49:59
Na druhú stranu, keby sa každý držal iba overených technológií, tak teraz asi všetci píšeme vo Fortrane
Fortran není vůbec špatný.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Idris 30. 07. 2019, 11:51:12
nikdy nevzniklo alebo sa nerozšírilo [...] Java, PHP [...]
Občas prostě shit happens  :(
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: listoper 30. 07. 2019, 14:34:00
nikdy nevzniklo alebo sa nerozšírilo [...] Java, PHP [...]
Občas prostě shit happens  :(

Kdyz se na to podivam ocima stredniho managementu tak java je skvela:
1. I juniora snadno prodam zakaznikovi jako seniora, protoze to vypada, ze neco dela => vic penez pro me
2. vsechno trva dlouho => v pripade kontraktu typu "cas a material" vic penez pro me
3. Snadno se tam nasekaji chyby => vetsi rozpocet na udrzbu => vic penez pro me
4. Kdyz me to uz nebavi udrzovat, zdrazim a navrhnu zakaznikovi offshore outsourcing => Ja neponesu zodpovednost za spatny produkt a v asii to pohrbi tak dokonale, ze
5. Snadno uzavru se zakaznikem dalsi kontrakt na prepis systemu => vic penez pro me

Je to nadsazka, ale nas obor (aspon v korporatech) opravdu podobne funguje.
Technicka stranka muze byt druhorada.

A k OP: Jen do toho. viz seznam vyse. Cim komplexnejsi a zamotanejsi tim vic penez z toho kouka.  :)
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Gabriel Mlocik 30. 07. 2019, 14:41:50
Kdyz se na to podivam ocima stredniho managementu tak java je skvela:
1. I juniora snadno prodam zakaznikovi jako seniora, protoze to vypada, ze neco dela => vic penez pro me
2. vsechno trva dlouho => v pripade kontraktu typu "cas a material" vic penez pro me
3. Snadno se tam nasekaji chyby => vetsi rozpocet na udrzbu => vic penez pro me
4. Kdyz me to uz nebavi udrzovat, zdrazim a navrhnu zakaznikovi offshore outsourcing => Ja neponesu zodpovednost za spatny produkt a v asii to pohrbi tak dokonale, ze
5. Snadno uzavru se zakaznikem dalsi kontrakt na prepis systemu => vic penez pro me

Je to nadsazka, ale nas obor (aspon v korporatech) opravdu podobne funguje.
Technicka stranka muze byt druhorada.

A k OP: Jen do toho. viz seznam vyse. Cim komplexnejsi a zamotanejsi tim vic penez z toho kouka.  :)

 ;D tak toto je skvele.... to si vystihol... Však javisti ktorý zarábajú od počtu riadkov zarobia polovicu len psaním (resp. rovno generovaním jedním kliknutím) getterov a setterov.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondrej Nemecek 30. 07. 2019, 16:09:37
Kdyz se na to podivam ocima stredniho managementu tak java je skvela:
1. I juniora snadno prodam zakaznikovi jako seniora, protoze to vypada, ze neco dela => vic penez pro me
2. vsechno trva dlouho => v pripade kontraktu typu "cas a material" vic penez pro me
(...)

 :D Jedním slovem: Enterprise a neomezoval bych se jen na javu.

Teď ještě napsat podobný bonmot na javascript. Někde jsem viděl vtipný text co zažije js nováček, nebyl to nějaký komix? Nemohu najít...
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Idris 30. 07. 2019, 16:34:56
nikdy nevzniklo alebo sa nerozšírilo [...] Java, PHP [...]
Občas prostě shit happens  :(

Kdyz se na to podivam ocima stredniho managementu tak java je skvela:
1. I juniora snadno prodam zakaznikovi jako seniora, protoze to vypada, ze neco dela => vic penez pro me
2. vsechno trva dlouho => v pripade kontraktu typu "cas a material" vic penez pro me
3. Snadno se tam nasekaji chyby => vetsi rozpocet na udrzbu => vic penez pro me
4. Kdyz me to uz nebavi udrzovat, zdrazim a navrhnu zakaznikovi offshore outsourcing => Ja neponesu zodpovednost za spatny produkt a v asii to pohrbi tak dokonale, ze
5. Snadno uzavru se zakaznikem dalsi kontrakt na prepis systemu => vic penez pro me

Je to nadsazka, ale nas obor (aspon v korporatech) opravdu podobne funguje.
Technicka stranka muze byt druhorada.

A k OP: Jen do toho. viz seznam vyse. Cim komplexnejsi a zamotanejsi tim vic penez z toho kouka.  :)
No jo, jenže my, co píšeme kritické systémy, kde chyba může způsobit v lepším případě škodu za milióny, si tohle dovolit nemůžeme. Viz poslední průser Boeingu, kde šlo dokonce o lidské životy, to někdo parádně podělal.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: uetoyo 30. 07. 2019, 17:19:08
Na druhú stranu, keby sa každý držal iba overených technológií, tak teraz asi všetci píšeme vo Fortrane a nikdy nevzniklo alebo sa nerozšírilo C, Java [...]

Už s Fortranem tu byly jazyky, které se na něco hodily víc než Fortran (1957), třeba Lisp (1958). Není chyba jazyk, že není pro všechno vhodný, právě naopak. Dnešní Fortran je velice čitelný jazyk a má i některé věci, které bys tam nečekal (http://fortranwiki.org/fortran/show/Fortran+2008), třeba `pure` funkce http://www.lahey.com/docs/lfpro78help/F95ARPURE.htm
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: gill 30. 07. 2019, 17:22:37
Viz poslední průser Boeingu, kde šlo dokonce o lidské životy, to někdo parádně podělal.

to byla chyba senzoru.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Zdenek Henek 30. 07. 2019, 18:26:44
Viz poslední průser Boeingu, kde šlo dokonce o lidské životy, to někdo parádně podělal.

to byla chyba senzoru.

Ne nebyla to chyba senzoru.

1. Nekdo se neobtezoval pouzivat k detekci problem vic nez jeden senzor.

2. Nikdo to nekontroloval.

3. Nikdo z pilotu se o tom nedozvedel, protoze to nebylo ani v manualu aby se moho rict " Je to ten stejnej Boing jako poslednich 30 let, jen lepsi. Neni treba skolit piloty"

takze ve zkratce nekdo to paradne podelal.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Zdenek Henek 30. 07. 2019, 18:36:17
Viz poslední průser Boeingu, kde šlo dokonce o lidské životy, to někdo parádně podělal.

to byla chyba senzoru.

Ne nebyla to chyba senzoru.

1. Nekdo se neobtezoval pouzivat k detekci problem vic nez jeden senzor.

2. Nikdo to nekontroloval.

3. Nikdo z pilotu se o tom nedozvedel, protoze to nebylo ani v manualu aby se moho rict " Je to ten stejnej Boing jako poslednich 30 let, jen lepsi. Neni treba skolit piloty"

takze ve zkratce nekdo to paradne podelal.

Tady je link na zdroj.
https://medium.com/@jpaulreed/the-737max-and-why-software-engineers-should-pay-attention-a041290994bd

Chvili mi trvalo, nez jsem to nasel.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Gabriel Mlocik 30. 07. 2019, 19:05:08
No jo, jenže my, co píšeme kritické systémy, kde chyba může způsobit v lepším případě škodu za milióny, si tohle dovolit nemůžeme. Viz poslední průser Boeingu, kde šlo dokonce o lidské životy, to někdo parádně podělal.

Ten systém Boeingu určite nebol robený v Jave.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: oss 01. 08. 2019, 08:43:25
Zdravím, čo si myslíte o kombinácii eletron.js a golangu, s tým že bych k tomu pripojil ešte redis a noSQL databázu (couchdb alebo mongodb)?
Videl som že kolem toho vznikajú nejaké nové technológie, ako Equanox/gotron . Má zmysel takéto použitie pre desktop aplikáciu slúžiacu podobne ako redakčný systém od wordpressu?

*Viem že teraz asi touto otázkou naserem polovicu programátorov. :-D Ale jakožto programátor ktorý sa primárne zaujíma o jazyky JS a GO (ale taktiež sa trocha zaujíma aj o C a Scala), tak ma projekt gotron hodne zaujal. https://github.com/Equanox/gotron

Moj nazor je taky, ze je to pre uzivatela cele zle.
Kombinujes technologiu ktora sa tazko udrzuje, kde nie je stabilne ani padovanie stringu s technologiu, ktora ohrozuje uzivatelov statickym linkovanim a bezpecnostnymi dierami. pricom obe su extremne narocne na zdroje.

Ak chces robit rozumne multiplatformove gui proste pouzi QT, GTK, avaloniu...
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondra Satai Nekola 01. 08. 2019, 11:39:15
Viz poslední průser Boeingu, kde šlo dokonce o lidské životy, to někdo parádně podělal.

to byla chyba senzoru.

Kterou měl software zvládnout.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: listoper 01. 08. 2019, 12:46:23
Viz poslední průser Boeingu, kde šlo dokonce o lidské životy, to někdo parádně podělal.

to byla chyba senzoru.

Kterou měl software zvládnout.

To bylo X chyb najednou. Jedna z tech hlavnich bylo chybne rozhodnuti montovat na letadlo vetsi motory nez na jake bylo navrzeno.
Takovy veci se softwarem kompenzuji spatne.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondra Satai Nekola 01. 08. 2019, 12:57:44
Viz poslední průser Boeingu, kde šlo dokonce o lidské životy, to někdo parádně podělal.

to byla chyba senzoru.

Kterou měl software zvládnout.

To bylo X chyb najednou. Jedna z tech hlavnich bylo chybne rozhodnuti montovat na letadlo vetsi motory nez na jake bylo navrzeno.
Takovy veci se softwarem kompenzuji spatne.

Určitě to nebyla jedna chyba, ale celý řetězec.

Ty motory jsou část. Ale pořád něco, co by asi SW zvládnul, kdyby byl navrhovaný v rozumném prostředí s rozumným procesem. Ale pokud hnije všechno kolem, tak to musí postihnout i ten SW.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: PetrK 02. 08. 2019, 08:07:49
Hosi jde videt ze jste fakt amateri a nevite ktera bije. Takovihle amaetori to jsou takovi ti lidi, kteri kdyby v Jave programovali, tak spatne  8) Java je nejvetsi nigga ze vsech otevrenych platforem, v tom co dela je nejlepsi, je to nejstandardnejsi a nejfunknejsi vec. Za to, ze programatori udelali memory leaky nemuze Java, zpusobi to predevsim debilni management, ktery nedava dostatek casu na vyvoj a na udrzbu a do tymu nedaji alespon jednoho skveleho seniora. Java v soucasnosti stale nema zadnou konkurenceschopnou alternativu pro enterpsise backend.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: user398 02. 08. 2019, 09:22:53
Java v soucasnosti stale nema zadnou konkurenceschopnou alternativu pro enterpsise backend.

A čo hovoríš na PHP?
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Gabriel Mlocik 02. 08. 2019, 10:19:10
Hosi jde videt ze jste fakt amateri a nevite ktera bije. Takovihle amaetori to jsou takovi ti lidi, kteri kdyby v Jave programovali, tak spatne  8) Java je nejvetsi nigga ze vsech otevrenych platforem, v tom co dela je nejlepsi, je to nejstandardnejsi a nejfunknejsi vec. Za to, ze programatori udelali memory leaky nemuze Java, zpusobi to predevsim debilni management, ktery nedava dostatek casu na vyvoj a na udrzbu a do tymu nedaji alespon jednoho skveleho seniora. Java v soucasnosti stale nema zadnou konkurenceschopnou alternativu pro enterpsise backend.

Amatér si možno ty, v ostatných jazykoch než Java. Bastlíš si tam nezmysli. Na kilo kódu máš 2 kilá OOP balastu, 1 kilo setterov, getterov, a nevím čo ešte. OOP samotné chyba nieje, ale tak jak je implementovaná v Jave je chyba najväčšia. Popravde, pred nedávnnom na roote bol článok k tomu, kde v podstate odslova doslova vysvetlili čo vše je v Jave nezmysel. Viď odkazy:

https://sw-samuraj.cz/2019/02/remcani-proti-jave/
https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53

(práve ten druhý a tretí link, to je jak kdyby autor prečítal môj mozog, a všetko čo si myslím o Jave napísal v článku, sám když som to čítal bol som v šoku jak presne zhodný názor na to autor má, snaď až na výnimku že funkcionálne programovanie si nezmyslím že je jediná správna cesta, ale inak...).

Ak už inak autor OOP konceptu nadáva na najviac "moderný OOP" jazyk, tak asi neco na tom bude.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: rhubner 02. 08. 2019, 11:26:24
Ahoj,

Predem poznamenam ze programuji uz nekolik let v Jave a posledni 4 roky ve Scale(ale ne uplne ciste funkcionalne).

Elektronu a GO bych se nebal, jsou to uz zazite technologie a google napriklad hooodne investuje do GO. Ale s ostatnima technologiema bych trosku opatrnejsi(mozna v JS casti bych sel do Typescriptu). Ted neco napises a za 2 roky budou chtit opravu a nebudou mit na upravu tolik penez a ty na tom prodelas a nebo si udelat spatnou reputaci. Budou rikat ze to stalo tolik a tolik a ted to nemuzou pouzivat protoze chces xxx za opravu. Pripadne si muzes dohodnout nejaky mesicni udrzovaci poplatek a kazdy pulrok vydat novou verzi aby jsi predesel tomu ze ti projekt nepujde zkompilovat kdyz budes potrebovat udelat hotfix. Pokud nechteji platit udrzbu, tak jim predat i zdrojovy kod a rict ze s timhle to muzes kdokoliv upravit. Napriklad u ERP se bezne plati udrzovaci poplatek 10% rocne z implementacni ceny(vcetne dodelavek).

Jinak na backendu bych se drzel typovych jazyku. GO, Java, C#, Typescript .... Dokud je aplikace mala, tak to je sranda, ale jakmile se mi rozroste, tak se blbe dela refaktoring. V typovych jazycich to kontroluje prekladac a tak se delaji nektere opravy mnohem jednoduseji. V dynamickych jazicich je potreba psat vice automatizovanych testu.

Jako databazi bych asi pouzil SQLite. Mate silu SQL databaze a navic ji bude rozumet kazdej. Nic vam nebrani do SQLite ukladat JSON. Vykonu bych se nebal. Pokud prestane staci muzete prejit na nejakou vetsi databazi. Dokud jsou data mala(<100GB), drzel bych se SQL. Je to stabilni overena technologie a nemusite resit plno omezeni noSQL.

Radek
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: PetrK 02. 08. 2019, 11:29:32
Hosi jde videt ze jste fakt amateri a nevite ktera bije. Takovihle amaetori to jsou takovi ti lidi, kteri kdyby v Jave programovali, tak spatne  8) Java je nejvetsi nigga ze vsech otevrenych platforem, v tom co dela je nejlepsi, je to nejstandardnejsi a nejfunknejsi vec. Za to, ze programatori udelali memory leaky nemuze Java, zpusobi to predevsim debilni management, ktery nedava dostatek casu na vyvoj a na udrzbu a do tymu nedaji alespon jednoho skveleho seniora. Java v soucasnosti stale nema zadnou konkurenceschopnou alternativu pro enterpsise backend.

Amatér si možno ty, v ostatných jazykoch než Java. Bastlíš si tam nezmysli. Na kilo kódu máš 2 kilá OOP balastu, 1 kilo setterov, getterov, a nevím čo ešte. OOP samotné chyba nieje, ale tak jak je implementovaná v Jave je chyba najväčšia. Popravde, pred nedávnnom na roote bol článok k tomu, kde v podstate odslova doslova vysvetlili čo vše je v Jave nezmysel. Viď odkazy:

https://sw-samuraj.cz/2019/02/remcani-proti-jave/
https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53

(práve ten druhý a tretí link, to je jak kdyby autor prečítal môj mozog, a všetko čo si myslím o Jave napísal v článku, sám když som to čítal bol som v šoku jak presne zhodný názor na to autor má, snaď až na výnimku že funkcionálne programovanie si nezmyslím že je jediná správna cesta, ale inak...).

Ak už inak autor OOP konceptu nadáva na najviac "moderný OOP" jazyk, tak asi neco na tom bude.

Jo? A co sis teda nasel za alternativu k Jave, pochlub se, treba mate na Slovensku neco, co svet jeste neobjevil 8) Jestli je alternativa kombinace nekolika ruznych jazyku, tak navstiv doktora  8)

A co se tyce OOP, tak jde videt, ze neznas nejmodernejsi metodologie organizace zdrojoveho kodu, ktere se vyvinuly v Jave za poslednich 20 let, a delali to vetsi bedny nez si ty 8) Ty v tom proste hochu neumis  8) To, ze se na vsechno nehodi ultra OOP, to my experti co delame v Jave davno vime, ty ale jeste zrejme ne  8) Dneska je nejpopularnejsi plocha architektura, s rozdelenim na stateless tridy spojovanymi dependency injection, pojo objeky, se stridmym uzivanim typove hierarchie  8) A my experti v Jave, kdyz se nam to hodi, dovedeme udelat i highperformance asynchronni aplikace treba s Vertex  8) A ti nejvetsi experti, kdyz se jim to hodi, si muzou udelat i ultra OOP knihovnu  8)

Mas se synku jeste hodne co ucit 8)
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: redustin 02. 08. 2019, 11:42:23
Odkaz 1) Java - chybí rozumně udělaná kompozice (tj. vícenásobná dědičnost). Autoři Javy to samozřejmě ví a snaží se "tunit" interfacy, ale dokud v něm nebude interní field a protected metoda, je to pořád napůl.

Maven - máme projekt s 10tis. tříd a pom.xml jen několik. Je každého věc, jak si projekt rozseká do modulů. Ano, pluginy do mavenu jsou špatně kvůli verzování, ale nakonec nikdo jej nenutí, aby používal zrovna maven.

Odkaz 2) Bylo to tu diskutované nedávno, autor píše v JS a s Javou nemá větší praktické zkušenosti, to je vidět. FP rozhodně není řešením jím uváděných problémů.

Odkaz 3) Chyby OOP ukazuje na špatných modelech dědičnosti (např. obr. https://miro.medium.com/max/500/1*o-Mdcrd9B5hTrrQKhcP8yA.png ) . Opět dochází k tomu, že chybí (de)kompozice, což chybí.

Pevně věřím, že se rozhraní v javě postupně změní na variantu traitu. Již to tak pár let od zavedení defaultních metod používáme, ale citelně chybí fieldy a protected default metody, aby se nenafukovalo API.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Gabriel Mlocik 02. 08. 2019, 13:15:17
Jo? A co sis teda nasel za alternativu k Jave, pochlub se, treba mate na Slovensku neco, co svet jeste neobjevil 8) Jestli je alternativa kombinace nekolika ruznych jazyku, tak navstiv doktora  8)

A co se tyce OOP, tak jde videt, ze neznas nejmodernejsi metodologie organizace zdrojoveho kodu, ktere se vyvinuly v Jave za poslednich 20 let, a delali to vetsi bedny nez si ty 8) Ty v tom proste hochu neumis  8) To, ze se na vsechno nehodi ultra OOP, to my experti co delame v Jave davno vime, ty ale jeste zrejme ne  8) Dneska je nejpopularnejsi plocha architektura, s rozdelenim na stateless tridy spojovanymi dependency injection, pojo objeky, se stridmym uzivanim typove hierarchie  8) A my experti v Jave, kdyz se nam to hodi, dovedeme udelat i highperformance asynchronni aplikace treba s Vertex  8) A ti nejvetsi experti, kdyz se jim to hodi, si muzou udelat i ultra OOP knihovnu  8)

Mas se synku jeste hodne co ucit 8)

Nazývať seba expertom vypovedá o tom že expert nie si. Zaujímavé že som stretol už tucet expertov, i takých ktorý vraj programujú v Jave 10 rokov. A zaujímavé že ľubovolní 2 z nich, si každý definici OOP v Jave vysvetlil úplne inak. Každý to chápe úplne inak. A ešte aj tý medzi sebou sa hádajú, a jeden druhému tvrdí že v Jave nevie programovať. Tak potom kto vie v Jave programovať? Java je humus, kdyby nebol, nebolo by potreba sa učiť takové množstvo design patternov, refactoring by nespôsibil že kód sa zvätší viac než dvojnásobne, a nebol by v tom taký superchaos ako sa spomína v tretom článku s ešte jednoduchým kódom a už zložitým problémom o "Kopírke".
Java je grc. grc, ktorý bol ešte mnoho krát prehltnuť a znova vygrcán.
Ak si taký expert, tak určite vieš povedať čo také profesionálne si dokázal naprogramovať. Lebo zaujímavé že i autor Linuxu, ktorý je skutočný expert, moderné OOP kritizuje. Tak isto autor konceptu OOP, tak isto autor programovacieho jazyka ERLang. Atd atd. Zaujímavé že tý čo majú najlepší softvér kritizujú moderné OOP a Javu, či iné podobné jazyky ako C#, C++, PHP. Pritom kto kritizuje Golang? Len bezvýznamný programátori, čo napsali v podstate program komplexnosti "Hello World" (na kilometre ďaleko od Linuxu). Myslím že Linusov názor teda považujem že má omnoho omnoho väčšiu váhu, on sa môže nazývať profesionálom/expertom. Ty rozhodne nie. A to že všade cpeš okulárové smajlíky už jasne vypovedá o tom jak si "vyvinutý" nebo teda naopak. To čo si napsal, ma teda ešte viac ujistilo že Java je blbá, v podstate si ma presvedčil ešte viac o opaku než to čo si chcel.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: oss 02. 08. 2019, 13:30:00
Jo? A co sis teda nasel za alternativu k Jave, pochlub se, treba mate na Slovensku neco, co svet jeste neobjevil 8) Jestli je alternativa kombinace nekolika ruznych jazyku, tak navstiv doktora  8)

A co se tyce OOP, tak jde videt, ze neznas nejmodernejsi metodologie organizace zdrojoveho kodu, ktere se vyvinuly v Jave za poslednich 20 let, a delali to vetsi bedny nez si ty 8) Ty v tom proste hochu neumis  8) To, ze se na vsechno nehodi ultra OOP, to my experti co delame v Jave davno vime, ty ale jeste zrejme ne  8) Dneska je nejpopularnejsi plocha architektura, s rozdelenim na stateless tridy spojovanymi dependency injection, pojo objeky, se stridmym uzivanim typove hierarchie  8) A my experti v Jave, kdyz se nam to hodi, dovedeme udelat i highperformance asynchronni aplikace treba s Vertex  8) A ti nejvetsi experti, kdyz se jim to hodi, si muzou udelat i ultra OOP knihovnu  8)

Mas se synku jeste hodne co ucit 8)

Nazývať seba expertom vypovedá o tom že expert nie si. Zaujímavé že som stretol už tucet expertov, i takých ktorý vraj programujú v Jave 10 rokov. A zaujímavé že ľubovolní 2 z nich, si každý definici OOP v Jave vysvetlil úplne inak. Každý to chápe úplne inak. A ešte aj tý medzi sebou sa hádajú, a jeden druhému tvrdí že v Jave nevie programovať. Tak potom kto vie v Jave programovať? Java je humus, kdyby nebol, nebolo by potreba sa učiť takové množstvo design patternov, refactoring by nespôsibil že kód sa zvätší viac než dvojnásobne, a nebol by v tom taký superchaos ako sa spomína v tretom článku s ešte jednoduchým kódom a už zložitým problémom o "Kopírke".
Java je grc. grc, ktorý bol ešte mnoho krát prehltnuť a znova vygrcán.
Ak si taký expert, tak určite vieš povedať čo také profesionálne si dokázal naprogramovať. Lebo zaujímavé že i autor Linuxu, ktorý je skutočný expert, moderné OOP kritizuje. Tak isto autor konceptu OOP, tak isto autor programovacieho jazyka ERLang. Atd atd. Zaujímavé že tý čo majú najlepší softvér kritizujú moderné OOP a Javu, či iné podobné jazyky ako C#, C++, PHP. Pritom kto kritizuje Golang? Len bezvýznamný programátori, čo napsali v podstate program komplexnosti "Hello World" (na kilometre ďaleko od Linuxu). Myslím že Linusov názor teda považujem že má omnoho omnoho väčšiu váhu, on sa môže nazývať profesionálom/expertom. Ty rozhodne nie. A to že všade cpeš okulárové smajlíky už jasne vypovedá o tom jak si "vyvinutý" nebo teda naopak. To čo si napsal, ma teda ešte viac ujistilo že Java je blbá, v podstate si ma presvedčil ešte viac o opaku než to čo si chcel.

Ty musis mat z javy naozajstnu traumu, alebo ta ako maleho bili java programatori.
Odvolavat sa na Linusa, ktory je uz za zenitom je naozaj vtipne, hlavne vo svete OOP. Ked si clovek precita Clean code bude mt vetsie znalosti OOP ako Linus.
Este viac smiesny je pojem "najlepsi softver", ani omylom.
Vsteky tvoje argumenty boli vyvratene a ti si tu aj tak bezdovodne kopes do Javy, pricom tvoja povodna otazka bola o niecom uplne inom.
Hlavne, ziadnu s tych "slamenych pankov preco je OOP uplne zlo" Golang neriesi.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: redustin 02. 08. 2019, 13:32:11
nebol by v tom taký superchaos ako sa spomína v tretom článku s ešte jednoduchým kódom a už zložitým problémom o "Kopírke".

Proč by měla být kopírka potomkem tiskárny a skenneru? Kopírka je kompozitní zařízení, které uvnitř obsahuje obojí, ale rozhodně není přímým potomkem ani jednoho. Zřejmě implementuje spoustu společných rozhraní (Má napájení, má uživatelské rozhraní, atd.), ale implementace je úplně jiná. Navíc "umí tisknout" (jako tiskárna), "umí skenovat" (stejně jako skenner). Tiskárna i skenner jsou v kopírce od vnějšího světa odstíněné vrstvou kopírky. Všechno z toho lze rozpadnout do malých rozhraní, ale přímá dědičnost je rozhodně špatně. Možná to tak vypadá na první pohled, ale až by se autor dostal na detaily, zjistil by, že to v reálu dědičnost není. A každé nesprávné namodelování skutečnosti se u živého projektu jednou vymstí a bude se muset předělat. A tam nastoupí typová kontrola javy a předělání bude celkem bezbolestné a bezpečné, pokud se nepoužily nerefaktorovatelné techniky (reflexe a spol.).
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: KorporatniLopata 02. 08. 2019, 14:00:11
Každej, kdo věří tomu, že Java je na tom tak špatně jak tu prezentuje pan Mocik, by se měl striktně držet papírových peněz, protože bankovní systémy jsou postaveny z velké části na Javě. Ano, kompozice chybí a nezbývá než doufat, že Java bude pokračovat s vyzobavánim třešniček z ostatních jazyků, jak to dělala do teď. Ano, malé projekty lze napsat v něčem rychleji, ale jak roste projekt, produktivita se srovnává.
Jestli je na Javě něco super, tak že se poměrně dobře ví, kde nás tlačí bota a jak s limity jazyka pracovat.
Vůbec neberu takové ty kydy, že tvrzení X je pravda, protože to řekl Linus, spíš se snažím přemýšlet o samotném X. Nevím jak na tom je s OOP Linus, ale obecně: OOP je koncept, realizovat se dá různými způsoby, už podle toho, jak moc vnímám dědičnost jako fundamentální. Tohle je fakt diskuse na dlouho a snad by stála i za to, kdyby se vedla věcně, ale pokud někdo staví 360. e-shop v PHP, asi řeší úplně jiný typ problémů než někdo, kdo řeší infrastrukturu banky. Diskuse je pak fakt těžká.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Gabriel Mlocik 02. 08. 2019, 14:10:51
Každej, kdo věří tomu, že Java je na tom tak špatně jak tu prezentuje pan Mocik, by se měl striktně držet papírových peněz, protože bankovní systémy jsou postaveny z velké části na Javě.

K tomuto napíšu len jedno. Nepsal som nič o "nebezpečnosti" ale o tom jak je programovací jazyk špatný. To ale neznamená že pre uživatela je program naprogramovaný v Jave striktne "nebezpečný na použitie". Len tvrdím že to čo je naprogramované v Jave by v iných jazykoch šlo naprogramovať omnoho lepšie. To je veľký rozdiel.

Vsteky tvoje argumenty boli vyvratene a ti si tu aj tak bezdovodne kopes do Javy, pricom tvoja povodna otazka bola o niecom uplne inom.

to áno, ale kto tu prvý spomenul pojem Java? ne ja, ale "Javista".
Ešte k tomu ďalšiemu o Linusovi čo si psal. Kopíruješ moje argumenty. "Javista" tvrdí že je expert, a teraz urážate Linuse v podobnom význame? Pff... To vypovedá o logike "Javistov"...  A áno mám z Javy trauma, ako každý kto programuje udržitelný software, a nie problematický balast, u ktorého když chcete pridať nejakú funkcionalitu, tak to ovplivní beh 200 iných funkcionalít. Tady končím s kecmi o Jave. OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: uetoyo 02. 08. 2019, 14:49:42
Každej, kdo věří tomu, že Java je na tom tak špatně jak tu prezentuje pan Mocik, by se měl striktně držet papírových peněz, protože bankovní systémy jsou postaveny z velké části na Javě.

K tomuto napíšu len jedno. Nepsal som nič o "nebezpečnosti" ale o tom jak je programovací jazyk špatný. To ale neznamená že pre uživatela je program naprogramovaný v Jave striktne "nebezpečný na použitie". Len tvrdím že to čo je naprogramované v Jave by v iných jazykoch šlo naprogramovať omnoho lepšie. To je veľký rozdiel.

Vsteky tvoje argumenty boli vyvratene a ti si tu aj tak bezdovodne kopes do Javy, pricom tvoja povodna otazka bola o niecom uplne inom.

to áno, ale kto tu prvý spomenul pojem Java? ne ja, ale "Javista".
Ešte k tomu ďalšiemu o Linusovi čo si psal. Kopíruješ moje argumenty. "Javista" tvrdí že je expert, a teraz urážate Linuse v podobnom význame? Pff... To vypovedá o logike "Javistov"...  A áno mám z Javy trauma, ako každý kto programuje udržitelný software, a nie problematický balast, u ktorého když chcete pridať nejakú funkcionalitu, tak to ovplivní beh 200 iných funkcionalít. Tady končím s kecmi o Jave. OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?

Máte dost nedospělý pohled na svět. Dospělý člověk řeší problém, puberťák jazyk. "OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?" Ne.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondrej Nemecek 02. 08. 2019, 15:37:13
Odkaz 1) Java - chybí rozumně udělaná kompozice (tj. vícenásobná dědičnost). Autoři Javy to samozřejmě ví a snaží se "tunit" interfacy, ale dokud v něm nebude interní field a protected metoda, je to pořád napůl.

(...)

Pevně věřím, že se rozhraní v javě postupně změní na variantu traitu. Již to tak pár let od zavedení defaultních metod používáme, ale citelně chybí fieldy a protected default metody, aby se nenafukovalo API.

Přesně tak, rozhraní může být přeci i interní, kéž by to už v javě bylo! Omezení na veřejné metody v rozhraní mi přijde dost umělé a nesmyslné. IMHO by úplně stačilo mít vícenásobnou dědičnost s tím, že by rozhraní jen kontrolovalo přítomnost metod a nic jiného nenabízelo. Tak to ale v javě nebude, to je jasné. Místo toho se namísto tříd začnou víc používat rozhraní. Trochu absurdní řešení, ale dá se s tím asi žít.

Každopádně když jsem začal používat rozhraní s default metodama (traity) dalo mi to větší flexibilitu a svobodu, ale zároveň lepší konzistenci. Je to tak trochu lék na nadužívání hiearchie tříd a nepřítomnost vícenásobné dědičnosti. Ale ve stávající podobě to stále není kompletní.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondrej Nemecek 02. 08. 2019, 15:41:41
Máte dost nedospělý pohled na svět. Dospělý člověk řeší problém, puberťák jazyk. "OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?" Ne.

Nesmysl, dospělí lidé přeci taky řeší jazyky (byť rozhodně ne způsobem vedeným v této diskuzi).
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondrej Nemecek 02. 08. 2019, 16:00:56
Proč by měla být kopírka potomkem tiskárny a skenneru? Kopírka je kompozitní zařízení, které uvnitř obsahuje obojí, ale rozhodně není přímým potomkem ani jednoho. Zřejmě implementuje spoustu společných rozhraní (Má napájení, má uživatelské rozhraní, atd.), ale implementace je úplně jiná. Navíc "umí tisknout" (jako tiskárna), "umí skenovat" (stejně jako skenner). Tiskárna i skenner jsou v kopírce od vnějšího světa odstíněné vrstvou kopírky. Všechno z toho lze rozpadnout do malých rozhraní, ale přímá dědičnost je rozhodně špatně. Možná to tak vypadá na první pohled, ale až by se autor dostal na detaily, zjistil by, že to v reálu dědičnost není. A každé nesprávné namodelování skutečnosti se u živého projektu jednou vymstí a bude se muset předělat. A tam nastoupí typová kontrola javy a předělání bude celkem bezbolestné a bezpečné, pokud se nepoužily nerefaktorovatelné techniky (reflexe a spol.).

Takže můžete ty kompozitní části buď přímo vystavit  a pak je přímo voláte - copier.getScanner().scan() - anebo je schováte za rozhraní a voláte copier.scan() Druhý způsob lépe zapouzdřuje, ale přidává nějaký režijní kód navíc, kde se budou interně nejspíš jen volat metody kompozitu. V „opravdovém“ OOP by stačilo metodu přeposlat.

Při použití traitů můžete navíc, pokud jsou dobře navrženy, funkčnost skeneru přidat pouhým připojením toho traitu - s minimální nutností něco implementovat, protože sdílená funkčnost může být v tom traitu už implementovaná. Nově se bude implementovat například jen hardwarově závislá část, který zajistí získání InputStreamu apod. Zpracování a operace nad těmi daty bude v traitu. To samé pro tiskárnu. Stále při zachování toho, že kopírka nemusí dědit z tiskárny a skeneru. Pokud to shrnu, trait je v porovnání s dědičností flexibilnější způsob sdružování implementace do balíčků.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: redustin 02. 08. 2019, 17:09:37
Každopádně když jsem začal používat rozhraní s default metodama (traity) dalo mi to větší flexibilitu a svobodu, ale zároveň lepší konzistenci. Je to tak trochu lék na nadužívání hiearchie tříd a nepřítomnost vícenásobné dědičnosti. Ale ve stávající podobě to stále není kompletní.

No jasně, dědičnost a kompozice se doplňují, to není žádná náhrada. Proto jsou úchylné ty příklady údajně nefunkční dědičnosti, když jde ve skutečnosti o kompozici a dědičnost vůbec neměla být použitá.

Defaultní metody používáme úplně stejně, workaround, ale dá se. Nicméně holt budu mít public metody místo protected a sem tam nějaký field navíc, když jej nemohu strčit rovnou k rozhraní, ale pořád radši bezpečí typového systému + generik a možnosti nabízené kvalitním IDE Javy. Až to do javy dodělají, bude triviální public změnit na protected, příp. přesunout ty duplicitní fieldy z implementací rovnou do společného rozhraní/traitu.

Navíc spoustu komponent pracuje právě s jednou funkcionalitou/rozhraním/traitem, to už lze/je potřeba mít správně oddělené dneska.

Jenže to vše vyžaduje aspoň trochu kompetentního vývojáře, který nemíchá jablka a hrušky do jedné třídy a pak si stěžuje, že mu dědičnost hází klacky pod nohy.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Zdenek Henek 02. 08. 2019, 18:37:32
nebol by v tom taký superchaos ako sa spomína v tretom článku s ešte jednoduchým kódom a už zložitým problémom o "Kopírke".

Proč by měla být kopírka potomkem tiskárny a skenneru? Kopírka je kompozitní zařízení, které uvnitř obsahuje obojí, ale rozhodně není přímým potomkem ani jednoho. Zřejmě implementuje spoustu společných rozhraní (Má napájení, má uživatelské rozhraní, atd.), ale implementace je úplně jiná. Navíc "umí tisknout" (jako tiskárna), "umí skenovat" (stejně jako skenner). Tiskárna i skenner jsou v kopírce od vnějšího světa odstíněné vrstvou kopírky. Všechno z toho lze rozpadnout do malých rozhraní, ale přímá dědičnost je rozhodně špatně. Možná to tak vypadá na první pohled, ale až by se autor dostal na detaily, zjistil by, že to v reálu dědičnost není. A každé nesprávné namodelování skutečnosti se u živého projektu jednou vymstí a bude se muset předělat. A tam nastoupí typová kontrola javy a předělání bude celkem bezbolestné a bezpečné, pokud se nepoužily nerefaktorovatelné techniky (reflexe a spol.).

Bingo. Kompozice. Taky jsem došel do tohoto stavu. Trvalo to, ale cesta je cíl :).

Predka dvou tříd nedělám proto, abych mohl sdílet jejich "společné" metody. Kompozice a interface a společný kod do separatní třídy. Toto je v mnoha případech dostačující a mnohem lépe udržovatelné. A hierarchie vytvářím pouze pokud se jedná opravdu o nějaký subjekty s hierarchií.

I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied.

https://www.javaworld.com/article/2073649/why-extends-is-evil.html#talkback (https://www.javaworld.com/article/2073649/why-extends-is-evil.html#talkback)
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: redustin 02. 08. 2019, 19:09:08
interface a společný kod do separatní třídy. Toto je v mnoha případech dostačující a mnohem lépe udržovatelné.
Je, ale všichni víme, že to je workaround. Kdyby tu společnou funkcionalitu rovnou umělo ono "rozhraní", včetně dat, které by si uvnitř neslo (properties) a chovalo se jako normální trait nebo mixin... Ale ono to jednou přijde.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: PetrK 02. 08. 2019, 21:22:26
Kdyz delas architekturu plochou s dependency injection, tak prirozene potrebujes udelat domenove pojo tridy, a na tech pojo se skvele uplatnuje dedicnost.

Mimochodem kdyz se tu resily ty staticky a dynamicky typovane jazyky, tuhle jsem se setkal s nazorem, jaka ze to je rpuda, ze nemuzu v Jave pracovat primo s JSONem. Podle me je to blbost, v cem je problem udelat si tridu, ktera predstavuje ten json se kterym pracuju (a namapovat si JSON do te tridy). Neni v tom podle me vubec zadna prace navic u jakekoliv aplikace vetsi nez male a podle me to dokonce setri praci a dela poradek v kodu.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondrej Nemecek 02. 08. 2019, 23:42:23
Překvapuje mne vlažné rozšíření Groovy. IMHO jakýkoli javista může začít psát v Groovy a postupně adoptovat jeho vylepšení oproti javě. A přitom je to jvm jazyk.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: PetrK 03. 08. 2019, 08:35:30
Překvapuje mne vlažné rozšíření Groovy. IMHO jakýkoli javista může začít psát v Groovy a postupně adoptovat jeho vylepšení oproti javě. A přitom je to jvm jazyk.

Zbytecne, naco, proc by to nekdo mel chtit delat? to uz mi prijde lepsi nez Groovy Typescript. To uz bych se radeji naucil Python nez Groovy.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: uetoyo 03. 08. 2019, 11:20:18
Máte dost nedospělý pohled na svět. Dospělý člověk řeší problém, puberťák jazyk. "OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?" Ne.

Nesmysl, dospělí lidé přeci taky řeší jazyky (byť rozhodně ne způsobem vedeným v této diskuzi).
Ano, řešíme jazyky, ale ne na téhle úrovni. Takže jste to pochopil (?)
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Filip Jirsák 03. 08. 2019, 12:11:02
Překvapuje mne vlažné rozšíření Groovy. IMHO jakýkoli javista může začít psát v Groovy a postupně adoptovat jeho vylepšení oproti javě. A přitom je to jvm jazyk.
Podle mne je to tím, že přístup k syntaxi je v Groovy je přesně opačný než v Javě. Java je založená na tom, že každá věc se dělá právě jedním způsobem, takže když dva programátoři budou psát totéž, napíšou stejný kód. (Samozřejmě to neplatí úplně stoprocentně, ale v Javě je tenhle rys hodně silný.) Groovy naopak dává programátorovi spoustu možností, jak napsat jednu a tu samou věc. Takže když píšu nějaký kód, můžu ho napsat přesně tak, jak by se mi to líbilo. Problém ovšem je se čtením takového kódu. Groovy mi tímhle připomíná Perl… Jako skriptovací jazyk je Groovy super, closures zavedl dávno před tím, než měla Java lambdy, ale ta rozvolněná syntaxe je podle mne pro lidi zvyklé na Javu spíš matoucí. Je otázka, zda by se Groovy neuchytilo třeba spíš u lidí zvyklých na JavaScript.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondrej Nemecek 03. 08. 2019, 12:27:08
Máte dost nedospělý pohled na svět. Dospělý člověk řeší problém, puberťák jazyk. "OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?" Ne.

Nesmysl, dospělí lidé přeci taky řeší jazyky (byť rozhodně ne způsobem vedeným v této diskuzi).
Ano, řešíme jazyky, ale ne na téhle úrovni. Takže jste to pochopil (?)

Měl jsem na mysli, že bude skupina praktiků kteří budou řešit praktické problémy a volba jazyka pro ně bude víceméně vedlejší věc a pak tu bude skupina teoretiků či akademiků, kteří budou jazyky studovat případně vyvíjet nové. Potřebné jsou obě skupiny - dospělostí bych se neoháněl (byť v mládí člověka skutečně zpravidla zajímají ideály a v pozdějším věku víc praxe, nicméně ani to není 100% pravidlo).
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondrej Nemecek 03. 08. 2019, 12:30:53
Překvapuje mne vlažné rozšíření Groovy. IMHO jakýkoli javista může začít psát v Groovy a postupně adoptovat jeho vylepšení oproti javě. A přitom je to jvm jazyk.

Zbytecne, naco, proc by to nekdo mel chtit delat? to uz mi prijde lepsi nez Groovy Typescript. To uz bych se radeji naucil Python nez Groovy.

Mohl by to chtít dělat, protože je mu java příliš těsná a chce featury, která java nemá. Třeba ty lepší traity.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Ondrej Nemecek 03. 08. 2019, 12:40:18
Překvapuje mne vlažné rozšíření Groovy. IMHO jakýkoli javista může začít psát v Groovy a postupně adoptovat jeho vylepšení oproti javě. A přitom je to jvm jazyk.
Podle mne je to tím, že přístup k syntaxi je v Groovy je přesně opačný než v Javě. Java je založená na tom, že každá věc se dělá právě jedním způsobem, takže když dva programátoři budou psát totéž, napíšou stejný kód. (Samozřejmě to neplatí úplně stoprocentně, ale v Javě je tenhle rys hodně silný.) Groovy naopak dává programátorovi spoustu možností, jak napsat jednu a tu samou věc. Takže když píšu nějaký kód, můžu ho napsat přesně tak, jak by se mi to líbilo. Problém ovšem je se čtením takového kódu. Groovy mi tímhle připomíná Perl… Jako skriptovací jazyk je Groovy super, closures zavedl dávno před tím, než měla Java lambdy, ale ta rozvolněná syntaxe je podle mne pro lidi zvyklé na Javu spíš matoucí. Je otázka, zda by se Groovy neuchytilo třeba spíš u lidí zvyklých na JavaScript.

Máte nějaké příklady (nejsem Groovista)? Mě se líbí ta nulová bariára Java -> Groovy (Groovy používám na skriptování).
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: gill 03. 08. 2019, 12:53:14
Máte nějaké příklady (nejsem Groovista)? Mě se líbí ta nulová bariára Java -> Groovy (Groovy používám na skriptování).

nulovou bariéru má i Kotlin, na Androidu se prosadil. Groovy a Grails ve své době těžily z popularity Rails, ale na webovém backendu je JVM spíš nevýhoda než výhoda.

Mě se líbí ta nulová bariára Java -> Groovy (Groovy používám na skriptování).

Kotlin má k Javě ještě blíž. Na skriptování se víc hodí interpretované jazyky.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Filip Jirsák 03. 08. 2019, 14:04:20
Máte nějaké příklady (nejsem Groovista)? Mě se líbí ta nulová bariára Java -> Groovy (Groovy používám na skriptování).
Já také Groovy používám jen občas na skriptování, a potom v Gradle. Exemplárním příkladem je podle mne volání metod – závorky, jsou nepovinné, pokud je kód jednoznačný, pokud je poslední parametr closure, může být uvedený až za závorkami, volání setterů a getterů můžete napsat jako přiřazení/čtení do/z fieldu. Jasně, všechno to šetří „zbytečné“ psaní… Ale když jsem začínal s Gradle, tenkrát byla navíc ještě doporučovaná syntaxe s přetíženým operátorem <<, strašně těžko se mi orientovalo v dokumentaci a příkladech, protože jsem neustále musel pracně luštit, co je to vlastně za kód – je to volání metody? Je to přiřazení? Je to closure? Jasně, není to úplně čisté Groovy, Gradle je spíš další jazyk postavený nad Groovy a možnosti Groovy využívá do krajností. Ale o to více to vyniklo. Tím, že Groovy jinak používám pouze pro své skripty, bylo to vlastně poprvé, kdy jsem musel číst větší množství kódu napsaného v Groovy někým jiným. A díky tomu jsem si uvědomil, co mi na Groovy vlastně vadí. Ale pro soukromé skriptíky je fajn, stejně jako kdysi Perl.
Název: Re:Váš názor na kombinaci několika technologií
Přispěvatel: Sam Samovic 03. 08. 2019, 18:14:48
Viz poslední průser Boeingu, kde šlo dokonce o lidské životy, to někdo parádně podělal.

to byla chyba senzoru.
Ale prdlajz, jako vzdy slo o prachy. Boeing slibil ze vyrobi modifikaci bez nutnosti preskoleni. Zmenou motoru a jejich umisteni se posunulo teziste a motor to letadlo moc tahal. Proto tam udelali onen system ktery to mel regulovat. Dali tam DVA senzory, jenze kdyby to byl system zapojeny na DVA jednalo by se o kriticky system a NUTNE PRESKOLENI posadek. Takze to zapojili na jeden :-). A voala, vysledek vsichni zname.