abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 21:11 | Nová verze

Vyšla nová verze 1.4.0 nástroje pro připojení ke vzdálené ploše Remmina. Mezi změnami figurují např. opravy autentizace přes SSH nebo nakládání se schránkou při připojení přes RDP. Sestavení dostupná z PPA pro Ubuntu skončí ve prospěch Flatpaku a Snapu.

Fluttershy, yay! | Komentářů: 3
21.2. 16:33 | Komunita

Google zveřejnil seznam 200 organizací přijatých do letošního Google Summer of Code (GSoC). Dle plánu se studenti přihlašují od 16. do 31. března. Vydělat si mohou od 3 000 do 6 600 dolarů. V Česku a na Slovensku 3 600 dolarů. Další informace v často kladených otázkách (FAQ). K dispozici jsou také statistiky z minulých let.

Ladislav Hagara | Komentářů: 1
21.2. 15:55 | IT novinky

Ve věku 74 let zemřel Lawrence Tesler. V 70. letech pracoval v Xerox PARC a posléze odešel do Apple. Zabýval se především zjednodušováním uživatelských rozhraní, byl odpůrcem modality a přispěl k prosazení moderního způsobu označování a kopírování textu – myší a klávesovými zkratkami (kombinace s XCV) – v raných Apple Human Interface Guidelines. Dále se podílel např. na vývoji Smalltalku a souvisejícího přenosného počítače Xerox NoteTaker nebo později PDA Apple Newton.

Fluttershy, yay! | Komentářů: 6
21.2. 13:11 | Zajímavý článek

Aktuální příspěvek What is Mobile PureOS? na stránkách společnosti Purism je věnován operačnímu systému Mobile PureOS, tj. PureOS pro mobilní zařízení a především pro telefon Librem 5. Víceméně se jedná o stabilní Debian s GNOME doplněný o balíčky phosh, phoc, libhandy, Calls, Chats a další.

Ladislav Hagara | Komentářů: 0
20.2. 19:33 | Zajímavý článek

Jozef Mlich se v příspěvku PinePhone je nové OpenMoko na svém blogu věnuje svému novému linuxovému chytrému telefonu PinePhone v edici BraveHeart: "Momentálně se pocity z tohohle zařízení dají přirovnat k BrokenMoku. Většina věcí prostě nefunguje. Minimálně ne sama od sebe. Začít se dá už u samotného hardware, kde existuje wiki stránka popisující nedostatky".

Ladislav Hagara | Komentářů: 23
20.2. 10:00 | Zajímavý projekt

Justine Haupt aktualizovala svůj open source mobilní telefon s rotační číselnicí a zveřejnila kompletní dokumentaci, vlastní kód, schémata i STL soubory pro 3D tisk. Desku plošných spojů případně i vytištěný obal lze koupit v jejím obchodu.

Ladislav Hagara | Komentářů: 40
20.2. 06:00 | IT novinky

Otevřená certifikační autorita Let's Encrypt v příspěvku na svém blogu informuje, že žádosti o vystavení certifikátů nově validuje z několika míst současně (Multi-Perspective Validation). Další informace v diskusním fóru.

Ladislav Hagara | Komentářů: 10
19.2. 13:55 | Nová verze

Byla vydána verze 15.0 na Debianu založené linuxové distribuce Untangle NG Firewall. Přehled novinek v poznámkách k vydání a ve videu na YouTube. Vyzkoušet lze (zatím neaktualizované) demo webového rozhraní.

Ladislav Hagara | Komentářů: 0
19.2. 12:11 | Pozvánky

Letošní ročník konference LinuxDays se uskuteční o víkendu 3. a 4. října, opět se potkáme v pražských Dejvicích na FIT ČVUT. Také během devátého ročníku nás budou čekat desítky přednášek, workshopy, stánky a spousta doprovodného programu. Aktuální dění můžete sledovat na Twitteru nebo Facebooku, přidat se můžete také do telegramové diskusní skupiny.

Petr Krčmář | Komentářů: 7
19.2. 10:22 | Zajímavý článek

Alexander Popov se v příspěvku na svém blogu podrobně věnuje možnostem zneužití bezpečnostní chyby CVE-2019-18683 v linuxovém podsystému V4L2. Videoukázka eskalace práv na YouTube. Chyba byla v upstreamu opravena v listopadu loňského roku. Alexander Popov se chybě věnoval ve své přednášce (pdf) na konferenci OffensiveCon 2020.

Ladislav Hagara | Komentářů: 0
Vydržela vám novoroční předsevzetí?
 (9%)
 (5%)
 (3%)
 (83%)
Celkem 183 hlasů
 Komentářů: 0
Rozcestník

www.AutoDoc.Cz

Microsoft kupuje Xamarin

Microsoft kupuje Xamarin. Společnost Xamarin založili v roce 2011 Miguel de Icaza a Nat Friedman. Xamarin pokračoval ve vývoji Mono, svobodné alternativy k platformě .NET od Microsoftu, po propuštění zaměstnanců Novellu, kteří na Mono pracovali (zprávička).

25.2.2016 00:30 | Ladislav Hagara | Komunita


Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

25.2.2016 07:37 JD
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
A ted se ukaze, zda je kupuje, aby zvysil kompatibilitu .NET u konkurence kvuli prosazeni vlastnich aplikaci. Nebo naopak MONO pohrbil a zajistil tim pro .NET aplikace exluzivitu ve Win (podobny scenar jako zkusil Oracle s OpenOffice/StarOffice)
Václav 25.2.2016 08:30 Václav "Darm" Novák | skóre: 26 | blog: Darmovy_kecy | Bechyně / Praha
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
To by bylo trochu zvláštní, vzhledem k tomu že části .net pokud vím uvolňují (a jejich nový textový editor nabízí i ve verzi pro Linux)
Cross my heart and hope to fly, stick a cupcake in my eye!
Salamek avatar 25.2.2016 15:26 Salamek | skóre: 22 | blog: salamovo
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
> a jejich nový textový editor nabízí i ve verzi pro Linux

Jejich "nový" textovy editor je ve skutecnosti jen fork Atomu https://atom.io/ kdyby to delali oni od "piky" tak pochybuji ze by by tam podpora Linuxu byla
Skutečně nemám v plánu zničit Microsoft. Bude to jen zcela neúmyslný vedlejší efekt.
25.2.2016 17:02 chytrák
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Salamek avatar 26.2.2016 13:14 Salamek | skóre: 22 | blog: salamovo
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Tak tomu se da teda dost tezko verit...
Skutečně nemám v plánu zničit Microsoft. Bude to jen zcela neúmyslný vedlejší efekt.
Václav 27.2.2016 16:32 Václav "Darm" Novák | skóre: 26 | blog: Darmovy_kecy | Bechyně / Praha
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Základ v elektronu je stejný jako u Atomu, ale jinak je to opravdu jiný editor

tl;dr:
There are rumors that Visual Studio code is either a fork or rebranding of Github's Atom Editor. This is not even remotely true. Inspecting the source of Visual Studio Code (which can be done by opening Chrome's built in dev tools while running the program by simply pressing F12) reveals that it uses Electron and Atom Shell Archive, but nothing else is from the Atom editor.

