Zaměstnavatelé a programovací jazyky

[andy]

No vždyť jo, to je přesně ten úplně jiný level. V haskellu schopnost napsat si funkční parser patří mezi naprosté základy (jedna z příruček pro začátečníky má téma "napiště si interpret Scheme za 48 hodin"). Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít.  Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).

Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.

Vzhledem k neschpnosti poochopit psaný text ten parser asi moc elegantně napsaný nebude...

[Reklama]

[balki]

No vždyť jo, to je přesně ten úplně jiný level. V haskellu schopnost napsat si funkční parser patří mezi naprosté základy (jedna z příruček pro začátečníky má téma "napiště si interpret Scheme za 48 hodin"). Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít.  Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).

Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.

Vzhledem k neschpnosti poochopit psaný text ten parser asi moc elegantně napsaný nebude...

Ved je elegantny, do komentarov som dal poniky v ascii art.  Vy budete nejaky hlupejsi.

[andy]

No vždyť jo, to je přesně ten úplně jiný level. V haskellu schopnost napsat si funkční parser patří mezi naprosté základy (jedna z příruček pro začátečníky má téma "napiště si interpret Scheme za 48 hodin"). Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít.  Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).

Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.

Vzhledem k neschpnosti poochopit psaný text ten parser asi moc elegantně napsaný nebude...

Ved je elegantny, do komentarov som dal poniky v ascii art.  Vy budete nejaky hlupejsi.

To je dost možné, mám třeba problém pochopit, jak jste z mého "je problém napsat elegantní parser" vyvodil, že to nejde.... asi mám moc nízké IQ, pravda....

[balki]

No vždyť jo, to je přesně ten úplně jiný level. V haskellu schopnost napsat si funkční parser patří mezi naprosté základy (jedna z příruček pro začátečníky má téma "napiště si interpret Scheme za 48 hodin"). Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít.  Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).

Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.

Vzhledem k neschpnosti poochopit psaný text ten parser asi moc elegantně napsaný nebude...

Ved je elegantny, do komentarov som dal poniky v ascii art.  Vy budete nejaky hlupejsi.

To je dost možné, mám třeba problém pochopit, jak jste z mého "je problém napsat elegantní parser" vyvodil, že to nejde.... asi mám moc nízké IQ, pravda....

Ved ja viem, haskellisti kodia v cylindroch, to som si vas len tak doberal ...

[Labrat]

Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.

Knihovnu umí použít každý.

[Reklama]

[Jano7]

Myslím, že autor tím myslel to, že je trošku rozdíl mezi "frameworkem" a "knihovnou" s tím, že je preferována "knihovna" před "frameworkem". Tohle je samozřejmě na filosofickou debatu, ale třeba konkrétně proti tvému příkladu anotace @RequestMapping tak nějak spadla z nebe, není to pořádně součást kódu, je tam nějak "navíc". Tohle je příklad tohotéž s použitím knihovny (která je teda hodně advanced).

Nespadla z neba, Spring si pozrie zdroják a potrebné závislosti si stiahne a použije. Groovy sa používa na prototyping, preto sa to takto uľahčuje. To je samozrejme niečo, čo C++, C, Haskell programátor nevie, lebo nepozná špecifiká vývoja v Jave. Je Spring Boot magic, vec ktorá veľmi zjednodušuje programátovori prácu, ale na druhej strane pridáva na štúdiu pre začiatočníkov.

„Problém” v Jave nie je v tom, že na vytvorenie aplikácie potrebujeme množstvo knižníc. Každý projekt má sadu nástrojov, tzv. full stack, ktorú použije na tvorbu aplikácie. Tak je to v Jave, C#, PHP, alebo Ruby. Problém sa vníma v tom, že Java má veľa alternatív, konkurenčných knižníc, modulov, frameworkov. Problém je sa potom rozhodnúť, ktorú použiť.

Tak až do PHP by se to dalo brát vážně, ale tím jsi to fakt zabil....

PHP za tie roky vyzrelo. Veľa sa inšpirovali Javou. Tí, čo sa dívajú zvrchu na PHP zrejme moderné PHP vôbec nepoznajú. Taký PHP Laravel framework je veľmi šikovný a elegantný.

