Vlákno názorů k článku Nechte Go plavat, teď sviští Java od Humblee - To jsou pořád hádky...stejně ale nikdo, pokud nedělá...
-
Humblee (neregistrovaný)
To jsou pořád hádky...stejně ale nikdo, pokud nedělá jádro výkonově specifické aplikace, tak neoptimalizuje natolik, aby ho vytrhlo pár procent výkonu (a ten nepoužije ani C#, ani go, ani javu). Go je dobrej jazyk, Java je dobrá i C# je výbornej jazyk...
Jako hlavní rozdíl mezi GO a javou vidím v GO zprzněnou dědičnost a jinak v podstatě to samé, co jsou nevýhody C - chce to seniorního architekta, aby udržel rozsáhlejší projekt strukturálně čistý, rozhodně v tom nejde nic psát na první dobrou.
Aplikací tohohle pravidla pak vzniká jedinej rozdíl mezi vývojem v C# a v Javě. Outsourcing je pak zlatej důl pro firmu, když zaměstnají kdejakého ňoumu s jedním semestrem javy, aby to nějak zbastlil, náročnost svedou na Javu, zaplatit si nechají jako profesionála a mají vystaráno. To je hlavní důvod, proč se většina firma k javě nechá překecat. C# není v módě, aby se učil na pseudoškolách, člověk s ním přijde do kontaktu jen, když opravdu sám chce. Většinou s tím přichází i nějaká předchozí znalost programování v několika jazycích a pro takového člověka je C# jenom jedna z možností, jak aplikaci zapsat.Takový člověk už přemejšlí spíš nad návrhem, než aby se pral s tím, jak to zbastlit, aby to šlo zkompilovat a dělalo přibližně, co to dělat má. -
krecek (neregistrovaný)
C# ja hlavne donedavna wokna only, .Net Core je uplne nova zalezitost.
Takze v C# hlavne matlaj korporatni wokenni matlalove pro wokkenni "servery" a MSSQL.
Vsechny trochu rozumne backend aplikace bezej na Jave hlavne z toho duvodu, ze wokenice si da na backend jedine masochista.
A taky proto, ze C# ekosystem se s Javou nemuze merit. .Net runtime toho umi sice vic nez holy JVM, lec v pripade C# na teto urovni koncime.V Jave mame Apache Foundation a Maven central, na tohle C# nelepi ani omylem.
Vyhoda tohoto pristupu je hlavne v tom, ze samotna java se nezasira modnimi poryvy, samodna java je porad mala a jednoducha.
. Net Core ostatne vznikl prave proto, ze stary .Net nafukovanim tak zmolochovatel, ze uz to bylo do budoucna neunosne.Co se tyce .Net Core, je to zrejme poctive a slusne pojata iniciativa, ale proc chodit ke kovarickovi, kdyz muzu ke kovari...
-
dustin (neregistrovaný)
====
chce to seniorního architekta, aby udržel rozsáhlejší projekt strukturálně čistý, rozhodně v tom nejde nic psát na první dobrou.
====Udržení rozsáhlejšího projektu "strukturálně čistý" (jinými slovy "aby v něm nebyl bordel") vyžaduje vždycky zkušenosti, ať je psaný v čemkoliv. Ba dokonce bych řekl, že na použitém jazyce v tomto ohledu ani moc nezáleží.
-
IMHO to bylo spise mysleno tak, ze kdyz uz ujely cvicky a bordel vznikl, jsou jazyky a vyvojove prostredi, kde se to da jeste rozumne podchytit v zarodku a vycistit, nez se to zesere cele.
Treba Java IDE typu Eclipse/IntelliJ/Netbeans spolu s modularnim mavenem maji luxusni podporu refaktorizace, xml config validace apod.
V jave mi prijde na review nejaka hrozna spageta, a tam buch-buch "extrac method", "extract interface", "change method signature", "rename" a uz to lita. IDE se postara, ze se zmeny zpropagujou vsude.
V jazycich jako je C nebo GO to jde mnohem obtizneji a jenom rucne. Hlavne z duvodu neexistence vyjimek, v Jave muzes beztrestne kus kodu ze spagety extrahovat do metody, IDE samo automaticky prida potrebne throws klausule. V GO, kde mas dohromady zmatlany business kod a error handling to musis vypreparovat rucne, je to hrozny oser nachylny na chyby, casto je snazsi napsat zpraseny kod nacisto odznova.
-
dustin (neregistrovaný)
Tak to rozhodně, úpravy legacy kódu v Javě dělám úplně stejně. Máme to jako první krok každého změnového požadavku. Asi jsem ten původní post blbě pochopil.
Přesně proto "embedded" Javě fandím, protože i na kratší projekty se hodí používat kvalitní IDE a mít kód pořádně pod kontrolou. Píši teď trošku větší projekt (10+ funkcí) v octave a i obyčejné přejmenování funkce bolí. Ono to tedy bolí i v pythonu, který se pro větší věci běžně používá...
-
dustin (neregistrovaný)
Ani PyCharm není věštec a neumí spolehlivě rozeznat volání metody Class1.metodaA() od Class2.metodaA(), když se jmenují stejně, ale přejmenuji jen Class1.metodaA -> metodaB(). Type hinty u instancí sice pomáhají a PyCharm se snaží věštit ze všech sil, ale zdaleka ne tak, aby se na to dalo spolehnout. Proto se v pythonu snažím používat jména co nejpopisnější, aby se minimalizovala pravděpodobnost takovýchto kolizí.
Navíc spoustu "doporučovaných" postupů používá názvy metod/fieldů ve stringu (např. kontrola "vhodnosti" vstupních parametrů přes hasattr(), to už je úplná konečná).
-
Inkvizitor (neregistrovaný)
Kazdemo, co jeho jest, kazdy si pod pojmem uzivatelsky privetivy jazyk asi predstavi neco jineho. Mne treba u Javy vadi spousta veci - pocinaje jejim az dogmatickym lpenim na tridach a konce nemoznosti pouzivat normalni operatory pro uzivatelske typy (vcetne treba BigDecimal a spol.).
-
Inkvizitor (neregistrovaný)
Je to podobné, o tom žádná, ale nepřijde mi to moc hezké, je to asi na delší debatu. V C++ jsem programoval před lety, živím se hlavně Pythonem, z dalších jazyků se mi (z různých pohledů) líbí třeba Julia, Rust nebo Scala. Každý z těchto jazyků umí přetěžovat základní operátory, stejně jako to umí Lisp, Haskell, Ruby, C#, F#, Kotlin a já nevím, co ještě, každý jazyk to samozřejmě dělá po svém, pro některý je to prostě třeba infixová funkce, pro některý je na to trait, jiný zase má magické metody třídy...
Java i Go v tomhle z mého pohledu tragicky selhaly. Nepláču po >> z C++, ale u číselných typů bych rohodně čekal konzistenci.
ČLÁNKY DO MAILU