The 'editor' (the thing that renders the code with syntax highlighting, line numbers, etc..) part of Visual Studio Code is Microsoft's Monaco editor. It is the same editor used for OneDrive, Windows Azure, TypeScript Playground, and Visual Studio Online. I have yet to find any real documentation on this editor from Microsoft but there are some articles about it around the web.
Cross my heart and hope to fly, stick a cupcake in my eye!
25.2.2016 08:46 pet I. | skóre: 7
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Ale vždyť logika MONA byla vždy jasná: MONO funguje všude, .NET jen na win, jinými slovy: na win fungují všechny programy, jinde jen některé, tak proč používat něco jiného než win? Totéž předváděli hoši od M$ už s Javou než je Sun musel nakonec žalovat.
25.2.2016 09:26 Sid
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
povedal by som, ze zo snov o ovladnuti sveta cez Windows sa uz MS vyliecil a teraz podla mna sa snazi aby mu znova neusiel vlak aj v cloude a obecne v platformach co sa pouzivaju.
25.2.2016 09:33 asdfadssssssssssss
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
podla mna to dopadne ako skype...
25.2.2016 10:53 Ivan
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
MS uz davno neni jakovy arcilotr jakym byval. Ta firma si prosla nekolik anti-monopolnich rizeni, aby jim nakonec doslo, ze jim ujel vlak nekde jinde a ze penize se vydalavaji jinde. Dneska se chovaji jako normalni pragmaticka firma, ktera se venuje vsemu co prinasi zisk.

Mono nepouzivam, ale musim uznat, ze nekterych ohledech je to velice uspesny projekt. Udivuje me ta rychlost vyvoje. Mono se velice rychle dostalo do stavu kdy je to pouzitelne, ma to nastroje, knihovni a hlavne dokumentaci. Kdyz to porovnam s tim kolik lidi a casu se investovalo do Qt, a to je v podstate jen framework bez kompilatoru a bez VM.

PS: samozrejme ze se to neda uplne srovnavat, protoze Mono ma pouziva bindingy na Gtk a jine Cckove knihovny.
25.2.2016 10:55 rastos | skóre: 61 | blog: rastos
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
MS uz davno neni jakovy arcilotr jakym byval.
Jo. S Win10 prešli na úplne iný level.
pavlix avatar 25.2.2016 10:58 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Dneska se chovaji jako normalni pragmaticka firma, ktera se venuje vsemu co prinasi zisk.

Jako normální pragmatická firma bez vize.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
25.2.2016 15:25 JoHnY3
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Ja si myslim, ze Win 10 a sber udaju snad jeste drsnejsi nez jak ho dela Google celkem jasne ukazuje cestu. :-)
25.2.2016 17:05 chytrák
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Drsnější není, podívej se na android nebo nedávná kauza s chromebooky rozdávanými do amerických škol. Spíš je první kdo podobné praktiky přinesl na desktop.
25.2.2016 10:59 Ivan
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Kdyz tak o tom premyslim, tak ono se to dostalo do relativne pouzitelneho stavu. Podelali si to tim, ze meli ve zdrojacich hard-codovane cesty k souborum, ktere fungovaly jen na Suse a odmitali s tim cokoliv udelat.
25.2.2016 11:16 Jardík
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Pro C# dneska není ani pořádná knihovna pro GUI ... kromě nějakých wrapperů, kvůli kterým se z toho stává slátanina, kde půlku věcí uvolní samo GC, a drouhou si řešíte hacky typu IDisposable ... a to proto, že nikdo nenapíše nativní toolkit.
25.2.2016 17:28 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
půlku věcí uvolní samo GC, a drouhou si řešíte hacky typu IDisposable
GC uvolní i objekty implementující IDisposable.
26.2.2016 12:45 Jardík
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Nakonec možná ... problém je, že GC nezná skutečnou velikost takového objektu, protože nemá páru, kolik naalokoval třeba přes malloc, nebo kolik file descriptorů vyplácal a nemůže ho tak odstranit prioritně. Taky takový objekt s destruktorem přežije podstatně déle, než normální objekt, protože se musí zařadit do fronty ... a z dtoru se může dokonce i znovu oživit a GC s tím musí počítat. O to horší je pak, že je třeba jeden objekt zničit před tím druhým, řekněme objekt z C je závislý na existenci nějakého factory objektu z C ... C# o tom samozřejmě neví, protože pointer je ukryt v C objektu. Pořadí spuštění dtorů si určí GC, a dostanete se do situace, kdy zničíte factory objekt před tím závislým a pak dostanete pád. V podstatě je tedy potřeba tu Dispose fci zavolat ve správném pořadí. Máte pak program ve stylu C, který má navíc overheady při volání nativních C fcí kvůli marshalování ... a to můžete rovnou psát v C.
26.2.2016 17:14 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
že GC nezná skutečnou velikost takového objektu, protože nemá páru, kolik naalokoval třeba přes malloc, nebo kolik file descriptorů vyplácal a nemůže ho tak odstranit prioritně
1) Informaci, kolik paměti je alokováno mimo heap spravovaný GC, lze sdělit runtimu voláním GC.AddMemoryPressure. Tato informace se pak použije při plánování úklidu paměti.

2) Informace o velikosti jednotlivých objektů neumí GC z CoreCLR ani Mona k prioritnímu uvolňování využít.

Pořadí spuštění dtorů si určí GC, a dostanete se do situace, kdy zničíte factory objekt před tím závislým a pak dostanete pád.
Tomu můžete předejít například pomocí GC.KeepAlive.
Máte pak program ve stylu C, který má navíc overheady při volání nativních C fcí kvůli marshalování ... a to můžete rovnou psát v C.
Nevím, zda například C umí automaticky rezervovat paměť pro běh destruktorů.
26.2.2016 17:46 Jardík
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
1) Informaci, kolik paměti je alokováno mimo heap spravovaný GC, lze sdělit runtimu voláním GC.AddMemoryPressure. Tato informace se pak použije při plánování úklidu paměti.
Jak tak čtu dokumentaci, tak to nevypadá, že je to informace pro jednotlivé objekty, ale nějaká globální iformace. GC tedy neví, jestli je můj objekt malý nebo velký.
Tomu můžete předejít například pomocí GC.KeepAlive.
Tohle se zdá funguje úplně jinak. Navíc jsme pak opět zpět u manuálního se starání o prostředky.
Nevím, zda například C umí automaticky rezervovat paměť pro běh destruktorů.
Nechápu tento komentář. C nemá destruktory, ale můžu za něj považovat třeba fci co objekt uvolní. Rezervovat paměť pro takovou fci není třeba. Je-li na zásobníku dostatek místa pro uložení návratové adresy pro call instrukci, fce se prostě spustí. Ale můj komentář byl o overheadech marshallování, to není většinou zadarmo, pokud často potřebuju volat takovou fci. Když se pak stejně navím musím manuálně starat o uvloňování dalších prostředků, tak pro mě NET nepřináší žádnou výhodu, jenom starosti. Jinak to samé platí i o Javě, vůbec to není namířené proti NETu.
26.2.2016 18:45 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Jak tak čtu dokumentaci, tak to nevypadá, že je to informace pro jednotlivé objekty, ale nějaká globální iformace.
Ano, jak píši v bodu 2), GC informaci o velikosti jednotlivých objektů neumí využít k jejich prioritnímu uvolňování dle velikosti – je zbytečné tuto informaci pro jednotlivé objekty uvádět.
Tohle se zdá funguje úplně jinak.
Z dokumentace: The purpose of the KeepAlive method is to ensure the existence of a reference to an object that is at risk of being prematurely reclaimed by the garbage collector.
Nechápu tento komentář.
Chtěl jsem poukázat na to, že .NET nabízí i něco v oblasti ruční správy paměti, co C nemá.
Rezervovat paměť pro takovou fci není třeba. Je-li na zásobníku dostatek místa pro uložení návratové adresy pro call instrukci, fce se prostě spustí.
Takže je třeba minimálně rezervovat místo na zásobníku pro danou funkci a všechny funkce, jenž zavolá.
Ale můj komentář byl o overheadech marshallování, to není většinou zadarmo, pokud často potřebuju volat takovou fci.
Výkon jde řešit pomocí tzv. FCallů (viz Choosing between FCall, QCall, P/Invoke, and writing in managed code), nicméně to není přenositelné a ani standardizované řešení.
Když se pak stejně navím musím manuálně starat o uvloňování dalších prostředků, tak pro mě NET nepřináší žádnou výhodu, jenom starosti. Jinak to samé platí i o Javě, vůbec to není namířené proti NETu.
Pokud chcete spravovat paměť výhradně ručně, tak .NET není dobré řešení. Situace se ovšem může změnit, když chcete část paměti spravovat ručně a část automaticky. Oproti Javě má .NET ukazatele.
26.2.2016 19:51 Tomas
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Prosim... Nemichej dohromady objekty idisposable a objekty s dtor (finalizerem). Jedna se zcela odlisne veci - jak z pohledu gc, tak zmpohledu jazyka.
25.2.2016 19:18 Tomas
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
A vite vubec, co je to disposable? To kupodivu s gc a tim jak tomcisti, nema nic spolecneho
Bluebear avatar 25.2.2016 12:23 Bluebear | skóre: 30 | blog: Bluebearův samožerblog | Praha
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
povedal by som, ze zo snov o ovladnuti sveta cez Windows sa uz MS vyliecil

