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 uv
2011/7/18 Oto Buchta
> 2011/7/18 Pavel Kolesnikov
>
>> 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 n
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 při
> 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(technolo
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 technolo
2011/7/18 Pavel Kolesnikov
> 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í pozice na Ruby bez Rai
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"
> Dobrý den,
>
> myslím, že při rozhodování, kterému jazyku či technologi
Myslim, ze ludia su zvyknuti menit veci okolo seba - uz len tym, ze sa tu
prihlasia na mailing list, tak sa chcu nieco dozvediet.
Ale ked clovek robi v korporacii, navyse ak zakaznik je rovnaka firma, tak
akakolvek zmena je porod.
Nie kazdy ma moznost sa nieco naucit a hned si to aj na realnych pro
Jasny, kazdy to vidime jinak. Ja jsem zvykly menit svet kolem sebe a
delat praci tak, abych nemel ani zavan pochybnosti, ze neco delam
zbytecne ci neefektivne. K tomu jsem ale musel dospet. Myslim, ze
koncept "diktujiciho zakaznika" neni spravny, protoze lide poptavaji
funkcnost, nikoli konkretni j
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
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
> Potiz je IMHO v tom, ze se velmi jednoduse zameni "rozumny odpor" s
> lenosti.
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 mozno
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 desit
Ř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ý s
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,
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 :
> Nejvetsi
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
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 hrozn
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/
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 b
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
Pocet clankov velmi casto reflektuje marketingovy hype nez pouzivanost a
mnohokrat indikuje nedostatocnu oficialnu dokumentaciu, s prihliadnutim
na mnozstvo oblasti, ktore pokryva, kvalitu samotneho produktu a
komplexnost pouzitia. (Zoberte si take Koleso ;-))
Wicket, co bol kedysi jeden z naj
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 Rai
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 "e
Dne 16. července 2011 20:25 Jiri Fabian 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 slova, tak Jirka reag
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 wrote:
> Tiez ma zaujalo tych 10 rokov RoR, ale to bude zrejme preklep.
>
> RN
>
> On
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 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 10 let ;))). N
2011/7/15 Jiří Hradil
> 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 směrem vývoj jde.
> 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
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 posle
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
Lépe bych to nenapsal, 100% souhlas,
Pavel.
- PŮVODNÍ ZPRÁVA -
Od: "Ondra Medek"
Komu: "Java"
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
> > > vygener
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
Ruby/Python/Groo
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 (nemaj
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 uro
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
> 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
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
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í, takže
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 @BeanPr
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éh
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íš? Gettery
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. Poku
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
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
> Viete mi n
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 :
> Viete mi niekto povedat preco konecne nedaju do javy z dovodu sprehladnenia
> kodu
Viete mi niekto povedat preco konecne nedaju do javy z dovodu sprehladnenia
kodu praca s property ako napr. v c# - velmi to sprehladni kod(namiesto kopy
balastu gettrov a settrov). Videl som projekt lombok ktory riesi tento
problem anotaciami, ale asi vhodnejsie je zaviest klucove slovo do jazyka.
47 matches
Mail list logo