Příspěvky

1336

Windows a jiné systémy / Re:gcc & Win32 mini-posix knihovna

« kdy: 18. 12. 2020, 16:21:58 »

Pokud nevyhovuje MinGW, tak snad jen WSL, verze 1 převádí linuxové syscally na Win32 API (není to tedy na úrovni libc, ale funguje to spolehlivě). POSIXový subsystém Windows mívaly, ale to už je dávno.

P.S. Nicméně funkce jako fopen, malloc, strcmp apod. jsou součástí standardní knihovny céčka a Windows je umí, občas s mírnými podivnostmi. Také je vhodné zmínit, že Microsoft teď na Windows nabízí clang (v rámci Visual Studia).

1337

Vývoj / Re:Trait a konstruktor

« kdy: 18. 12. 2020, 14:26:42 »

Obecně se domnívám, že data do traitů nepatří, ale kdyby nebylo zbytí, tak by se mi líbilo něco jako setAssociatedObject v Objective-C, to je hezky transparentní, kód zůstane čistý a všichni jsou spokojení. Jen teda asi nemáme žádný jazyk s traity a runtimem, který by to umožňoval. Třeba jednou vznikne nějaký Objective-Rust

1338

Studium a uplatnění / Re:oddych od IT / zvládanie stresu

« kdy: 10. 12. 2020, 00:07:52 »

Jo, po patnácti letech jsem odjel do And a tam žil nějakou dobu na náhorní plošině pod šestitisícovkami. Tesco tam sice nebylo, ale jinak super.

1339

Windows a jiné systémy / Re:Podpora iOS aplikací na intel Macboocích

« kdy: 08. 12. 2020, 19:34:14 »

Ne, to nejde (a velmi pravděpodobně nepůjde). Technicky by to šlo u aplikací, u kterých vývojář nahrál bitcode, Apple je automaticky překládá na svých serverech pro nové procesory, ale to je jen teoretická možnost, která nedává smysl obchodně.

Jediná schůdná cesta je, že vývojáři své aplikace přeloží pro macOS v rámci Catalystu, to jde bez změny kódu a výsledek běží na macOS bez ohledu na procesor. Výhoda je, že taková aplikace se dá přizpůsobit větší obrazovce, ovládání (dotykový displej vs. klávesnici) apod., ale co to tak očkem sleduju, Catalyst si zatím moc obliby nezískal.

Ono i na Apple Silicon zas tak moc iOS aplikací nejede, vývojáři to totiž musí povolit, je to sice jen jeden checkbox, ale přinejmenším velcí hráči jako Google, Amazon apod. se k tomu zatím nerozhoupali.

1340

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 15. 11. 2020, 00:10:09 »

Sice je to trochu jiná kategorie, ale podle mě má velký potenciál Kotlin.
Při vydání .NET Core jsem dával velkou naději C#, ale dodnes nesplnil moje očekávání, hlavně kvůli oficiální podpoře multiplatformního GUI.

To ano, kotlin je vážně skvělý. Také si pohrávám se Scalou, doporučil bych se na ni také podívat, sdílí některé vlastnosti s rustem. Ale Kotlin a Scala jsou také úplně jiné kategorie.

Scala je fajn. Takové lepší F#.

1341

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 07. 11. 2020, 21:44:36 »

Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Java nahradila COBOL

doslova

1342

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 06. 11. 2020, 03:23:52 »

Ano. Jako s Go. To není ani revoluce, ani evoluce, je to vlastně jen Céčko, kde je nějaká základní "objektová" podpora, mnohem větší standardní kníhovna, GC a CSP. Ale spousta věcí z 15-ti let vývoje programování byla prostě zahozena.

Python byl revoluce. Go pak přenesl tu prošlapanou cestičku do kompilovaného světa (plus pár skvělejch nápadů, abych mu nekřivdil).

V čem byl Python revoluce? Beru třeba Lisp nebo Smalltalk, ale proč Python?

Python přinesl úplně jiný způsob myšlení - Python Zen. Možnost napsat jasně myšlenku, neřešit implementační detaily (práce s pamětí, práce s chybami), možnost nebát se, že ta aplikace spadne. Osvobození se od starého chápání typů jak bylo v C. Osvobození od nutnosti psát romány jak je v Javě. A hlavně to přinesl pro obyčejný lid, a prosadil to.

Smalltalk? Lisp? Jo, jasně, všichni jsme to znali. Ale tyto revoluce zůstali jen v hlavách autorů. Python se prosadil.

Z dnešního pohledu je Python nudný, nezajímavý a nic neumějící. Ale tehdá neměl konkurenci. Bylo to zjevení.

Hmm, asi jsem jiná generace, za mého mládí byl pro “obyčejný lid” Basic.

1343

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 05. 11. 2020, 19:36:51 »

Ano. Jako s Go. To není ani revoluce, ani evoluce, je to vlastně jen Céčko, kde je nějaká základní "objektová" podpora, mnohem větší standardní kníhovna, GC a CSP. Ale spousta věcí z 15-ti let vývoje programování byla prostě zahozena.

Python byl revoluce. Go pak přenesl tu prošlapanou cestičku do kompilovaného světa (plus pár skvělejch nápadů, abych mu nekřivdil).

V čem byl Python revoluce? Beru třeba Lisp nebo Smalltalk, ale proč Python?

1344

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 04. 11. 2020, 22:08:40 »

Mám pocit, že stále čekám na ten přelomovej jazyk, který bude opravdu špička, a bude opět revoluce - stejně jako bylo ve své době Java, a později Python. Přijde mi, že to stálo přešlapuje na místě - občas se objeví něco nadějného (Scala, Rust, Elm), ale pak mám pocit, že se do toho bojí pořádně fláknout, protože vývojáři konzervy by to odmítly... (Go, Kotlin)