Staré indické přísloví, které říkám všude, kde někdo praví, že se M$ zlepšil: tygr své pruhy nikdy nezmění.
To mi připomíná, jak jsem si pořídil květináč, že v něm budu mít květinu. Opravdu tam byla, ale potom být přestala...
25.2.2016 12:37 Sid
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Netvarme sa ze MS je teraz nejaka velka vynimka voci google, facebook atd.
pavlix avatar 25.2.2016 13:26 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Netvařme se, že není.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
xvasek avatar 25.2.2016 09:49 xvasek | skóre: 21 | blog: | Zlín
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
No, dobře, ale rozdíl je v tom, že kdyby mono zmizelo, tak by si toho možná ani nikdo nevšimnul. :-)
25.2.2016 10:06 j
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Coby, cast se jim nejspis hodi, a zbytek zahodej, delaj to tak se vsim co koupi, ve finale to pohrbej.
25.2.2016 12:31 Tomas
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Microsoftu je mono ukradeny. Na windowsech to nikdo nepouziva a na linuxu je to stale dost nepouzitelne. Krom toho, mono je komunitni projekt... A synergicky efekt s v soucasne dobe opensource .net frameworkem je jasny.

Duvod, proc MS koupil xamarin, je vcelku jasny - jejich tooly pro mobilni telefony (xamarin pro androind a ios, ktere jsounvelmi poiuzitelne a v portfoliu ms chybi)... A ms nema jediny duvod je jakymkoli zpusobem zarezavat, ale naopak - jsou pro ne zpusobem jak konkurovat jave na androidu a objective c na iosu.

Vetsina diskutujicich tady mi prijde, ze vubec nema tuseni, co xamarin dela, a plka plka a plka
25.2.2016 13:06 Zdenek 'Mst. Spider' Sedlak | skóre: 38 | blog: xMstSpider
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
+1
25.2.2016 17:32 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
na linuxu je to stale dost nepouzitelne
Proč myslíte?
26.2.2016 09:24 Boris Dušek | skóre: 22 | blog: everything
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
objective c na iosu.
dnes již hlavně Swiftu
vim ~/.emacs
26.2.2016 14:05 Qaxi | skóre: 14 | blog: Qaxi
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Nám Mono umožnilo převést CallCentrum kompletně na Linux.

Klient CallCentra vyžadoval jen drobnou úpravu co se týkala cest na FS (Win programátoři netuší, že C:\ nemusí být vždy dostupný ...).
25.2.2016 08:52 dustin | skóre: 62 | blog: dustin
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
M. de Icaza měl vždycky blízko k lidem z MS, tipnul bych si, že se tam s někým domluvil. MS má volný keš, tak proč jej trošičku nepodojit...
25.2.2016 21:22 pjoter
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Tak Miguel si asi splnil sen a po 20 letech se do Microsoftu konecne dostal.
25.2.2016 12:16 AlYoSHA
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Zbohom Mono. Stejne som ta nemal rad :-)
25.2.2016 12:44 balki
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Chcelo by to odstranit MONO z Mate, ak tam este nieco zostalo.
Fluttershy, yay! avatar 25.2.2016 17:50 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Embrace. Extend. Extinguish.

Lidé mají krátkou paměť.
xkucf03 avatar 25.2.2016 20:46 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
+1
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Tomáš Bžatek avatar 25.2.2016 18:23 Tomáš Bžatek | skóre: 29 | Brno
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin

To jim to ale trvalo. Cekal jsem to mnohem driv.

Koupim litajiciho tucnaka
25.2.2016 22:56 Odin1918 | skóre: 5 | blog: Valhalla
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Ze srdce to monu preji. Bud dojde k jeho zlepseni, coz by bylo dobre, nebo dojde k jeho umrti, coz zadna skoda s ohledem na opozdeni oproti .net frameworku nebude.
26.2.2016 12:20 Ivan
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
A v cem by se mely delat open-source desktop aplikace pro Linux? QT/C++ GTK? Kdyz se poudivam kolem sebe, tak vetsina open-source projektu pouziva python anebo javu a jedna se predevsim o webove aplikace. Mozna ze Linux desktop nikdy neovladne a misto toho si pockame az desktop upne umre.

Sam udrzuju opensource projekt ktery ma 300K radek v C++ a vidim ze to neni idealni. Pokud nepravidelne prispivate do kodu, ktery z hlavy neznate tak potrebujete nastroje, ktere vam umozni se v nem rychle zorientovat a na to neni C/C++ uplne nejlepsi. Kdeska uz to docela jde ale jeste pred par lety to bylo prakticky nemozne.

27.2.2016 19:15 Odin1918 | skóre: 5 | blog: Valhalla
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
A v cem by se mely delat open-source desktop aplikace pro Linux? QT/C++ GTK?
Java swing/awt, qt, gtk.
Mozna ze Linux desktop nikdy neovladne a misto toho si pockame az desktop upne umre.
Vyznam desktopu se posunuje, ale opravdu nikdy nevymre. Stroj, na kterem si pustis alespon prohlizec, budes potrebovat vzdy. Vzdycky tam bude muset byt nejaka vrstva, ktera bude pristupovat k hardware. V tomto bych pro Linux hledal naopak prilezitost.
Sam udrzuju opensource projekt ktery ma 300K radek v C++ a vidim ze to neni idealni.
Hmmm. Chcete soutezit? Ja mel na starosti nasobne vetsi projekty, ale o open source se opravdu nejednalo.
Pokud nepravidelne prispivate do kodu, ktery z hlavy neznate tak potrebujete nastroje, ktere vam umozni se v nem rychle zorientovat a na to neni C/C++ uplne nejlepsi.
Ono je velice lacine obvinit jazyk, ktery za to opravdu, ale opravdu nemuze. ;-) Kdyz se v kodu nevyznate, tak jsou mozne dve priciny: jste neschopny a mel byste delat jinou praci, nebo je navrh dane aplikace tak strasny, ze i kdyz jste schopny, tak se v nem nevyznate. Take je mozne, ze jste neschopny a dana aplikace ma hrozny navrh. ;-)
xkucf03 avatar 27.2.2016 19:28 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše GUI – Java, Swing, AWT, Qt, GTK
Java swing/awt, qt, gtk.

