Příspěvky

331

Vývoj / Re:Traits ve Fortranu

« kdy: 11. 09. 2022, 09:55:37 »

Podle mne je OOP i ve Fortranu, pokud se používá jen v nějakých částech aplikace, akceptovatelné. Možná poslouží i na nějaký převod původně OOP designu z C++ do Fortranu.

Taky souhlas (když se používá rozumně). Ono v době přidání OOP do Fortranu zrovna letěl styl Java, bylo do dávno před (typovými systémy) Rustu, Julie či Go.

BTW co se mi z nových návrhů hodně líbí jsou šablony: https://everythingfunctional.wordpress.com/2022/07/24/the-state-of-fortran-generics/
Trochu se tváří jako ty v C++, ale s těmi omezeními (restriction) to bude super, pokud to takto projde. Kdo má furt používat m4, že?

332

Vývoj / Re:Traits ve Fortranu

« kdy: 11. 09. 2022, 08:27:52 »

moduly jsou dobrá cesta

To tady nikdo nerozporuje, a týká se to asi všech jazyků.

A ano, buďme rádi za každého fortranistu, naprostý souhlas

333

Vývoj / Re:Traits ve Fortranu

« kdy: 11. 09. 2022, 00:25:31 »

... viz co psal Ink. Moduly jsou jen jmenné prostory ...

Never nikomu, kym si to sam neoveris.

Dobrá rada, ale vzhledem k tomu, že znám Fortran i ostatní věci, o kterých Ink psal, můžu z fleku říct, že on má pravdu a ty se ukrutně pleteš.

Jo a v tom příkladu chybí právě ty “generic bindings” aka traity.

334

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 22:00:23 »

něco jako rustí std::io::Read nebo io.Reader (Go)

K tomuto jsem zapomněl dodat, že zrovna pro read/write Fortran plnohodnotné “traity” má.

335

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 21:09:47 »

a jak vies ze tie rozsirenia su pekne, ked si povedal ze vo fortrane neprogramujes

To jsem nikdy neřekl, jen že nepoužívám GNU Fortran a nepotřebuju v něm OOP, to je docela rozdíl.

336

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 21:07:51 »

Tak s tymi Quaternionmi to samozrejme vo Fortrane ide.

 

337

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 18:04:58 »

ja bych si furt myslel, ze na numericke pocitani ol'good fortran a jeste mpi na cluster.

Pro paralelní zpracování (HPC clustery) má pěkná rozšíření Fortran 2018.

338

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 17:52:58 »

fortran je na numeriku a traits a oop jsou v nem zbytecne.

Co jsem to tak jedním okem sledoval, fortranisti si prostě stěžovali: “Všechny jazyky mají OOP, proč my ne?!” Tak se ustanovil výbor a vznikla verze Fortranu s OOP. To se pak začalo používat. Konzervativní fyzici pořád píšou stylem F77 a nějaké OOP mají někde

Úplně stejně to bylo s Prologem, taky vznikla jeho OO verze jen proto, že tehdy to byl buzzword. Už si přesně nevybavuju, který manažer IBM to bez obalu takto přiznal.

339

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 17:48:40 »

veortranu bych ocekaval praci s vektory, maticemi, na co specialni typ pro kvaterniony.

To tam je, ale někdy se hodí vektor nebo matice kvaternionů (nebo nějakého jiného složitějšího typu).

340

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 15:31:21 »

Uzavrime tuto diskusiu s tym, ze na podobny ucel, na ktory sa pouzivaju v inych jazykoch traity sa vo fortrane daju pouzit moduly.

Jenže to není pravda ani trochu, viz co psal Ink. Moduly jsou jen jmenné prostory a nijak nesouvisí s OOP/dynamicitou. Ale uzavřít to můžeme

341

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 14:32:22 »

No to som trochu sklamany

To mě mrzí. Slibuji, že až bude chvilka času, nainstaluju si GNU Fortran a napíšu příklad. Ovšem vzhledem k charakteru OOP ve Fortranu ten kód bude hnusný a jako příklad spíše negativní

342

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 14:26:45 »

Moduly vo fortrane (90+) maju podobny ucel ako traity v inych jazykoch. Sluzia na organizaciu a znovupouzitie kodu.

