Vlákno názorů k článku Pohled pod kapotu JVM - vliv změn v syntaxi a sémantice Javy na strukturu bajtkódu od Palo - Clanok pekny len nesuhlasim s: > neklesající ceně za...
-
Palo (neregistrovaný)
Clanok pekny len nesuhlasim s:
> neklesající ceně za hodinu času práce programátorů je vlastně logické, že se stále více prosazují dynamicky typované programovací jazykyTo nema ziadnu logiku. Kto si mysli ze dynamicky typovy jazyk moze nahradit metriky, refactoring a staticku typovu kontrolu vo vacsom ako 200 riadkovom projekte tak nevie o com hovori. Pri dnesnej urovni podpornych prostriedkov ako su MDD nastroje a rozne funkcie IDE dynamicky jazyk nepredstavuje ziadnu vacsiu vyhodu.
Ziadny vacsi effort neexistuje. Jedine cim sa tieto jazyky lisia ze maju podporne kniznice postavene na vyssiu uroven programatorskeho API. Ked ale pride problem aj tak sa musite zakopat do nizsich urovni API. -
Dovolil bych si také mírně nesouhlasit :-). Samotné Pharo (Smalltalk) má jen v kódu metod momentálně cca 430 tis. řádků. Jako běžný zdroják by to s definicemi tříd, komentáři a mezerami mezi metodami dělalo něco přes 800 tis. řádků.
Díky architektuře Smalltalku a jeho primitivnosti jako jazyka je pro něj implementace refactorovacích nástrojů poměrně snadná, takže není divu, že se s nimi začalo právě tam. Že jste je neviděl, neznamená, že neexistují.
-
Radek Miček (neregistrovaný)
implementace refactorovacích nástrojů poměrně snadná, takže není divu, že se s nimi začalo právě tam.
A jak se třeba provádí přejmenování metody v dynamicky typovaných jazycích? Například, když několik různých tříd má metodu se stejným názvem a já se rozhodnu v jedné z těchto tříd metodu přejmenovat. Co se provede s kódem, který volal metodu s původním názvem? Co se provede s kódem, který volal nějakou metodu, jejíž název se shoduje s novým názvem přejmenovávané metody?
-
Honza (neregistrovaný)
Pokud několik různých tříd má metodu se stejným názvem, přejmenují se dané metody u všech těchto tříd, co se stane s kódem, ve kterém se poté volá metody, která není nikde implementovaná, je potom jasné, přejmenuje se také. O tom, kde všude se tak stane, mám přehled, vím, kde se metody volají, i které třídy je implementují. Druhou možností je metodu zkopírovat s novým názvem. Potom můžu starou metodu smazat, a to se bude týkat jen té třídy, kde to potřebuji. Všechny metody mám pokryté Unit Testy, které bych musel(měl) psát tak jako tak i ve staticky typovaném jazyce...
-
Honza (neregistrovaný)
"A když je nějaká z těch tříd součástí cizí/standardní knihovny?"
Udělám raději tu kopii metody, a pak původní smažu? Jinak jak píše Pavel níže, výv.prostředí mi to dá vědět, kde všude se ta metoda vyskytuje...
Testy mi řeknou, jestli někde bude chybět, a jestli to byl vůbec dobrý nápad :) proto. -
Pavel TišnovskýZlatý podporovatelTak ono je mnohdy hodne vyhodne vyuzivat moznosti obou svetu, proste skriptovaci jazyky na tvorbu proof of concept, nulte verze, na ktere zakaznik teprve pochopi, co vlastne chce.
Potom taky na slepeni logiky ale zaklad udelat treba v Jave. Resp. zalezi na konkretnim projektu, mnohdy vsak ani jedna strana netusi "ktera bije" a potom mi pripadne mnohem lepsi za par dnu slepit nejakej system treba v Jythonu a teprve az se zadani vyjasni na to nahnat Javisty.
-
Pavel TišnovskýZlatý podporovatel
Jeste bych pridal teoreticke vyhody jazyku jako je Clojure pro tvorbu programu pro paralelni systemy, ale popravde si pockam na to, az nekdo porovna nejaky realny prinos Clojure versus Java (teoreticky to totiz vypada dost dobre).
-
atarist (neregistrovaný)
Dovolim si jen pripomenout, ze pro nektere projekty se proste OOP jazyky moc nehodi a voli se spis jazyky funkcionalne orientovane. Ostatne vsechny dnes klasicke jazyky - C++, Java, Ruby... - maji dost vyznamne problemy na multijadrovych masinach, takze pokud nekdo hleda dalsi jazyk, s jehoz vyuzitim dokaze za par let vyrabet $$$, doporucuji bud Clojure nebo Erlang. Plicheni v C++/Jave nechte podprumernym bastlirum.
-
Ivan (neregistrovaný)
Zajimavy jazyky vznikaji i na .NET platforme. Treba tohle: http://nemerle.org