AWT dneska už moc ne. Se zbytkem souhlas.

A jak Qt, tak GTK se dá používat i v Javě tzn. nativní GUI.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
27.2.2016 20:47 Odin1918 | skóre: 5 | blog: Valhalla
Rozbalit Rozbalit vše Re: GUI – Java, Swing, AWT, Qt, GTK
+1

Awt uz je dnes opravdu mimo. Stejne jako ja mimo programovani. Roky bohuzel opravdu plynou. :-) Na qt/gtk v jave se podivam. Dekuji za tip.
28.2.2016 09:44 Ivan
Rozbalit Rozbalit vše Re: GUI – Java, Swing, AWT, Qt, GTK
Qt jambi byl vylice nadejny projekt. Vyvoj to bylo mnohem ryhlejsi nez Qt/C++. Preci jen Java se snaz parsuje a doplnovani v Jave funguje mnohem lepe. Takze jsem mohl vic psat a min koukat do dokumentace Qt.

Na pouzivani to bylo mnohem jednodussi nex Eclipse RCP. Dal se s tim pouzivat GUI designer z Qt, takze nebylo potreba navrhovat GUI v kodu. Bohuzel se Qt Jambi uz nekolik let nachazi ve stadiu klinicke smrti. Udrzuje to uz jen par lidi, kteri to potrebuji pro svoje projekty.
Fluttershy, yay! avatar 27.2.2016 19:51 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Pokud nepravidelne prispivate do kodu, ktery z hlavy neznate tak potrebujete nastroje, ktere vam umozni se v nem rychle zorientovat a na to neni C/C++ uplne nejlepsi.
Ono je velice lacine obvinit jazyk, ktery za to opravdu, ale opravdu nemuze. ;-) Kdyz se v kodu nevyznate, tak jsou mozne dve priciny: jste neschopny a mel byste delat jinou praci, nebo je navrh dane aplikace tak strasny, ze i kdyz jste schopny, tak se v nem nevyznate. Take je mozne, ze jste neschopny a dana aplikace ma hrozny navrh. ;-)

Guido van Rossum:

This is all very informal, but I heard someone say a good programmer can reasonably maintain about 20,000 lines of code. Whether that is 20,000 lines of assembler, C, or some high-level language doesn't matter. It's still 20,000 lines. If your language requires fewer lines to express the same ideas, you can spend more time on stuff that otherwise would go beyond those 20,000 lines.

A 20,000-line Python program would probably be a 100,000-line Java or C++ program. It might be a 200,000-line C program, because C offers you even less structure. Looking for a bug or making a systematic change is much more work in a 100,000-line program than in a 20,000-line program. For smaller scales, it works in the same way. A 500-line program feels much different than a 10,000-line program.

xkucf03 avatar 27.2.2016 20:13 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Python?
A 20,000-line Python program would probably be a 100,000-line Java or …

Docela úsměvné představy. Takových dojmů obvykle nabývají lidé, když se podívají na HelloWorld v Javě a porovnají to s nějakým skriptovacím jazykem.

U céčka bych možná souhlasil, i když ani tam to s použitím vhodných knihoven a vhodného návrhu nebude tolik kódu. U C++ to IMHO není pravda vůbec.

Whether that is 20,000 lines of assembler, C, or some high-level language doesn't matter.

Ne, to opravdu ne. Stejně jako jsou knihy, které se čtou snadno a jsou knihy, kde člověk musí přemýšlet nad každou větou, číst ji třikrát a stejně části z nich neporozumí… tak je i kód, který se čte lehce, který stačí proletět očima a člověk ví, co kód dělá a že v něm není žádná zákeřnost, a pak je kód, u kterého si ani po důkladném čtení nejsi úplně jistý a radši si ho spustíš nebo i projdeš v debuggeru.

Programy v Javě obsahují hodně lehkého vzdušného kódu. Stejně jako třeba SQL odsazené tak, že na spoustě řádků je jen jedno slovo (název sloupečku) nebo třeba jeden výraz (podmínka). I když by to samozřejmě šlo napsat na jeden řádek.

Looking for a bug or making a systematic change is much more work in a 100,000-line program than in a 20,000-line program.

Tohle už je úplně mimo – kdo má pochybnosti, ať si zkusí refaktorovat kód v Javě a kód v Pythonu.

Co se týče hledání chyb – hledal jsem chyby i v javovském kódu od Indů a i v pythoním kódu od kolegy od vedlejšího stolu – v Pythonu to bylo řádově složitější a to i když započtu fakt, že znám líp Javu než Python. Problém s hledáním chyby měl i autor toho kódu.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Fluttershy, yay! avatar 27.2.2016 21:14 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Python?
porovnají to s nějakým skriptovacím jazykem

Non sequitur.

Whether that is 20,000 lines of assembler, C, or some high-level language doesn't matter.
Ne, to opravdu ne. Stejně jako jsou knihy, které se čtou snadno a jsou knihy, kde člověk musí přemýšlet nad každou větou, číst ji třikrát a stejně části z nich neporozumí…

To, o čem píšeš, je sémantika. Jenže člověk musí v prvé řadě interagovat s její reprezentací.

Můžeme použít jinou analogii, a sice že člověk kvůli fyzikálním limitům nedohlédne za obzor.

Pokud se vrátím k sémantice, je otázka, zda se tím myslí logické řádky kódu, nebo prostě řádky.

Nicméně, odpověď může poskytnout kognitivní věda, o jejíchž výsledcích v tomto směru aspoň z hlavy nevím; jinak je to jenom tvůj/můj/Odinův/Guidův názor.

27.2.2016 21:27 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Python?
A 20,000-line Python program would probably be a 100,000-line Java or …
Docela úsměvné představy. Takových dojmů obvykle nabývají lidé, když se podívají na HelloWorld v Javě a porovnají to s nějakým skriptovacím jazykem.
IMO více než polovinu programu v Javě tvoří balast, který by šlo odstranit. Konkrétně například nepotřebná klíčová slova public a private (stačí zvolit vhodný default a výraznou část jich nebudete potřebovat), gettery a settery, složené závorky, středníky, typy uvnitř metod (lze většinou odvodit lokální typovou inferencí).

Další kód odstraníte, když dovolíte, aby se některé řídíci konstrukce (např. if a switch) chovaly jako výrazy. Standardní knihovna v Javě není příliš dobře navržená – řada funkcí tam chybí, některé části jsou zdvojené (nio a io).
xkucf03 avatar 27.2.2016 21:55 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Python?

Jenže tohle všechno jsou věci, které při čtení prakticky nevnímám, nebrzdí mě to a pokud ano, je to pod moji rozlišovací schopnost. Řádově víc času trávím přemýšlením nad obsahem – co program dělá a proč ho právě tak někdo napsal, jaký je za tím smysl. Ne jestli jsou někde složené závorky nebo ne, to je opravdu nepodstatné. A tam hraje daleko větší roli návrh programu, použití vhodných knihoven a jak schopný programátor ten kód psal, než detaily zápisu, o kterých píšeš.

Je to podobné jako honit se za co nejvyšším počtem úhozů za minutu – když ti řádově víc času zabere přemýšlení, než zápis myšlenek na klávesnici. Rozdíl mezi normální rychlostí psaní a přeborníkem v psaní na stroji pak na celkový výsledek nemá prakticky žádný vliv.

typy uvnitř metod (lze většinou odvodit lokální typovou inferencí)

Někdy se to může hodit, ale taky to může být kontraproduktivní.

Pokud tam je třeba:

Map<Integer,String> proměnná = new HashMap<>();