Pleteš si znalosti (webových) technologií se znalostí jazyka a jeho ekosystému. Haskell má velmi dobrou podporu pro webové technologie, tak fakt netuším, proč by na tom PHPčkář měl být líp.

Upozorňoval so, že Haskell senior developer nemôže robiť Java senior developera, pretože ich doména je iná. V Jave sa riešia veľké webové projetky, Android a v Haskelli iné veci. Implicitne sa tu v diskusii myslelo Haskell  + matematika.

Nedávno jsem dělal v haskellu několik větších projektů, přičemž každý používá asi tak 50 různých knihoven z dost velkého rozsahu (parsing, security, různé web protokoly atd.). To, na co se ty tváříš, že je potřeba mít strašně velké znalosti, je asi tak na té úrovni "přečtu si API a použiju to".

Nuž ja som intenzívne študoval Swing (desktop UI) vyše roka a pol. Len JTextPane a JEditorPane komponenty by ti zabrali niekoľko mesiacov štúdia. Ak si myslíš, že sa „porozhliadneš” a začneš Swing používať, tak sa veľmi mýliš. Nenakódiš bez dlhodobého štúdia nič poriadne. O Springu ani nehovorím.

Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít. 

To berieš odkiaľ? Máš proti Jave a PHP poriadne predsudky. To, čo potrebuje senior Java programátor som písal podrobnejšie vyššie. (Rozsiahle znalosti knižníc, frameworkov, integrácie, návrhu aplikácií, réžie, soft skills a roky praxe.)

Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).

Neviem či si to uvedomuješ, ale Java je ekosystém. Nie je to jeden programovací jazyk. V ekosystéme Javy máme funkcionálne jazyky Scalu a Clojure. Takže ak si potrebuješ spraviť parser a chceš to s funkcionálnym jazykom, tak si zoberieš jeden z týchto jazykov. A výslekok môžeš použiť trebárs spätne v Jave (jazyku).

[Jano7]

Knihovnu umí použít každý.

Poprosím všetkých tých, čo si toto myslia, aby doplnili nasledujúci program tak, aby
tam boli dva buttony v ľavom dolnom rohu, s medzerou medzi nimi a okrajmi.

Kód: [Vybrat]

package com.zetcode

import javax.swing.*

class TooltipEx(title: String) : JFrame() {

    init {
        createUI(title)
    }

    private fun createUI(title: String) {

        val closeButton = JButton("Button").apply({
            toolTipText = "JButton component"
        })

        createLayout(closeButton)

        setTitle(title)

        defaultCloseOperation = JFrame.EXIT_ON_CLOSE
        setLocationRelativeTo(null)
    }

    private fun createLayout(vararg arg: JComponent) {

        val gl = GroupLayout(contentPane)
        contentPane.layout = gl

        (contentPane as JPanel).toolTipText = "This is JPanel"

        gl.autoCreateContainerGaps = true

        gl.setHorizontalGroup(gl.createSequentialGroup()
                .addComponent(arg[0])
                .addGap(200)
        );

        gl.setVerticalGroup(gl.createSequentialGroup()
                .addComponent(arg[0])
                .addGap(120)
        );

        pack();
    }
}

private fun createAndShowGUI() {

    val frame = TooltipEx("Tooltip example")
    frame.isVisible = true
}

fun main(args: Array<String>) {
    SwingUtilities.invokeLater(::createAndShowGUI)
}

Je to v jazyku Kotlin. Práve teraz si skúšam, ako spraviť Swing aplikáciu v Kotline.

[Labrat]

Myslím, že autor tím myslel to, že je trošku rozdíl mezi "frameworkem" a "knihovnou" s tím, že je preferována "knihovna" před "frameworkem". Tohle je samozřejmě na filosofickou debatu, ale třeba konkrétně proti tvému příkladu anotace @RequestMapping tak nějak spadla z nebe, není to pořádně součást kódu, je tam nějak "navíc". Tohle je příklad tohotéž s použitím knihovny (která je teda hodně advanced).