Možná jsem něco nepochopil, ale co jsi demonstroval ve svém příkladu, jsou funkce uspořádané do nějakých namespaces. Traity slouží k implementaci nějakého rozhraní napříč různými typy (třídami). Možná tam někde nějaký průnik vidíš, ale nepřijde mi, že by tam byla nějaká zásadní podobnost nebo zastupitelnost.

Žádný průnik tam není.

Ale je tam analogia - pozri:

Kód: [Vybrat]

class Main implements my_mod {
	static void main(String[] args) {
		Main m = new Main();
		println("main calls:")
		m.t11()
		m.t12()
		m.t2()
		m.s()
	}
}

trait tmp_mod1 {
	void t11() {
		println("t11");
	}
	void t12() {
		println("t12 calls:")
		t11()
	}
}

trait tmp_mod2 {
	void t2() {
		println("t2")
	}
}

trait my_mod implements tmp_mod1, tmp_mod2 {
	void s() {
		println("s calls:")
		t11()
		t12()
		t2()
	}
}

output:

Kód: [Vybrat]

main calls:
t11
t12 calls:
t11
t2
s calls:
t11
t12 calls:
t11
t2

Úžasné!

Teď vážně, jak se tedy ve Fortranu pomocí modulů docílí toho, abych mohl mít funkci, třeba ReadAll, která bude typově bezpečná a bude umět číst data ze souboru, socketu a čehokoliv, co implementuje předem daný protokol (s chybami typové kontroly hlášenými během překladu, ne běhu)?

343

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 13:27:10 »

Tak preco neurobis syntaktickou omáčkou male demo traitu vo fortrane ?
Nech je to funkcne, da sa skompilovat v gfortrane a ma zmysluplne pouzitie ..

Protože to nepotřebuju a navíc to je triviální a úplně stejné jako třeba v Javě bez rozhraní (její úplně prvotní verze, asi ještě pre-v1.0, je ostatně neměla). Napsat něco jako rustí std::io::Read nebo io.Reader (Go) bez použití traitů/rozhraní a bez vícenásobné dědičnosti bývá oblíbená otázka u zkoušek z úvodu do “OOP”.

344

Vývoj / Re:Traits ve Fortranu

« kdy: 10. 09. 2022, 13:18:38 »

nechapu proc to cpou do fortranu, ten jsem pouzival jen na vypocty a stacily realna cisla, na co dalsi typy.

Tak uživatelské typy se hodí pro lepší reprezentaci kdejakých objektů (například kvaternionů), tím spíš že Fortran má pěkně udělané přetěžování operátorů (a definici vlastních). Méně užitečné je až to OOP à la Java (dynamický dispatch je fajn, ale jde udělat i bez dědičnosti). Navíc se zavedením pointerů Fortran “dostal” typovou nebezpečnost, člověk si musí paměť spravovat manuálně (nebo pointery nepoužívat). K jakým hrůzám to vede ukazuje výše odkazovaný prasokód.

345

Studium a uplatnění / Re:Změna práce

« kdy: 10. 09. 2022, 01:56:00 »

mozek bezneho smrtelnika by to proste nepobral ani po letech studia

Tak mozek běžného smrtelného vývojáře v Javě nebo JS nepobere ani mírně pokročilé funkcionální programování. Algebraická geometrie je úplně jiný level.

No dobře, dobře, srandičky stranou.

Když mám:
1 + 1
a + b
foo boo coo
První dva případy chápu, protože znám.
Ale u toho třetí taky chápu, že foo a coo bude levý a pravý operand, a boo operátor. I když netuším co to vlastně dělá.

Abstrakce je:
map = <buildin>
xs = [1, 2, 3]
inc = \x -> x + 1
print map xs inc

nebo
foo = <buildin>
doo = x goo too soo
jooooo = lambd x do x op 1
hoo foo doo jooooo

Ve výsledku tomu druhému taky mrkev rozumím. Ale tuším, že tam jsou všechno jenom triviální transformace, bez ohledu na abstrakci. I když ten stromeček transformací může být extrémně zamotaný. Možná to vyžaduje velké úsilí, nahrát si to do hlavy - ale bude to v něčem horší, prinicipielně horší, než ty špagety, co dokáží vytvořit někteří kolegové?

Špagety jsou fajn