tak je tam sice vpravo a vlevo částečně duplicitní informace, ale je to přesně kód který jen přeletím očima a moc se nezdržuji s jeho čtením. Kdyby tam místo toho bylo:

var proměnná = new HashMap<Integer,String>();

Tak mi to čtení nijak zásadně neusnadní. A dokonce i délka řádku je skoro stejná.

A kdyby tam bylo:

var proměnná = získejData();

tak ani nevím, jaký typ tam bude – musím se podívat na hlavičku té metody nebo si zobrazit JavaDoc. Což zabere víc času, odvádí to pozornost a narušuje to plynulost čtení víc, než třeba částečně duplicitní informace v prvním příkladu.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
27.2.2016 22:10 dustin | skóre: 62 | blog: dustin
Rozbalit Rozbalit vše Re: Python?
Naprosto souhlasím. Navíc tu levou část často vygeneruje přímo IDE, takže při psaní ani moc nezdržuje a vím hned přesně, jaký datový typ tam je. Osobně moc nerozumím snaze mít kód co nejkratší, když daleko důležitější je přehlednost/čitelnost/udržovatelnost.
27.2.2016 22:16 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Python?
Navíc tu levou část často vygeneruje přímo IDE
Ano, kód ale bude delší než v Pythonu nebo Scale nebo F# (a o tom se tu bavíme).
Osobně moc nerozumím snaze mít kód co nejkratší, když daleko důležitější je přehlednost/čitelnost/udržovatelnost.
IMO přehlednost/čitelnost/udržovatelnost souvisí s délkou kódu.
27.2.2016 22:34 dustin | skóre: 62 | blog: dustin
Rozbalit Rozbalit vše Re: Python?
IMO přehlednost/čitelnost/udržovatelnost souvisí s délkou kódu.
To si až tak nemyslím. Pro mě je podstatné v každém okamžiku vidět podstatné údaje. A vůbec mi nevadí, že to o ně bude delší.

Příklad z níže uvedeného lomboku:
13   public void example2() {
14     val map = new HashMap<Integer String>();
15     map.put(0, "zero");
16     map.put(5, "five");
17     for (val entry : map.entrySet()) {
18       System.out.printf("%d: %s\n", entry.getKey(), entry.getValue());
19     }
20   }
13   public void example2() {
14     final HashMap<Integer, String> map = new HashMap<Integer, String>();
15     map.put(0, "zero");
16     map.put(5, "five");
17     for (final Map.Entry<Integer, String> entry : map.entrySet()) {
18       System.out.printf("%d: %s\n", entry.getKey(), entry.getValue());
19     }
20   }
Stokrát raději budu číst
for(final Map.Entry<Integer, String> entry : map.entrySet())
a vědět přesně, co v tom entry je, než sice krátké, ale pro mě naprosto nepřehledné
for (val entry : map.entrySet())
I kdyby IDE správně nabízelo konkrétní typy entry.key, entry.value, stejně raději explicitně uvidím, co tam vlastně je. Navíc ta map vůbec nemusí být definovaná o pár řádků výše, ale může jít o volání funkce a návratová hodnota pak nebude nijak vidět.
Může tam být

proměnná = HashMap()
To může, ale v takovém případě jde ten kód úplně do kytek.
27.2.2016 22:46 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Python?
Příklad z níže uvedeného lomboku:
Obojí je ukázka, jak obrovské množství balastu je v Javě.
Stokrát raději budu číst
V tomto případě bych raději četl kód bez typu, protože typ je zřejmý. Naopak nevidím důvod, proč typ neuvést explicitně na místech, kde to kód zpřehlední.
27.2.2016 23:03 dustin | skóre: 62 | blog: dustin
Rozbalit Rozbalit vše Re: Python?
Typ vůbec není zřejmý, nikde. Obzvláště s kvalitou pojmenování proměnných průměrných programátorem. Viz např. ono použité "map" místo např. namesByID.

Každý den refaktoruji/rozšiřuji/čistím kód poměrně rozsáhlého projektu a čím víc přesných typů je uvedeno, tím přehlednější a udržovatelnější to je. Počet znaků/omáčka kolem má pro mě podstatně nižší prioritu.

A při psaní je to jedno, stejně to vygeneruje IDE. Ta smyčka je na pár klepnutí do klávesnice.

Samozřejmě nahradit smyčky streamy v javě 8 je něco jiného, to ale z řady jiných důvodů.
27.2.2016 23:26 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Python?
Typ vůbec není zřejmý, nikde.
Když je o pár řádků nad tím vidět, co do mapy přiřazujete, tak jsou typy jasné.
čím víc přesných typů je uvedeno, tím přehlednější a udržovatelnější to je.
V Javě příliš přesné typy uvádět nejde, bohužel. Například je problematické odlišit id od obyčejného integeru. V Javě byste zřejmě musel vytvořit třídu a do ní integer zabalit, jenže to může mít neblahé důsledky na výkon programu (nemáte hodnotové třídy). V C#, F# i Scale to můžete udělat lépe. Například Scala má hodnotové třídy a refinement typy (type IdUzivatele = Int @@ Uzivatel), kde
type Tagged[U] = { type Tag = U }
type @@[T, U] = T with Tagged[U]
28.2.2016 12:51 dustin | skóre: 62 | blog: dustin
Rozbalit Rozbalit vše Re: Python?
Jo, ty refinement typy by se hodily. Čím přesnější (a bližší) definice typu/významu, tím lepší.

Jenže byznys není o ideálním řešení v daném čase, ale o realitě. Náš systém začínal před 15 lety a pořád se jej v javě daří aktualizovat, modernizovat, urychlovat. V dohledné době vyhodíme poslední komponentu bránící nasazení javy 8 (stará verze gwt) a začnou se používat streamy a delty. U streamů se dobře využije paralelizace - další urychlení. V dalších verzích javy lze očekávat hodnotové typy, dnes to již sice kompilátor víceméně odstíní, ale výkonový nárůst se bude hodit.

Před 15 lety, kdy jsme designovali základy toho řešení, tyhle věci možná existovaly teoreticky, prakticky to nikdo neznal, natož aby mohl v praxi používat. A ten systém nemá důvod nerozvíjet se dalších 10 let. Pořád jej lze modernizovat, posouvat dál. Přepisovat sw do jiného jazyka, který zrovna frčí, jenom pro ten přepis, je nesmysl, proveditelný (zaplatitelný) možná tak v akademické sféře. Navíc jsem přesvědčený, že java tu bude ještě hodně dlouho a pořád se bude rozvíjet.

Ale aby šlo něco rozvíjet desítky let (tj. aby to opravdu sloužilo), musí být kód přehledný a typově co nejvíc svázaný. Takže taková HashMap() opravdu ani náhodou (to se vyřešilo při úpravách během zavádění generik). I případné groovy skripty se při změnách přepisují do javy, ten jazyk je sice stručný, ale jeho refaktoring je plně závislý na schopnostech IDE, což není dostatečně bezpečné. A pro mě není přehledný ani trochu, když na první pohled nevidím datové typy. Jo, pokud budou ty typy ještě přesnější, jenom lépe.
28.2.2016 13:09 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Python?
Navíc jsem přesvědčený, že java tu bude ještě hodně dlouho a pořád se bude rozvíjet.
To asi ano, jenže ten rozvoj je velmi pomalý a v řadě věcí byl C# napřed (například hodnotové typy, generika, lambda funkce).
Před 15 lety, kdy jsme designovali základy toho řešení, tyhle věci možná existovaly teoreticky, prakticky to nikdo neznal, natož aby mohl v praxi používat.
Záleží, co přesně myslíte. Řada věcí jako například lepší typová inference, generika a vůbec silnější typový systém jsou v OCamlu více než 15 let. Bohužel OCaml málokdo používá, tudíž má málo knihoven – to byl velký problém dříve a stále je to problém i dnes.
28.2.2016 13:28 dustin | skóre: 62 | blog: dustin
Rozbalit Rozbalit vše Re: Python?
Možná je rozvoj pomalý, ale neustálý a současně se daří držet zpětnou kompatibilitu. C# je daleko mladší než java, navíc není multiplatformní. Dlouhodobé projekty mají vůči novinkám stejně zpoždění, takže je často nemohou používat hned od jejich zavedení. A opravdu nemíním měnit spolehlivý OS se stejně garantovanou budoucností za jiný kvůli tomu, že se do C# některé věci dostávají dříve než do javy.