Nespadla z neba, Spring si pozrie zdroják a potrebné závislosti si stiahne a použije. Groovy sa používa na prototyping, preto sa to takto uľahčuje. To je samozrejme niečo, čo C++, C, Haskell programátor nevie, lebo nepozná špecifiká vývoja v Jave. Je Spring Boot magic, vec ktorá veľmi zjednodušuje programátovori prácu, ale na druhej strane pridáva na štúdiu pre začiatočníkov.

„Problém” v Jave nie je v tom, že na vytvorenie aplikácie potrebujeme množstvo knižníc. Každý projekt má sadu nástrojov, tzv. full stack, ktorú použije na tvorbu aplikácie. Tak je to v Jave, C#, PHP, alebo Ruby. Problém sa vníma v tom, že Java má veľa alternatív, konkurenčných knižníc, modulov, frameworkov. Problém je sa potom rozhodnúť, ktorú použiť.

Tak až do PHP by se to dalo brát vážně, ale tím jsi to fakt zabil....

PHP za tie roky vyzrelo. Veľa sa inšpirovali Javou. Tí, čo sa dívajú zvrchu na PHP zrejme moderné PHP vôbec nepoznajú. Taký PHP Laravel framework je veľmi šikovný a elegantný.

Pleteš si znalosti (webových) technologií se znalostí jazyka a jeho ekosystému. Haskell má velmi dobrou podporu pro webové technologie, tak fakt netuším, proč by na tom PHPčkář měl být líp.

Upozorňoval so, že Haskell senior developer nemôže robiť Java senior developera, pretože ich doména je iná. V Jave sa riešia veľké webové projetky, Android a v Haskelli iné veci. Implicitne sa tu v diskusii myslelo Haskell  + matematika.

Nedávno jsem dělal v haskellu několik větších projektů, přičemž každý používá asi tak 50 různých knihoven z dost velkého rozsahu (parsing, security, různé web protokoly atd.). To, na co se ty tváříš, že je potřeba mít strašně velké znalosti, je asi tak na té úrovni "přečtu si API a použiju to".

Nuž ja som intenzívne študoval Swing (desktop UI) vyše roka a pol. Len JTextPane a JEditorPane komponenty by ti zabrali niekoľko mesiacov štúdia. Ak si myslíš, že sa „porozhliadneš” a začneš Swing používať, tak sa veľmi mýliš. Nenakódiš bez dlhodobého štúdia nič poriadne. O Springu ani nehovorím.

Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít. 

To berieš odkiaľ? Máš proti Jave a PHP poriadne predsudky. To, čo potrebuje senior Java programátor som písal podrobnejšie vyššie. (Rozsiahle znalosti knižníc, frameworkov, integrácie, návrhu aplikácií, réžie, soft skills a roky praxe.)

Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).

Neviem či si to uvedomuješ, ale Java je ekosystém. Nie je to jeden programovací jazyk. V ekosystéme Javy máme funkcionálne jazyky Scalu a Clojure. Takže ak si potrebuješ spraviť parser a chceš to s funkcionálnym jazykom, tak si zoberieš jeden z týchto jazykov. A výslekok môžeš použiť trebárs spätne v Jave (jazyku).

Ty časy jsou trochu přehnané. Vývojář nebo architekt je junior nebo senior bez ohledu na jazyk, jde o zkušenosti z vývoje a návrhu celkově. Vůbec to nesouvisí s Haskellem nebo Javou. Akorát Haskell je mnohem abstraktnější, takže přechod na Javu je hračka, kdežto naopak obnáší učení se novému paradigmatu.

[andy]

Myslím, že autor tím myslel to, že je trošku rozdíl mezi "frameworkem" a "knihovnou" s tím, že je preferována "knihovna" před "frameworkem". Tohle je samozřejmě na filosofickou debatu, ale třeba konkrétně proti tvému příkladu anotace @RequestMapping tak nějak spadla z nebe, není to pořádně součást kódu, je tam nějak "navíc". Tohle je příklad tohotéž s použitím knihovny (která je teda hodně advanced).