To je otázka, co přelomového se dá ještě přinést. Zatím to na žádnou revoluci nevypadá.

1345

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 04. 11. 2020, 13:09:34 »

hrozne tristi sily a pokroku to spis skodi nez prospiva

A v čem by sis teda představoval ten pokrok? Aby to dle tvého nebylo plejtvání?

To jsou strašné žvásty. Touto logikou je plýtvání každý základní výzkum. Naopak toto “plýtvání” je z dlouhodobého hlediska největším přínosem pro celý obor obecně, o jednotlivé jazyky prakticky nejde. Dělící čára běží mezi zvídavými, bystrými jedinci a konzervativní, tupou masou.

Když už jsme u té zvídavosti, jak ses popral s tou intuicionistickou logikou? Dalo ti to něco?

1346

Vývoj / Re:Kotlin nebo Scala pro backend?

« kdy: 04. 11. 2020, 13:04:20 »

Jenže tam chybí nějaký cíl, něco, co by to zastřešilo, dalo to jazyku nějaký smysl. U Javy, Scaly, Go, C++, Rustu, C, JavaScriptu, TypeScriptu, Pythonu, Perlu nebo PHP dokážu ten jazyk charakterizovat jednou větou. V případě Kotlinu to nedokážu – resp. jedna věta by byla o tom, jak Kotlin vznikl, ne k čemu je určen.

Kotlin je určen ke všemu, k čemu je určena java. Má mít kompaktnější syntax (properties, data classes, switch expressions, lambdy, type inference, template strings....  něco z toho se později dostává do javy..). Má být bezpečnější pro "průmyslové použití" tj návrhem preventivně bránit částým chybám (null safe calls, == vs ref. equality..). "Průmyslové použití" pro mne znamená  velký projekt, kde kód píše hodně lidí s různými úrovněmi znalosti.  Zároveň, do třetice, ten jazyk má být jednoduchý na naučení (ne o moc složitější než java) a kód v něm má být dobře udržovatelný (jako v javě). Takže se právě naopak chce vyhnout zbrklému přidávání features stylem "kočička pejsek".

A řekl bych, že úspěšně.

Tak určitě je lepší než Java. To je ale hodně nízká laťka.

1347

Studium a uplatnění / Re:Jak efektivně studovat programování?

« kdy: 04. 11. 2020, 12:57:46 »

Kód: [Vybrat]

fn div (a: Int, b: Int) -> Result Int String
	if b == 0 then
		Fail ("Dělení nulou")
	end
	Succes (a / b)

match a <- div(42, a):
	Fail msg -> print(msg)
	_ -> print(a)

Kód: [Vybrat]

fn div (a: Int, b: Int) -> throw Int
	if b == 0 then
		throw Error ("Dělení nulou")
	end
	a / b

try:
	print(div(42, a))
catch e:
	print(e)

To je skutečný jazyk nebo nějaký funkcionální pseudokód?

Pseudokód. Mix Swiftu, Rustu a TypeScriptu.

Hezký mix, to by si zasloužilo parser a přinejmenším transpiler

1348

Studium a uplatnění / Re:Jak efektivně studovat programování?

« kdy: 03. 11. 2020, 14:11:12 »

ty monády jsou v Haskellu největší pruda, protože jdou vidět moc.

Protože monáda je skoro všechno užitečné, optional, seznam, množina, futures
Nicméně otázka výjimek a transakčnosti s tím nijak nesouvisí. Ve FP jde něco jako noexcept udělat jednoduše.

1349

Studium a uplatnění / Re:Jak efektivně studovat programování?

« kdy: 02. 11. 2020, 10:53:54 »

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)

No podle mě zas tak ne. Třeba v Haskellu je kód s efekty oddělený od kódu bez efektů. Takže by, teoreticky, napřed došlo k výpočtu finálního stavu a pokud by výpočet prošel, došlo by k jeho zápisu. Že by ten zápis byl chráněn transakcí, je jasné, ale to už by si ta low level část systému musela pohlídat sama...

To “zahodit” znamená, že výpočet se v monádě dostane na vedlejší kolej. Ten kód oddělený není, jen pracuje v rámci složitějšího typového systému. BoneFlute má pravdu, že to je v podstatě zdarma.

Však já polemizuju pouze s tím "Tady trochu provokuju". "kód oddělený není, jen pracuje v rámci složitějšího typového systému" - není to slovíčkaření? Prostě se ví, která funkce má efekty a která ne a dokud se výpočet dělá v bezefektové funkci, víme, že výsledek se může zahodit.

Možná jsem jen úplně nepochopil komentář o tom rozdělení.

Nicméně zajímavější jsou ty “efekty,” to s tím zahazováním je tedy rollback? A co je pak commit? Jakému typovému operátoru odpovídá? Podle mě je tohle všechno ve FP plně transparentní, ale možná mi něco uniká.

1350

Studium a uplatnění / Re:Jak efektivně studovat programování?

« kdy: 02. 11. 2020, 09:12:38 »

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)

No podle mě zas tak ne. Třeba v Haskellu je kód s efekty oddělený od kódu bez efektů. Takže by, teoreticky, napřed došlo k výpočtu finálního stavu a pokud by výpočet prošel, došlo by k jeho zápisu. Že by ten zápis byl chráněn transakcí, je jasné, ale to už by si ta low level část systému musela pohlídat sama...

To “zahodit” znamená, že výpočet se v monádě dostane na vedlejší kolej. Ten kód oddělený není, jen pracuje v rámci složitějšího typového systému. BoneFlute má pravdu, že to je v podstatě zdarma.