Řada věcí jako například lepší typová inference, generika a vůbec silnější typový systém jsou v OCamlu více než 15 let.
To je hezké teoreticky, ale prakticky k ničemu. Zvolit před 15 lety OCaml místo javy by opravdu nebyla výhra.

I když jsme už v té době synchronizovali síťové disky mezi lokalitami unisonem, který je v OCamlu napsaný a dodnes funguje parádně :-)
28.2.2016 14:07 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Python?
C# je daleko mladší než java, navíc není multiplatformní.
Multiplatformní již je několik let.
Dlouhodobé projekty mají vůči novinkám stejně zpoždění, takže je často nemohou používat hned od jejich zavedení.
Řadu těch věcí uměl OCaml v roce 1995 (tehdy pod názvem Caml Special Light) a další přidal v roce 1996 (pod názvem Objective Caml) – tj. v době JDK 1.0 nebo ještě dříve.
Zvolit před 15 lety OCaml místo javy by opravdu nebyla výhra.
Třeba by vám stačila desetina kódu, co máte dnes v Javě.
28.2.2016 16:35 dustin | skóre: 62 | blog: dustin
Rozbalit Rozbalit vše Re: Python?
Multiplatformní již je několik let.
:-) Opravdu doporučujete klientům pro větší dlouhodobé projekty mono na linuxu? Tahle diskuse se posouvá úplně mimo realitu...
Zvolit před 15 lety OCaml místo javy by opravdu nebyla výhra.
Třeba by vám stačila desetina kódu, co máte dnes v Javě.
Sice by to bylo daleko dražší (personálně i časově - neexistující knihovny) a totálně neudržitelné z důvodu neexistence kvalitního vývojového prostředí, ale ušetřili bychom trochu diskového prostoru na gití commity. To je přesně to, o čem mluvím. Stručnost zdrojáku je z mé zkušenosti u dlouhodobých projektů téměř irelevantní, daleko důležitější jsou jejich rozvíjitelnost, aktualizovatelnost na nové technologie a samozřejmě taky dostupnost šikovných lidí, kteří jsou ochotni za zaplatitelné peníze na tom dělat. V těchhle diskusích mi přijde, že diskutují samí teoretici z akademické sféry, kteří jsou placení bezedným erárem...
28.2.2016 17:30 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Python?
Opravdu doporučujete klientům pro větší dlouhodobé projekty mono na linuxu?
Ano, nebál bych se toho. Proč myslíte, že to není dobrý nápad?
a totálně neudržitelné z důvodu neexistence kvalitního vývojového prostředí, ale ušetřili bychom trochu diskového prostoru na gití commity
Díky bohatému typovému systému je to lépe udržovatelné a refaktorovatelné než Java s těmi nejlepšími IDE.
Sice by to bylo daleko dražší (personálně i časově - neexistující knihovny)
Třeba v Jane Street došli k opačnému závěru. Revize kódu v Javě byly mnohem dražší a méně učinné než pro OCaml.
xkucf03 avatar 28.2.2016 17:45 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše OCaml?
Díky bohatému typovému systému je to lépe udržovatelné a refaktorovatelné než Java s těmi nejlepšími IDE.

Proč se v OCamlu tedy nepíše víc programů?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
28.2.2016 17:57 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: OCaml?
Nemám tušení, ale hádám, že mu chybí marketing a lidé, co by v něm programovali (málo se to učí na školách).

Mj. programy, kde jde o symbolický výpočet (kompilátory, nástroje pro analýzu programů, dokazovače), se často píší v OCamlu nebo podobných jazycích.
28.2.2016 21:39 tacoberu | skóre: 5
Rozbalit Rozbalit vše Re: Python?
Typ vůbec není zřejmý, nikde. Obzvláště s kvalitou pojmenování proměnných průměrných programátorem. Viz např. ono použité "map" místo např. namesByID.

Každý den refaktoruji/rozšiřuji/čistím kód poměrně rozsáhlého projektu a čím víc přesných typů je uvedeno, tím přehlednější a udržovatelnější to je. Počet znaků/omáčka kolem má pro mě podstatně nižší prioritu.
K čemu je to dobré uvádět tam ty typy (když inference funguje)? Pro mě jsou typy životně důležité, ale nevím proč bych je tam měl nutně číst? Důležité je, aby to chcíplo, když tam typy nesedí. Toto nechápu. Vysvětlíte?
xkucf03 avatar 28.2.2016 21:54 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Odvozování typů

Když přijdu k nějakému kódu, tak bych rád na první pohled viděl o jaké datové typy jde, abych nemusel postupovat metodou pokus-omyl a čekal, až mi kompilátor zahlásí chybu, nebo abych musel odskakovat někam jinam (do hlavičky volané metody nebo otevírat JavaDoc).

Nechci dělat z nouze ctnost – někdy je to opravdu zřejmé a odvozování typů místo jejich explicitní deklarace smysl má, ale až tak bych ho nepřeceňoval – jednak deklarovat typy explicitně není až taková tragédie a jednak nedeklarovat je může mít naopak negativní vliv na čitelnost a těch ušetřených pár znaků se nevyplatí.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
28.2.2016 23:45 tacoberu | skóre: 5
Rozbalit Rozbalit vše Re: Odvozování typů

Když přijdu k nějakému kódu, tak bych rád na první pohled viděl o jaké datové typy jde, abych nemusel postupovat metodou pokus-omyl a čekal, až mi kompilátor zahlásí chybu, nebo abych musel odskakovat někam jinam (do hlavičky volané metody nebo otevírat JavaDoc).

Proč byste to dělal? Prostě kouknete a vidíte, aha tady teče kurzor z téhle funkce sem, tady se s tím dělají tyto operace, tady se to transformuje na toto... K čemu typy? Typy budete zkoumat v okamžiku, kdy řešíte omezení hodnot, polymorfizums, etc, a tam je Java poněkud málo příkladná, takže toto bych raději nerozváděl.
může mít naopak negativní vliv na čitelnost a těch ušetřených pár znaků se nevyplatí
Může být. Stejně jako že zbytečná ukecanost. Mě přijde, že Java naučila Céčkové programátory, že funkce a proměnné se dají pojmenovávat inteligentně. To je její historická zásluha. A také, že se to krapet zvrhlo.
pavlix avatar 29.2.2016 00:06 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Odvozování typů
Mě přijde, že Java naučila Céčkové programátory, že funkce a proměnné se dají pojmenovávat inteligentně.
Lze to nějak historicky doložit nebo je to dojmologie? Ptám se vážně.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
Hans1024 avatar 29.2.2016 01:09 Hans1024 | skóre: 5 | blog: hansovo
Rozbalit Rozbalit vše Re: Odvozování typů
Ja bych sazel na tu dojmologii, vzhledem k tomu, ze delsi a popisnejsi nazvy byly pouzivany u X11 minimalne 10 let predtim, nez se objevila nejaka Java.
Veni, vidi, copi
pavlix avatar 29.2.2016 07:32 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Odvozování typů
+1