Nespadla z neba, Spring si pozrie zdroják a potrebné závislosti si stiahne a použije. Groovy sa používa na prototyping, preto sa to takto uľahčuje. To je samozrejme niečo, čo C++, C, Haskell programátor nevie, lebo nepozná špecifiká vývoja v Jave. Je Spring Boot magic, vec ktorá veľmi zjednodušuje programátovori prácu, ale na druhej strane pridáva na štúdiu pre začiatočníkov.

No...já chápu, že je trochu problém diskutovat o filosofii jazyků, když ta druhé strana jaksi nezná to druhé...ale zkusím to. Rozdíl mezi knihovnou a frameworkem je v tom, kdo koho volá a co po něm chce. U knihovny principiálně můj kód volá knihovnu a říká jí, co má dělat. Framework naopak volá můj kód a "očekává", že na nějakých místech se třeba objeví nějaké nápady, co má ten framework dělat. Což je příklad toho @RequestMapping, kdy člověk prostě musí "vědět", že to tam ten framework očekává a nějak se podle toho zařídí. Když se to tam zapomene, tak akorát ten program nefunguje jak má, a když to člověk píše, tak se to blbě hledá, protože to tak nějak není v kódové cestě.

„Problém” v Jave nie je v tom, že na vytvorenie aplikácie potrebujeme množstvo knižníc. Každý projekt má sadu nástrojov, tzv. full stack, ktorú použije na tvorbu aplikácie. Tak je to v Jave, C#, PHP, alebo Ruby. Problém sa vníma v tom, že Java má veľa alternatív, konkurenčných knižníc, modulov, frameworkov. Problém je sa potom rozhodnúť, ktorú použiť.

No, což je situace zhruba ve všech jazycích....

Pleteš si znalosti (webových) technologií se znalostí jazyka a jeho ekosystému. Haskell má velmi dobrou podporu pro webové technologie, tak fakt netuším, proč by na tom PHPčkář měl být líp.

Upozorňoval so, že Haskell senior developer nemôže robiť Java senior developera, pretože ich doména je iná. V Jave sa riešia veľké webové projetky, Android a v Haskelli iné veci. Implicitne sa tu v diskusii myslelo Haskell  + matematika.

Ne, to se vůbec implicitně nemyslelo, to někdo zmínil v tom (a ještě chybném) smyslu, že haskellový typový systém je hodně teoretický a abstraktní, a pokud ho zvládneš, tak ve srovnání s ním je všechno ostatní hračka. Ne, že v tom píšeš matematiku. Třeba konkrétně ten servant (knihovna na REST api) je krásná ukázka hodně advanced typového systému. A ano, v Haskellu se taky řeší webové projekty, dokonce bych řekl, že je to dneska asi nejčastější užití haskellu.

Nedávno jsem dělal v haskellu několik větších projektů, přičemž každý používá asi tak 50 různých knihoven z dost velkého rozsahu (parsing, security, různé web protokoly atd.). To, na co se ty tváříš, že je potřeba mít strašně velké znalosti, je asi tak na té úrovni "přečtu si API a použiju to".

Nuž ja som intenzívne študoval Swing (desktop UI) vyše roka a pol. Len JTextPane a JEditorPane komponenty by ti zabrali niekoľko mesiacov štúdia. Ak si myslíš, že sa „porozhliadneš” a začneš Swing používať, tak sa veľmi mýliš. Nenakódiš bez dlhodobého štúdia nič poriadne. O Springu ani nehovorím.

Takže podle tebe není senior java programátor ten, který neumí JTextPane a JEditorPane?

Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít. 

To berieš odkiaľ? Máš proti Jave a PHP poriadne predsudky. To, čo potrebuje senior Java programátor som písal podrobnejšie vyššie. (Rozsiahle znalosti knižníc, frameworkov, integrácie, návrhu aplikácií, réžie, soft skills a roky praxe.)

