Tu by som suhlasil, ale Java sa vlece ako slymak (hlemyzd). Vacsina
konstrukcii je uz preverenych v inych jazykoch ako napriklad funkcionaly v
Lispe, ... Suhlasim ze Java si udrziava kompatibilitu na urovni byte kodu.
Co sa tyka technologii, tak nie je smerodajny iba vyvoj. V mnohych firmach
sa
2011/7/18 Oto Buchta ta...@buchtovi.cz
2011/7/18 Pavel Kolesnikov pavel.kolesni...@gmail.com
Tady bych jen pro pořádek doplnil, že ten graf ne zcela pochopitelně
separuje Ruby a Rails, které dohromady budou na úrovni Pythonu. Zajímavý je
taky třetí graf ukazující nárůst poptávky.
Otázka
Nejvetsi problem java programatoru a nejen jich je v tom, ze
predpokladaji, ze s jednim jazykem si vystaci do konce zivota a proto
jej chybne pokladaji za svaty gral. Ani Java ani Ruby ani zadny dalsi
jiny jazyk neni svaty gral. V pripade aplikacnich frameworku to plati
mozna dvojnasob. Jirka
Jak jsi k tomu došel? Já osobně neznám ve svém okolí nikoho, kdo by si
myslel, že s jedním jazykem vystačí do konce života.
Možná si někteří myslí, že s jedním jazykem vystačí do konce svého
programátorského života, ale většina se podle mého názoru přechodu na
jiný jazyk nebojí.
Z.
--
Zdenek
Podepisuji :). Dokonce uz mame vsichni zadara i super transcript z
prednasky, diky za nej. Neni to krasa? Co se tyce Rails, zitra je
opustim, pokud se objevi neco jednodussiho. Technologie jsou jen
nastroj. Cil je pouze jeden: psat lepsi software.
Diky,
Jirka
2011/7/18 Roman Pichlík
Ja zase znam techto pripadu hafo. V Kyberii jsem to uz vymlatil, ale
ve firmach, kde jsem mel moznost pracovat nebo pro ne dodavat reseni
jsem na tyto programatory narazel porad. Potiz byla v nepruznosti a
lenosti. Az jsem se divil, s jakou vervou nekdo obhajoval CVS, aby
nemusel prechazet na SVN,
Řeč ovšem byla o jazyku, ne o nástrojích. Navíc to, že má někdo zdrženlivý
postoj ke změně jazyka na konkrétním projektu, neznamená, že je obecně
proti změně, ale třeba jen nevidí pro daný projekt žádný přínos nebo má s
daným jazykem svoje zkušenosti. Jsem si téměř jistý, že kdyby se objevil
nový
Ohledne velikosti systemu jsem vazan a neco jsem zminil na prednasce,
ale mohu uvest velikost v radech:
--poctu trid modelu : rad stovek
--pocet testu : rad tisicu
--velikost databaze: rad desitek GB u jedne z mnoha databazi
--pocet serveru: rad desitek
--pocet vystridanych programatoru: rad
Potiz je IMHO v tom, ze se velmi jednoduse zameni rozumny odpor s
lenosti. Pokud je odpor ke zmene vysledkem vlastni osobni zkusenosti,
pak je vse v poradku. Pokud je odpor vysledkem nebudu to zkouset,
protoze to ASI nebude fungovat, pak je to pruser. Z me praxe je to
prave spise ta druha moznost.
Já tedy nevím, ale nemohl by se tu už někdo zeptat zase něco o JAVĚ? A Ruby
se jít bavit do Ruby fóra?
Ne že by to nebylo zajímavé, ale radši bych si tu četl o Javovských tématech
:-)
Libor
2011/7/18 Jiří Hradil ji...@hradil.cz
Potiz je IMHO v tom, ze se velmi jednoduse zameni rozumny odpor
Ale lenost zmenit system je naprosto pochopitelna !
Kdyz mate firmu kde je treba 30 programatoru kteri jedou v jednom jazyku,
jsou celkem dobry, funguje zastupitelnost, jsou osahany nastroje, bezi
projekty at uz udrzba a nebo vyvoj, Navic pro budouci zakazniky mohu
mit reference z X projektu
Tady bych jen pro pořádek doplnil, že ten graf ne zcela pochopitelně
separuje Ruby a Rails, které dohromady budou na úrovni Pythonu. Zajímavý je
taky třetí graf ukazující nárůst poptávky.
Pavel
2011/7/16 Zdeněk Troníček troni...@fit.cvut.cz
Dobrý den,
myslím, že při rozhodování, kterému
2011/7/18 Pavel Kolesnikov pavel.kolesni...@gmail.com
Tady bych jen pro pořádek doplnil, že ten graf ne zcela pochopitelně
separuje Ruby a Rails, které dohromady budou na úrovni Pythonu. Zajímavý je
taky třetí graf ukazující nárůst poptávky.
Otázka zní: Je opravdu větší požadavek na pracovní
Ako uz bolo spomenute nic(hocijaka technologia,hocijake rozhodnutie) nieje
idealne, vzdy je to o prioritach.
enterprise technologie:
Podla mojej klasifikacie jednym z hlavnych znakov(prioritou) enterprise
technologie je dlhodoby support.
A RoR ma podla mna vsetky charakteristiky enterprise
Hlavnym konkurentom javy je podla mna ozaj .net ten ma ten korporatny
support, a nema javovsku vlastnost roztriestenost ktora ubera podla mna
energiu jave. Energia sa nedeli ako je to u Javy ale ide jednym smerom. A v
konecnom dosledku je asi vyvoj rychlejsi, a teda tiez lacnejsi(technologie
Tohle platí nejen v oblasti frameworků, ale třeba i pro vlastnosti jazyka.
Do produkčního jazyka jako je Java by neměly být přidávány neprověřené
konstrukce, protože to může napáchat více škody než užitku. Lepší je
počkat, zda se tyto osvědčí jinde (např. v nějakých experimentálních
jazycích) a
Dobrý den,
myslím, že při rozhodování, kterému jazyku či technologii se profesionálně
věnovat, je dobré se podívat na počty pracovních míst, které jsou pro
tento jazyk či technologii nabízeny.
Viz např.
http://regulargeek.com/2011/02/09/web-scripting-programming-language-job-trends-february-2011/
Jirko, nechci vyvolávat žádný flame, jenom bych se vás rád zeptal, jaký je
podle vašeho názoru důvod toho, že na Tiobe popularita Ruby posledních 2,5 roku
nepřetržitě upadá ze 4 % v prosinci 2008 (tehdy se probojovalo až na 8. místo)
na současných 1,3 % (12. místo).
Popularita Javy přitom
Co si myslíte, že ovlivňuje popularitu jazyků? Asi se všichni shodneme na
tom, že jejich kvalita to určitě není.
One day in Spring 1989, I was sitting out on the Lucid porch with some of
the hackers, and someone asked me why I thought people believed C and Unix
were better than Lisp. I jokingly
2011/7/15 Jiří Hradil ji...@hradil.cz
Milej zlatej Makube, pres moje male websajty v railsech tecou aktualne
asi 2 miliardy a o nejvetsi system se staram uz 10 let ;))). Nehrajte
Doporučuji se s Jirkou Hradilem nepřít, neb má zprávy z budoucnosti
a snaží se nás již teď přesvědčit, kterým
Tiez ma zaujalo tych 10 rokov RoR, ale to bude zrejme preklep.
RN
On 16. 7. 2011 18:01, Oto Buchta wrote:
2011/7/15 Jiří Hradil ji...@hradil.cz mailto:ji...@hradil.cz
Milej zlatej Makube, pres moje male websajty v railsech tecou aktualne
asi 2 miliardy a o nejvetsi system se staram uz
Kde z Jirkoveho emailu vyplyva, ze byl system odjakziva psan v RoR? Jirkuv styl
je mozna militantni, pro me presto inspirujici.
Mejte se
fil
Sent from iPhone.
On Jul 16, 2011, at 6:59 PM, Robert Novotny robert.novo...@upjs.sk wrote:
Tiez ma zaujalo tych 10 rokov RoR, ale to bude zrejme
Dne 16. července 2011 20:25 Jiri Fabian jiri.fab...@gmail.com napsal(a):
Kde z Jirkoveho emailu vyplyva, ze byl system odjakziva psan v RoR? Jirkuv
styl je mozna militantni, pro me presto inspirujici.
Ano, máš pravdu, sypu si popel na hlavu. Když si to člověk přečte pořádně
znova, slovo od
Ahoj,
ta cisla muzeme brat jako validni, 2 miliardy (CZK+EUR) skutecne platí
pro Railsy, 10 let platí pro jeden systém v toku PHP-Java-RoR. Chtel
jsem tim jen rict, ze RoR jsou vhodne i pro velke systemy a neni
treba se toho bat. Vyvarujme se sireni nazoru, ze RoR je pro webiky
a Java pro
Dobry den,
pokud popularita znamena, ze se o jazyku pise vice, nemuze byt tento
trend zpusoben tim, ze v Jave je vice komunikace v diskuzich taky diky
tomu, ze je to proste slozitejsi jazyk a technologie a tim padem vice
lidi poptava reseni vice problemu? Jak treba sleduji konference v Jave
vs
Jasne, naprosto souhlasim s komplexnosti pouzivani a s mnozstvim
divokych kombinaci. V Jave je mnozstvi frameworku extremni a vybrat si
spravnou a fungujici kombinaci je velmi narocne. Dobre je drzet se
skoro standardu, jako je Hibernate, atd., kde vas v krajnim pripade
zachrani alespon velikost
Jiří Hradil napsal(a):
Jinak pokud bych mel definovat velky system, tak to pro me znamena
jeho odpovednost a mnozstvi prace kterou poskytne a lidem usetri.
Udaje jako pocet trid, pocet radku a mnozstvi dokumentace nepovazuji
za rozhodujici. Maji jistou vypovidajici hodnotu, ale nelze je brat
Dne 14.7.2011 11:08, Robert Novotny napsal(a):
Ruinujuce a JAVA JE MRTVA hlasky nie su na mieste, isteze dalsie jazyky
(Groovy, Scala) mozno ju nahradia z hladiska syntaxe, ale dolezite je, ze stare
kniznice sa nestratia,
Řekl bych, že diskuse o to, jestli je lepší Java nebo
Lépe bych to nenapsal, 100% souhlas,
Pavel.
- PŮVODNÍ ZPRÁVA -
Od: Ondra Medek xmed...@gmail.com
Komu: Java konference@java.cz
Předmět: Re: smerovanie javy 7,8
Datum: 14.7.2011 - 14:16:52
O jakém balastu to mluvíš? Gettery a settery
přece umí každé IDE
vygenerovat a psát p.speed
Milej zlatej Makube, pres moje male websajty v railsech tecou aktualne
asi 2 miliardy a o nejvetsi system se staram uz 10 let ;))). Nehrajte
si na velikost a prestante razit nazor, ze Java je enterprise a pro
velke systemy. To delaji vohnouti v korporacich, aby si zduvodnili
vysokou cenu softwaru,
Skuste pozriet tuto diskusiu, mozno Vam najdete odpoved na niektore
otazky (nazov je Java 7 ale je to primarne o Java 8 ):
http://medianetwork.oracle.com/media/show/16796
Pekny den
Radovan
2011/7/14 x y jsoale...@gmail.com:
Viete mi niekto povedat preco konecne nedaju do javy z dovodu
S těmi property absoluteně souhlasím. Stavím aplikace masivně založené na
beanech a hlídat gettery a settery je opravdu jedním slovem vopruz.
Možnost o které dost uvažujeme je psát beansovské classy jako GroovyBeans.
Libor
BTW: To zase bude flame na tři týdny :-)
2011/7/14 x y
Preco nie su properties, mi nie je jasne a AFAIK v Jave 8 nebudu. Java
je uz zamrazena sama v sebe, lebo spatna kompatibilita je nutnost a
kazda dramaticka syntakticka zmena je zvazovana natolko, ze niekedy je
nemozne ju s kompatibilitou sklbit (.NET ma v tomto vacsiu flexibilitu)
Ruinujuce a
Properties mi osobně vůbec nechybí. Kdysi jsem řešil ještě v Borland Delphi
jeden problém a než jsem zjistil, že v properties je změněná jedna hodnota
naprosto divně, přestože být neměla, trvalo to několik dní.
Pokud jde o jednoduchost psaní, tak Idea se mi o gettery a settery postará
sama. Pokud
Property tak jak jsou řešeny v projektu Lombok podle mého názoru do jazyka
nepatří. Používají totiž anotace a anotace jsou v Javě prostředek pro
specifikaci dodatečné informace o zdrojovém kódu. Proto by bylo divné,
kdyby anotace měnily sémantiku zdrojového kódu.
O jakém balastu to mluvíš?
Rozmyslam o situaciach, ked potrebujete mat typesafe pristup k
properties (napr. wicketovske bindingy modelu na bean by sa zjednodusilo).
Ci si myslite, ze sa to da riesit plug-inmi pre IDE?
On 14. 7. 2011 12:07, Zdeněk Troníček wrote:
Property tak jak jsou řešeny v projektu Lombok podle mého
Ahojte,
Len taky moj nazor. Ja to s gettes/setters nevidim tiez nejak zle. Ved dnes
ich IDEcko dokaze generovat v priebehu jednej klavesovej skratky. Zase tie
getters/setters ma o tolko casu neuberaju. Pisu sa len raz a pri citani ich
clovek uz berie ako samozrejmost. V Scale je naprikald
Já osobně jsem také zastáncem kombinování různých jazyků.
Nezapomínejme že Java je (vzhledem k JVM) low-level jazyk, troufal bych si
ho přirovnat k C na nativních platformách. Co je v Javě napsáno, to je
poměrně přímočaře vyjádřeno do bytecode. Žádný jiný tak nízkoúrovňový jazyk
na JVM není,
Cau,
podle me gettery a settery nechat a jen pridat do eclipse pridat
podporu /* name=generovaneGettery colapsed=true type=bean*/ jako
castecne v netbeans a pripadne nejaky plugin co umi trosku lepe
refaktorovat beany prip kontrolovat ze dany blok je validni beana
(set+propertyName) a ne
O jakém balastu to mluvíš? Gettery a settery přece umí každé IDE
vygenerovat a psát p.speed místo p.getSpeed() mi nepřijde jako zásadní
změna. Navíc mnohem důležitější než snadnost či obtížnost psaní je
snadnost či obtížnost čtení (v literatuře se uvádí, že na jedno napsání
připadá až 20
ano ide o citatelnost(to som aj uviedol .. z dovodu sprehladnenia..) a to
prispieva k rychlosti vyvoja, da sa to riesit urcite na urovni IDE, ale ked
uz sa robi radikalny zasah do javy(teda tak ci onak bude s5tne
nekompatibilna) napr. closures, tak nechapem preco tam nedaju tie property,
preto by
Closures budou zpětně kompatibilní. Možná ne ze 100%, ale téměř jistě se
to číslo bude 100 blížit.
Z.
--
Zdenek Tronicek
FIT CTU in Prague
x y napsal(a):
ano ide o citatelnost(to som aj uviedol .. z dovodu sprehladnenia..) a
to
prispieva k rychlosti vyvoja, da sa to riesit urcite na urovni
Myslím, že tu nezazněl jeden veledůležitý fakt. Třídní/instanční
proměnné, kam bych property zařadil (pokud nemá v době kompilace vlastní
metody), nejdou přetížit. Naopak getter/setter jsou normální metody,
kde je OOP přístup aplikován. Vím, že na tyto metody by to být
aplikováno nemělo
43 matches
Mail list logo