Něco takového jsem čekal.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
29.2.2016 01:41 tacoberu | skóre: 5
Rozbalit Rozbalit vše Re: Odvozování typů
Psal jsem "mě přijde", takže to je asi jasné.

Když si vzpomenu na všechny ty staré zdrojáky psané v C, tak psaní kriptických názvů byl a obávám se, že stále je, rozšířený nešvar: printf, fprintf, vfprintf, sprintf, vsprintf, budiž příkladem.

Java na to šla z druhé strany. Tam zase vznikla soutěž o co nejdelší a nejdebilnější název dávající smysl. A že všechny funkce musí začínat get/set/is i když dělají s tím zcela nesouvisející věci.

Netvrdím, že to není lepší. Netvrdím, že před Javou neexistovali chytří lidé, kteří psali čitelnější kód. Ale Java to IMHO uvedla jako normální.
pavlix avatar 29.2.2016 07:34 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Odvozování typů
Takže jde vlastně o to, že Java přinesla monokulturu.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
xkucf03 avatar 29.2.2016 08:02 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Odvozování typů
A že všechny funkce musí začínat get/set/is i když dělají s tím zcela nesouvisející věci.

Konvence je, že název metody má obsahovat sloveso (zatímco název třídy podstatné jméno, název rozhraní přídavné…). Když metoda něco vrací, tak se logicky jmenuje getNěco() ne něco(). Je to IMHO dobrá konvence. A konkrétní předpony get/set/is jsou součástí specifikace JavaBean a tam ty metody dělají přesně to, co název říká. Někdy mají lidé tendenci je používat i jinde – např. getNěco(…) s parametrem – tam je lepší použít find/lookup/create/najdi/… nebo třeba metoda setNěco(…, …) se dvěma parametry, která něco nastavuje tomu prvnímu parametru místo instanci, na které je volána – tam stojí za zvážení zase slova fill, update atd. aby se to odlišilo od klasických getterůsetterů. Každopádně sloveso v názvu metody je dobrá věc.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
29.2.2016 12:39 tacoberu | skóre: 5
Rozbalit Rozbalit vše Re: Odvozování typů
A že všechny funkce musí začínat get/set/is i když dělají s tím zcela nesouvisející věci.

... Každopádně sloveso v názvu metody je dobrá věc.

Vo tom žádná.
pavlix avatar 28.2.2016 21:00 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Python?
Osobně moc nerozumím snaze mít kód co nejkratší, když daleko důležitější je přehlednost/čitelnost/udržovatelnost.
Třeba proto, abych si nemusel kupovat obří display jen proto, aby se mi smysluplná část kódu zobrazila najednou.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
27.2.2016 22:11 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Python?
Jenže tohle všechno jsou věci, které při čtení prakticky nevnímám, nebrzdí mě to a pokud ano, je to pod moji rozlišovací schopnost.
Mě osobně to brzdí. Například mezi triviálními gettery a settery se může ztratit jeden důležitý netrivální setter.

Například pro 10 veřejných tříd, kdy každá má 2 vlastnosti s getterem a setterm budu v Javě potřebovat 10 souborů, každý o cca 10 řádcích:
public class Foo {
  private int x;
  private int y;

  public int getX() { return x; }
  public void setX(int n) { x = n; }

  public int getY() { return y; }
  public void setY(int n) { y = n; }
}
Tj. celkem 100 řádků. Ve Scale jednu takovou třídu zapíšete
case class Foo(x: Int, y: Int)
a všechny můžete dát do jednoho souboru. Celkem tedy 10 řádků.
Rozdíl mezi normální rychlostí psaní a přeborníkem v psaní na stroji pak na celkový výsledek nemá prakticky žádný vliv.
Problém je to spíš při čtení – v hromadě balastu je třeba objevit důležitý kód. Brzdí to při review a prodlužuje úpravy.
A kdyby tam bylo: var proměnná = new HashMap<Integer,String>();
Může tam být
proměnná = HashMap()
Někdy se to může hodit, ale taky to může být kontraproduktivní.
Ano, když si myslím, že se to hodí, typ tam nechám. V Javě ho tam musíte nechat vždy.
xkucf03 avatar 27.2.2016 22:55 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Python?
Příloha:
Například mezi triviálními gettery a settery se může ztratit jeden důležitý netrivální setter.

Tohle je hlavně o kvalitách programátora, který to psal – slušnost je dát ten netriviální setter nahoru a/nebo ho okomentovat. Ne si hrát s ostatními na schovávanou.

Co mi v Javě chybí je zvláštní druh JARů, který by mohl obsahovat jen rozhraní a datové struktury, ale žádnou funkcionalitu, což by se kontrolovalo při načítání toho JARu. Pak bys mohl snadno použít knihovnu definující nějaké API a nemusel bys dělat audit jejího kódu – ten by udělalo běhové prostředí.

Nebo se na to dá jít z opačného konce – mít IDE, které rozparsuje zdroják, detekuje triviální gettery/settery a skryje je – uvidíš je v navigátoru a bude ti je napovídat, ale nebudeš ten kód muset číst – zbudou ti tam jen netriviální metody.

Netbeans umí rozpoznat JavaBean a ukáže ti, jestli je tam getter, setter nebo obojí (viz příloha). Šlo by tam přidat detekci těch triviálních, které jen nastaví/přečtou stejnojmennou proměnnou, a skrytí jejich kódu.

Může tam být proměnná = HashMap()

Což je dost na nic, protože neznám typ klíčů a hodnot, takže se mi těch ušetřených pár znaků (<Integer,String>) brzo vrátí (typová nebezpečnost, nutnost ručního přetypování).

Nebo snad nějaký jazyk dokáže odvozovat typy tak, že uhlídá tohle:

proměnná = HashMap();
proměnná.put(1, "ahoj");
proměnná.put(2, "nazdar");
proměnná.put("x", "3");
proměnná.put(4, new Date()); 
metoda5(proměnná.get(1));
int x6 = proměnná.get(1);

U 3 by měl kompilátor zahlásit chybu – nebo taky ne (co když chci jako klíč mít Object?). U 4 taky – ale co když chci mít jako hodnotu Object (nebo nejbližší společný nadtyp)? U 5 metoda očekává parametr typu int, ale z proměnná = HashMap() není poznat, co bude uvnitř. Totéž u 6.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
27.2.2016 23:11 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Python?
V následujícím kódu
    let proměnná = Dictionary()
    proměnná.Add(1, "ahoj")
    proměnná.Add(2, "nazdar")
    proměnná.Add("x", "3")
    proměnná.Add(4, DateTime.Now)
zahlásí kompilátor F# chybu pro 3 a 4.
U 4 taky – ale co když chci mít jako hodnotu Object (nebo nejbližší společný nadtyp)?
Musíte si to ručně ošetřit – buď tam napsat typy (například Dictionary<_, obj>() pro 4) nebo první hodnotu přetypovat ("ahoj" :> obj).
xkucf03 avatar 27.2.2016 22:02 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Python?

BTW: co se týče getterůsetterů – projekt Lombok, předpokládám, znáš. Není to úplně optimální, je to trošku hack, ale používat se to v zásadě dá.

Struktura pak vypadá zhruba takhle:

@Data
public class MojeStruktura {
    private int id;
    private String jméno;
    private Data datum;
}