Odkud to beru? Od tebe. Jako kontrast proti tomu, že kdybych já někde třeba chtěl dělat senior haskell programátora, tak se mě na znalost nějakých knihoven ptají akorát za účelem zjištění, na jaké úrovni jsem schopen programovat (pokud někdo programuje 7 let v haskellu a neumí aspoň základně použít lensy, tak to poněkud vzbuzuje pochybnost, co vlastně umí).

Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).

Neviem či si to uvedomuješ, ale Java je ekosystém. Nie je to jeden programovací jazyk. V ekosystéme Javy máme funkcionálne jazyky Scalu a Clojure. Takže ak si potrebuješ spraviť parser a chceš to s funkcionálnym jazykom, tak si zoberieš jeden z týchto jazykov. A výslekok môžeš použiť trebárs spätne v Jave (jazyku).

Jasně, takže hádej kdo bude mít menší problém napsat něco ve Scale? Javista nebo haskellista? A když se bavíme o tom, kdo to je senior programátor, tak to je asi docela relevantní otázka, že?

[andy]

Knihovnu umí použít každý.

Poprosím všetkých tých, čo si toto myslia, aby doplnili nasledujúci program tak, aby
tam boli dva buttony v ľavom dolnom rohu, s medzerou medzi nimi a okrajmi.

Buď to půjde nějakým fíglem s TRAILING alignmentem, nebo možná (dost pravděpodobně) taky ne a bude potřeba použít jiný layout, třeba BorderLayout.

Ty fakt máš pocit, že tohle je problém? (v životě jsem swing neviděl)

[Jano7]

No...já chápu, že je trochu problém diskutovat o filosofii jazyků, když ta druhé strana jaksi nezná to druhé...ale zkusím to. Rozdíl mezi knihovnou a frameworkem je v tom, kdo koho volá a co po něm chce. U knihovny principiálně můj kód volá knihovnu a říká jí, co má dělat. Framework naopak volá můj kód a "očekává", že na nějakých místech se třeba objeví nějaké nápady, co má ten framework dělat. Což je příklad toho @RequestMapping, kdy člověk prostě musí "vědět", že to tam ten framework očekává a nějak se podle toho zařídí. Když se to tam zapomene, tak akorát ten program nefunguje jak má, a když to člověk píše, tak se to blbě hledá, protože to tak nějak není v kódové cestě.

To je uhol pohľadu, resp. ako si zadefinujeme pojmy. Pretože z môjho uhla pohľadu, je framework jednoducho súbor knižníc. Napríklad Spring Boot projekt si vytvorím tak, že zadefinujem potrebné závislosti a Maven mi stiahne potrebné knižnice (u nás JAR súbory). Framework obsahuje množstvo kódu, ktorý sa v projektoch opakuje. Kto koho volá; na to v Jave máme pojem dependency injection, ale primárne nerozlišujeme podľa toho pojmy framework a knižnica. Možno to tak máte zadefinované v Haskelli.

Takže podle tebe není senior java programátor ten, který neumí JTextPane a JEditorPane?

To som nepovedal. Bolo to na ilustráciu toho, že predstava, že si zoberieš knižnicu, pozrieš si API a začneš ju
používať je nereálna. Swing bol len príklad zložitejšej knižnice. Bez dlhodobého štúdia princípov UI a Swingu to nespraví začiatočník správne. Ako spravíš Tetris hru vo Swingu? Veď je to jednoduché, zvolíš si správne triedy zavoláš  tie správne metódy...

Jasně, takže hádej kdo bude mít menší problém napsat něco ve Scale? Javista nebo haskellista? A když se bavíme o tom, kdo to je senior programátor, tak to je asi docela relevantní otázka, že?

Mal by to byť Haskellista. Ale odbáčaš od témy. Pointa toho, čo som povedal je, že mne sa zdá, že ty zužuješ (neviem prečo) všetko na Javu ako jazyk. Pritom Java je ekosystém s viacerými programovacími jazykmi. Tvrdíš niečo o Javistoch, hovoríš, že Java je taká a taká, pritom Java programátori môžu využívať viaceré jazyky: Java, Kotlin, Scala, Groovy, či Clojure. 

[v]

Java programátori môžu využívať viaceré jazyky: Java, Kotlin, Scala, Groovy, či Clojure.

