Na volnou nohu - jaký programovací jazyk?

[Lama]

Tak jsem si hledal, co je to vlastně to UX, tak nějak jsem tušil, ale MP mě donutil si to pořádně dohledat.
http://www.jiribrda.cz/co-je-ux-design-a-kde-se-s-nim-setkate.html
UX designer ve své práci využívá poznatky z mnoha oborů – informatika, kognitivní věda, grafický design, sociologie, psychologie, antropologie, průmyslový design atd.
Koukám, že to nebude uplně prd.el. Asi to nebude zrovna pro mě. Ale na druhou stranu, když jich je takový nedostatek, možná by se tim mohl živit i takový mamlas, jako já. Znáte to, mezi slepými....

[Reklama]

[hu]

VHDL nebo Verilog.

[Mirek Prýmek]

Koukám, že to nebude uplně prd.el.

Zas na druhou stranu pro člověka, který na to má talent a správný způsob myšlení to není až taková věda mám pocit. Selský rozum, pár znalostí, pár výzkumů a pak už to chce "jenom" zkušenosti.

Asi to nebude zrovna pro mě. Ale na druhou stranu, když jich je takový nedostatek, možná by se tim mohl živit i takový mamlas, jako já. Znáte to, mezi slepými....

Stopro nebude, podle toho, cos psal. Ale s tím zbytkem máš pravdu: UXáků je takovej nedostatek, že si stačí udělat dobrý PR a na každé zakázce pak pár měsíců provaříš (než zjistí, že jim žádnou přidanou hodnotu nepřinášíš ).

[ded.kenedy]

Java se vyvíjí stylem "v nadcházející verzi zrušíme unsafe package", čímž rozbijou takřka všechny používané (použitelné) knihovny.

Pokud je nekdo debil a pouziva neoficialni interni funkce a tridy, je to jeho problem, ne Javy.

[Aoidhghean]

Java se vyvíjí stylem "v nadcházející verzi zrušíme unsafe package", čímž rozbijou takřka všechny používané (použitelné) knihovny.

Pokud je nekdo debil a pouziva neoficialni interni funkce a tridy, je to jeho problem, ne Javy.

To ale budou debilové skoro všichni, protože skoro každý reálný projekt používá některou z postižených knihoven (jejich seznam je například na javaworld.com).

[Reklama]

[ded.kenedy]

Pripomnelo mi to  tri roky starou konverzaci, shodou okolnosti tady na rootu: https://blog.root.cz/babel/java-a-nativni-pamet/

Dovolim si vykopirovat ty zasadnejsi pasaze:

ded.kenedy  31. 3. 2014 10:47

Clanek by se mohl jmenovat "Prasime v Jave, aneb chceme programovat v Jave jako v C++ a je nam to jedno".

Pouziti JNI/JNA/PInvoke stoprocentne zajisti, ze program bude neprenositelny a s velkou pravdepodobnosti zajisti i to, ze za deset let nebude zkompilovatelny ani na HW platforme, pro kterou byl puvodne urcen (empiricka zkusenost).

sun.misc.Unsafe je taky neprenositelny, navic clovek musi byt opravdu hodne zoufaly, aby to melo nejaky vetsi efekt. Vetsina tech veci ma svou prenositelnou variantu. Napriklad pro tu (de)serializaci je mnohem vyhodnejsi pouzit nektereho z potomku ByteBufferu.

zboj  31. 3. 2014 11:06

@ded.kenedy Zajímavé, že ti nejlepší vývojáři píšící rozsáhlé efektivní knihovny takto "prasí". Však taky poznamenávám, že to není pro každého. Kdo neví, jak přesně to funguje, měl by se tomu úplně vyhnout. Případně zůstat u Basicu

ded.kenedy 31. 3. 2014 15:01

@13 Jo, ti bajecni vyvojari nebudou muset dnes napsane aplikace za deset let pouzivat nebo snad supportovat a tak, stejne jako ty, muzou dal s klidem v dusi uctivat fetis rychlosti, aniz by je trapilo, ze casem kvuli temto nedokumentovanym funkcim, jejich vytvor nepujde spustit nebo prelozit.