gettery/settery jsou jen v bajtkódu a ne ve zdrojáku. Samozřejmě se to dá kombinovat s dalším kódem, takže to nemusí být jen hloupá struktura, může mít zároveň metody, a taky se dají anotovat jen některé proměnné pomocí @Getter, @Setter.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
27.2.2016 22:26 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Python?
co se týče getterů a setterů – projekt Lombok, předpokládám, znáš
To už ale není platná Java (je třeba preprocessing). Navíc se nezbavíte prefixů get, set a is u vygenerovaných metod.
27.2.2016 20:48 Odin1918 | skóre: 5 | blog: Valhalla
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Nesouhlasim. A to, ze autor pythonu haji python, sve dite, mne opravdu neprekvapuje. :-D
Fluttershy, yay! avatar 27.2.2016 20:55 Fluttershy, yay! | skóre: 85 | blog:
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Totéž se dá říct o libovolném jazyce se srovnatelnou úrovní abstrakce. Ostatně se to ukazuje i v praxi – viz např. zařazení QML do Qt.
Hans1024 avatar 28.2.2016 12:57 Hans1024 | skóre: 5 | blog: hansovo
Rozbalit Rozbalit vše Re: Microsoft kupuje Xamarin
Desktopove aplikace v Jave prosim ne.
Veni, vidi, copi
xkucf03 avatar 28.2.2016 13:33 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Java a desktopové aplikace

-1

Samozřejmě nativní GUI je nativní GUI1, ale na prvním místě je pro mě funkcionalita – a tam mám mnohem lepší zkušenost s programy psanými v Javě – programy v jiných jazycích bývají často neskutečný bastl (nespolehlivost, pády) nebo kladou vysoké nároky na programátora (tzn. pomalejší vývoj a/nebo vyšší náklady) nebo obsahují bezpečnostní chyby, které by se v Javě (za jinak stejných okolností) nestaly.

Neříkám, že jinde nejde napsat dobrá desktopová aplikace, ale má to řadu rizik. Kdybych si jako firma objednával podnikový software (resp. jeho desktopovou část), tak bych mnohem radši šel do Javy (klidně i Swingu) než něčeho jiného.

[1] ale i to je v Javě dosažitelné

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Hans1024 avatar 28.2.2016 15:52 Hans1024 | skóre: 5 | blog: hansovo
Rozbalit Rozbalit vše Re: Java a desktopové aplikace
Kdyz uz mluvime o "neskutecnem bastlu", napada me Jitsi se svym spatnym vykonem a pametovymi naroky.

Rozhodne si nemyslim, ze by se vsechno melo psat v Cecku, zvlast kdyz to neni nejak vykonove narocne, ale myslim, ze je mnoho jazyku jinych nez Java, ktere jsou pro ten ukol vhodne a u kterych by nad vysledkem narikalo min lidi.

Java rozhodne neni nejakym etalonem bezpecnosti. Akorat zabrani lowlevel Ceckovym chybam, stejne jako vetsina ostatnich jazyku. Navic JIT kompilace bezpecnost zhorsuje.

Je mi celkem jedno v cem si firmy objednavaji svuj podnikovy software. Vetsinu aplikaci ktere pouzivam zacal psat ve volnem case nejaky silenec, a az pak se do toho pripadne vlozili placeni vyvojari.
Veni, vidi, copi
27.2.2016 19:08 Lopata
Rozbalit Rozbalit vše CoreCLR a komplet překopaný .NET
Nevím jestli jste si všimli, ale MS začal před delší dobou .NET komplet překopávat a to v podstatě jako open source - https://github.com/dotnet/coreclr. Open source je v podstatě všechno důležité včetně core runtime, GC, JITu. A navíc to běží to na Win, Mac OSX, Linuxu. Dokonce chystají i kompiler do nativního kódu pomocí LLVM.

A jdou na to moc dobře - bych řekl komponentově, což právě chybí Javě, tam se o to snaží léta a furt nic.

Takže pokud do toho zapojí vývojáře Mona, které stejně táhl jedině Xamarin a zúročí jejich zkušenosti, tak jsem pro a ať Mono skončí, proč mít zas dvě implementace téhož.

.NET má potenciál stát se platformou i pro Linux aplikace, zejména ty serverové. O ten server a ASP.NET stack se snaží primárně, mají i už komplet nové celkem slušně výkoné HTTP běhové prostředí nad libuv, podobně jako node.js
xkucf03 avatar 27.2.2016 19:52 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Java a modularita; MS svinstvo
A jdou na to moc dobře - bych řekl komponentově, což právě chybí Javě, tam se o to snaží léta a furt nic.

Modularita v Javě je přes patnáct let (viz OSGi) a od verze 9 bude přímo součástí platformy. Co se týče modularity standardní knihovny, tam myslím Java trefila právě vhodný stupeň granularity – jsou tu edice SE/EE/ME, ale víc už se to netříští, takže když nějaký program vyžaduje třeba Javu SE 6+ a ty stejnou nebo vyšší verzi Javy SE máš, tak víš, že ti to bude fungovat – celkem jednoduchá rovnice, kterou si každý dokáže spočítat, snadno se specifikují požadavky na instalované komponenty. Ne jako jinde, kde nestačí říct, jakou verzi platformy vyžaduješ, ale musíš říct, jaké všechny moduly/komponenty se mají nainstalovat – na což autoři programů zhusta kašlou, takže pak musíš postupovat metodou pokus-omyl a zkoumat, v jaké fázi běhu program spadl a kterou knihovnu vyžadoval, a doprošovat se administrátora, aby ti ji doinstaloval. Nebo si ji můžeš doinstalovat sám do ~/, ale to je nesystémové a má to řadu úskalí – možná bezpečnostní rizika při stahování, ne/ověřování podpisů, musíš se starat sám o aktualizace knihoven (nedělá to za tebe autor aplikace ani správce systému a/nebo balíčkovací systém).

Posunout to někam dál než jen SE/EE/ME může být přínos… ale než to udělat špatně, to to raději nedělat vůbec a odložit to – nenadělat víc škody než užitku.

Takže pokud do toho zapojí vývojáře Mona, které stejně táhl jedině Xamarin a zúročí jejich zkušenosti, tak jsem pro a ať Mono skončí, proč mít zas dvě implementace téhož.

Smyslem Mona bylo umožnit běh původních aplikací na svobodné platformě a zbavit se závislosti na proprietárním OS. Smysl současných snah Microsoftu a jeho „otevřenosti“ je přesně opačný – přetáhnout k sobě autory aplikací a pak donutit uživatele migrovat na MS Windows. S různými nekalými praktikami má MS dlouhodobé zkušenosti a je v tom hodně dobrý. Když se někdo celou dobu chová jako svině, tak není důvod mu věřit, že se najednou bude chovat slušně. Je mi líto lidí, kteří mají tak krátkou paměť.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
27.2.2016 20:40 Lopata
Rozbalit Rozbalit vše Re: Java a modularita; MS svinstvo
Modularita v Javě je přes patnáct let (viz OSGi) a od verze 9 bude přímo součástí platformy.
To je přesně o čem mluvím, 15 let se snaží a pořád nic.
Smyslem Mona bylo umožnit běh původních aplikací na svobodné platformě a zbavit se závislosti na proprietárním OS. Smysl současných snah Microsoftu a jeho „otevřenosti“ je přesně opačný.
Tak Mono je a bude dál open source, je na komunitě, jak s ním naloží. MS svůj soft uvolňuje povětšinou pod MIT, kdokoli může forkovat, když se mu otevřenost MS nebude líbit. MS se mění a Vaše teorie s nezměnitelnou sviní je Vaše osobní antipatie a s budoucností .NET platformy nemá nic společného.

Založit nové vláknoNahoru


ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.