tj. java programátor je programátor, který programuje pro JVM? to by byla hodně bizarní myšlenka

[Jano7]

Buď to půjde nějakým fíglem s TRAILING alignmentem, nebo možná (dost pravděpodobně) taky ne a bude potřeba použít jiný layout, třeba BorderLayout.

Ty fakt máš pocit, že tohle je problém? (v životě jsem swing neviděl)

Na to si potrebuješ naštudovať GroupLayout manager, čo sú to sequenčné a paralelné grupy a musíš praxou zistiť, ako to všetko v praxi uplatniť. (Naučiť sa pravidlá šachu vs hrať úspešne šach.) Je to triviálny príklad, ale bez dlhšieho štúdia nespravíš dobrý layout. A to som výrazne pomohol tým, že som tam dal GroupLayout, pretože korektný layout vo Swingu sa dá spraviť len s ním alebo s MigLayout manažérom. Toto všetko som zistil až po mnohých mesiacoch štúdia. Napríklad, ak by sa na to niekto spýtal na stackoverflow, veľmi často dostane nesprávnu odpoveď. Ktorá síce funguje, ale nie je portabilná.

Toto nehovorím preto, že by som sa chválil. Ja som dosť starý a zrelý na to, aby som sa potreboval nad niekým vyvyšovať. Ja som Javista ty si iba PHPčkár, ja som backend programátor, ty iba frontenďák apod. Je to na ilustráciu.

Kód: [Vybrat]

    private fun createLayout(vararg arg: JComponent) {

        val gl = GroupLayout(contentPane)
        gl.autoCreateGaps = true
        gl.autoCreateContainerGaps = true

        contentPane.layout = gl

        gl.autoCreateContainerGaps = true

        gl.setHorizontalGroup(gl.createSequentialGroup()
                .addGap(5, 250, Int.MAX_VALUE)
                .addPreferredGap(RELATED,
                        GroupLayout.DEFAULT_SIZE, Int.MAX_VALUE)
                .addComponent(arg[0])
                .addComponent(arg[1])
        )


        gl.setVerticalGroup(gl.createSequentialGroup()
                .addGap(5, 250, Int.MAX_VALUE)
                .addPreferredGap(RELATED,
                        GroupLayout.DEFAULT_SIZE, Int.MAX_VALUE)
                .addGroup(gl.createParallelGroup()
                        .addComponent(arg[0])
                        .addComponent(arg[1]))
        )

        gl.linkSize(SwingConstants.HORIZONTAL, arg[0], arg[1]);

        pack()
    }

Pre zaujímavosť, buttony do pravého dolného rohu sa dajú nakódiť takto.

Ak by som chcel zvoliť niečo zložitejšie, tak by som navrhol spraviť nasledovný layout:



To je board pre monopoly. Vnútorný priestor sa mení, vonkajšie tvary sú fixné. Dosť som sa s tým potrápil.

[Jano7]

Java programátori môžu využívať viaceré jazyky: Java, Kotlin, Scala, Groovy, či Clojure.

tj. java programátor je programátor, který programuje pro JVM? to by byla hodně bizarní myšlenka

Zatiaľ dominuje Java, ale Javisti bežne využívajú aj iné jazyky. Ale podľa mojej mienky to tam smeruje.
Všetko sa dramaticky mení, aj také veci, ktoré boli uhľovými kameňmi vývoja, sa zrazu menia. Trebárs
Servlety, jedna z najdôležitejších sfér v Jave. A prišiel Play framework, ktorý je postavený mimo servlety
a tiež si zvolil Scalu ako dominantný jazyk.

Je veľmi pravdepodobné, že Kotlin za pár rokov nahradí Javu a z Javy v podstate zostane názov pre tento
rozsiahly ekosystém.

[Ondra.]

Cetl jsem jen prvnich par prispevku, pak uz je to urcite OT jak je tady normalni a ano neni normalni se ptat na takove hovadiny na pohovoru. Mel jsi je poslat do rite a cestou ven jit na jejich HR a rict jim jaky hovada tam delaji pohovory.