Cekal jsem, ze to casem prijde. Ale ze to bude tak rychle, me opravdu prekvapilo.

[dustin]

@13 Jo, ti bajecni vyvojari nebudou muset dnes napsane aplikace za deset let pouzivat nebo snad supportovat a tak, stejne jako ty, muzou dal s klidem v dusi uctivat fetis rychlosti, aniz by je trapilo, ze casem kvuli temto nedokumentovanym funkcim, jejich vytvor nepujde spustit nebo prelozit.

No a co, vytahal jsem si triko, napsal boží kód, použil jsem dnešní super cool triky, shrábnul prachy a ať si to zákazník/zaměstnavatel za pár let zaplatí znovu, až do toho bude potřeba sáhnout a upravit nebo upgradovat. Nefunguje takhle spoustu vývojářů? Kolik super vývojářů myslí na budoucí udržovatelnost/rozšiřitelnost/upgradovatelnost svého díla pro nějakého zadavatele? Stačí si číst místní diskuse...

[RadimZ]

Co nahradí Rails?

Osobně si myslím, že Ruby je mrtvý, Python bude postupně pomalu ustupovat (asyncio je zoufalý) a postupně se bude prosazovat nejspíš Go, pokud ho někdo včas netrumfne. Kéžby se začal víc prosazovat Elixir, ale v to moc nedoufám - kritická masa tam není a nezdá se mi, že by se nabalovala.

Kritická masa ne, ale v ruby (rails) pozoruji, že skoro každý se již na Elixir (Phoenix) koukal, ale zatím nemají důvod k tomu, aby z něj udělali svůj primární jazyk(framework).  Ony ty railsy budou totiž umírat hrozně dlouho a tak by prosazování Elixiru mělo být spíše pozvolné, než že si najednou všichni railsaři řeknou, že odteď Phoenix a už nikdy jinak. 

Ale uvidíme, mě se Elixir moc líbí, ale hlediska jistoty do budoucna taky raději investuji svůj čas do JS (i když ho moc nemusím).

[gll]

Co nahradí Rails?

Osobně si myslím, že Ruby je mrtvý, Python bude postupně pomalu ustupovat (asyncio je zoufalý) a postupně se bude prosazovat nejspíš Go, pokud ho někdo včas netrumfne. Kéžby se začal víc prosazovat Elixir, ale v to moc nedoufám - kritická masa tam není a nezdá se mi, že by se nabalovala.

Kritická masa ne, ale v ruby (rails) pozoruji, že skoro každý se již na Elixir (Phoenix) koukal, ale zatím nemají důvod k tomu, aby z něj udělali svůj primární jazyk(framework).  Ony ty railsy budou totiž umírat hrozně dlouho a tak by prosazování Elixiru mělo být spíše pozvolné, než že si najednou všichni railsaři řeknou, že odteď Phoenix a už nikdy jinak. 

Ale uvidíme, mě se Elixir moc líbí, ale hlediska jistoty do budoucna taky raději investuji svůj čas do JS (i když ho moc nemusím).

Elixir se mi také líbí, ale nevěřím, že řeší problémy ne-realtime aplikací.

[Mirek Prýmek]

Elixir se mi také líbí, ale nevěřím, že řeší problémy ne-realtime aplikací.

Nevím, jeslti to považuješ za "problém", ale já osobně za jednu z nejlepších vlastností Elixiru považuju dobře udělané greenthready - kód řeší separátně třeba jenom jednoho klienta, jednu connection apod. (podobně jako v Go).

[gll]

Elixir se mi také líbí, ale nevěřím, že řeší problémy ne-realtime aplikací.

Nevím, jeslti to považuješ za "problém", ale já osobně za jednu z nejlepších vlastností Elixiru považuju dobře udělané greenthready - kód řeší separátně třeba jenom jednoho klienta, jednu connection apod. (podobně jako v Go).

Myslel jsem to tak, že u ne-realtime aplikací velkou část featur Phoenixu nevyužiujete.

[Mirek Prýmek]

Myslel jsem to tak, že u ne-realtime aplikací velkou část featur Phoenixu nevyužiujete.

No "realtime" je dneska v jistým smyslu každý serverový software. Těch opravdu čistě batchových je imho celkem málo.