Fórum Root.cz

Práce => Studium a uplatnění => Téma založeno: PetersonPierson 29. 05. 2018, 18:58:50

Název: Výběr vhodného OOP jazyka
Přispěvatel: PetersonPierson 29. 05. 2018, 18:58:50
Ahoj,

mám dilema. Mám zkušenosti s programováním v C++, rád bych se začal soustředit na jeden z těchto jazyků.
C#(.NET) vs Java

Vím, že jsou si velmi podobné, ale jde mi o:
1) Který jazyk je jednodušší zvládnout, aby člověk mohl být zaměstnán jakožto junior a rychleji?
2) Pokud bych chtěl dělat enterprise aplikace - je vhodnější java (EE) nebo .net?
3) S kterým jazykem lze jednodušeji se dostat do IT světa?

Díky moc! :)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 29. 05. 2018, 19:10:57
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: uuuuuuuu 29. 05. 2018, 19:11:21
C++
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: jdusizasvym 29. 05. 2018, 19:22:22
1. Python
2. C s mřížkou
3. Java
...
...
end. C++
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Youda 29. 05. 2018, 19:39:50
C#
Jawa
Jawa
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: anonym 29. 05. 2018, 19:55:18
C#
Jawa
Jawa

Nesouhlasím, se C# bude něco rychleji produkovat, ale na on se neptá, chce vědět, kde ho zaměstnají dřív a snáz. Takže taky Java.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Karel 30. 05. 2018, 15:48:35
1) Který jazyk je jednodušší zvládnout, aby člověk mohl být zaměstnán jakožto junior a rychleji?
2) Pokud bych chtěl dělat enterprise aplikace - je vhodnější java (EE) nebo .net?
3) S kterým jazykem lze jednodušeji se dostat do IT světa?

1) Na naučení se je jednodušší C#. Java má více chytáků a některé věci tam nejsou zrovna intuitivní. C++ není ani zdaleka tak snadné, jako tyhle dva.

2) To strašně záleží na tom, jaké další technologie chcete používat a jakým způsobem je chcete nasadit. Kupříkladu pokud chcete použít MS SQL, tak rozhodně C#. Ale pokud Oracle a chcete v něm mít i část aplikační logiky, tak si s C# natlučete hubu, protože v základu neumí ani takové věci, jako zavolat uloženou proceduru, u které má jeden z parametrů uživatelsky definovaný typ. Podobné zádrhele jsou prakticky se vším a na obou stranách, takže volba opravdu musí záviset na tom, co dalšího používáte.

3) Snadněji se práce hledá s Javou. C# u nás až tak moc nefrčí a nabídek je podstatně méně. Pokud se orientujete podle platu, tak pak je průměr ve prospěch Javy, maximum je ale u obou vyrovnané. Pokud tedy aspirujete na to být špička, pak je to jedno. Pokud si troufáte jen na lepší průměr, pak zvolte Javu.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Youda 30. 05. 2018, 17:22:44
1) Který jazyk je jednodušší zvládnout, aby člověk mohl být zaměstnán jakožto junior a rychleji?
2) Pokud bych chtěl dělat enterprise aplikace - je vhodnější java (EE) nebo .net?
3) S kterým jazykem lze jednodušeji se dostat do IT světa?

1) Na naučení se je jednodušší C#. Java má více chytáků a některé věci tam nejsou zrovna intuitivní. C++ není ani zdaleka tak snadné, jako tyhle dva.

2) To strašně záleží na tom, jaké další technologie chcete používat a jakým způsobem je chcete nasadit. Kupříkladu pokud chcete použít MS SQL, tak rozhodně C#. Ale pokud Oracle a chcete v něm mít i část aplikační logiky, tak si s C# natlučete hubu, protože v základu neumí ani takové věci, jako zavolat uloženou proceduru, u které má jeden z parametrů uživatelsky definovaný typ. Podobné zádrhele jsou prakticky se vším a na obou stranách, takže volba opravdu musí záviset na tom, co dalšího používáte.

3) Snadněji se práce hledá s Javou. C# u nás až tak moc nefrčí a nabídek je podstatně méně. Pokud se orientujete podle platu, tak pak je průměr ve prospěch Javy, maximum je ale u obou vyrovnané. Pokud tedy aspirujete na to být špička, pak je to jedno. Pokud si troufáte jen na lepší průměr, pak zvolte Javu.

Ohledne porovnani C# vs Jawa je tu este jeden velice dulezity aspekt.
C# je wokenice only (.Net Core je zatim novinka), zacim co Jawa je multiplatform.
A to je v ceskem enterprise pro C# prakticky showstopper.
Cesky enterprise default pro aplikacni servery je Linux na hypervisoru v DevOps prostredi (Puppet/Ansible/Satellite6), cpat nekam wokenice, starat se o to, platit licence a byt jednou nohou v kriminale, ze jsem na dany wokenni VM pridal CPUcore a je tam licence o onen jeden CPucore min - na to se muze kazdy IT manager a Admin defekovat.
Wokenice a C# ma uz misto jenom v niche prostredi, kde jsou wokenice nutne, pro legacy aplikace.


Stejne tak mizi nasazeni MSSQL a Oracle, jsou vytlacovany Postgresem (ktery sel vykonove velice nahoru) a NoSQL databazemi jako je InfluxDB, Apache Cassandra, Elasticsearch. MSSQL mizi opet z duvodu wokenice only, Oracle mizi z duvodu jejich silenstvi v oblasti cen licenci. V enterprise nyni casto vidim od MGMT jasne zadani vyfakovat Oracle okdud jenom mozno.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: borekz 30. 05. 2018, 19:27:43
Javu dnes umí všichni, takže platově to brzo bude jako PHP. Raději se k C++ nauč Qt, Boost a OpenGL.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Milfaus 30. 05. 2018, 19:55:55
Javu dnes umí všichni, takže platově to brzo bude jako PHP. Raději se k C++ nauč Qt, Boost a OpenGL.

 :o

Takovou blbost jsem už dlouho neslyšel, napiš to ještě jednou  ;D
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: GoGoGo 30. 05. 2018, 21:40:40
https://golang.org/ (https://golang.org/)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Vizionar 30. 05. 2018, 22:11:32
1) Který jazyk je jednodušší zvládnout, aby člověk mohl být zaměstnán jakožto junior a rychleji?
JavaScript

2) Pokud bych chtěl dělat enterprise aplikace - je vhodnější java (EE) nebo .net?
JavaScript

3) S kterým jazykem lze jednodušeji se dostat do IT světa?
JavaScript
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 30. 05. 2018, 22:21:19
1) Který jazyk je jednodušší zvládnout, aby člověk mohl být zaměstnán jakožto junior a rychleji?
JavaScript

2) Pokud bych chtěl dělat enterprise aplikace - je vhodnější java (EE) nebo .net?
JavaScript

3) S kterým jazykem lze jednodušeji se dostat do IT světa?
JavaScript

Opravdu nerad bych tu začínal flame, ale JavaScript není úplně nejjednodušší opravdu zvládnout. :) Ale jinak je to pěkný jazyk.

Ad 1) bych možná zvážil Python, ač ho dvakrát nemusím.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: balki 31. 05. 2018, 05:25:20
Haskell
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: uuuuuuuu 31. 05. 2018, 06:11:37
Haskell

Haskell dobry, ale neni OOP :-)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: RomčoBomčo 31. 05. 2018, 08:47:26
I made up the term object-oriented, and I can tell you I did not have C++ in mind. :)

Mne v poslednom čase vyhovuje SmallTalk Pharo (http://pharo.org) no nepohrdnem ani starým dobrým CLOS.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: balki 31. 05. 2018, 09:03:57
Haskell

Haskell dobry, ale neni OOP :-)

Neviem, naco lpiet na objektovo-orientovanej paradigme, ked sa da dosiahnut vyssej urovne poznania.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 31. 05. 2018, 09:25:25
Chce to na práci, ne na přemigrování myšlení na vyšší plateau. Mimoto objektový a funkcionální výpočetní model mají jiné použití.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: haskell guru 31. 05. 2018, 09:29:03
Neviem, naco lpiet na objektovo-orientovanej paradigme, ked sa da dosiahnut vyssej urovne poznania.

Dojít ke konečnému poznání dokonalosti funkce je ale tvrdá a dlouhá cesta...
(https://pbs.twimg.com/media/ClW4GpUVYAAzxOx.jpg)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kofeinista 31. 05. 2018, 12:29:06
1) Který jazyk je jednodušší zvládnout, aby člověk mohl být zaměstnán jakožto junior a rychleji?
2) Pokud bych chtěl dělat enterprise aplikace - je vhodnější java (EE) nebo .net?
3) S kterým jazykem lze jednodušeji se dostat do IT světa?

1) Na naučení se je jednodušší C#. Java má více chytáků a některé věci tam nejsou zrovna intuitivní. C++ není ani zdaleka tak snadné, jako tyhle dva.

2) To strašně záleží na tom, jaké další technologie chcete používat a jakým způsobem je chcete nasadit. Kupříkladu pokud chcete použít MS SQL, tak rozhodně C#. Ale pokud Oracle a chcete v něm mít i část aplikační logiky, tak si s C# natlučete hubu, protože v základu neumí ani takové věci, jako zavolat uloženou proceduru, u které má jeden z parametrů uživatelsky definovaný typ. Podobné zádrhele jsou prakticky se vším a na obou stranách, takže volba opravdu musí záviset na tom, co dalšího používáte.

3) Snadněji se práce hledá s Javou. C# u nás až tak moc nefrčí a nabídek je podstatně méně. Pokud se orientujete podle platu, tak pak je průměr ve prospěch Javy, maximum je ale u obou vyrovnané. Pokud tedy aspirujete na to být špička, pak je to jedno. Pokud si troufáte jen na lepší průměr, pak zvolte Javu.

Ohledne porovnani C# vs Jawa je tu este jeden velice dulezity aspekt.
C# je wokenice only (.Net Core je zatim novinka), zacim co Jawa je multiplatform.
A to je v ceskem enterprise pro C# prakticky showstopper.
Cesky enterprise default pro aplikacni servery je Linux na hypervisoru v DevOps prostredi (Puppet/Ansible/Satellite6), cpat nekam wokenice, starat se o to, platit licence a byt jednou nohou v kriminale, ze jsem na dany wokenni VM pridal CPUcore a je tam licence o onen jeden CPucore min - na to se muze kazdy IT manager a Admin defekovat.
Wokenice a C# ma uz misto jenom v niche prostredi, kde jsou wokenice nutne, pro legacy aplikace.


Stejne tak mizi nasazeni MSSQL a Oracle, jsou vytlacovany Postgresem (ktery sel vykonove velice nahoru) a NoSQL databazemi jako je InfluxDB, Apache Cassandra, Elasticsearch. MSSQL mizi opet z duvodu wokenice only, Oracle mizi z duvodu jejich silenstvi v oblasti cen licenci. V enterprise nyni casto vidim od MGMT jasne zadani vyfakovat Oracle okdud jenom mozno.

+1
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: I/O 31. 05. 2018, 12:30:27
Neviem, naco lpiet na objektovo-orientovanej paradigme, ked sa da dosiahnut vyssej urovne poznania.

Dojít ke konečnému poznání dokonalosti funkce je ale tvrdá a dlouhá cesta...
(https://pbs.twimg.com/media/ClW4GpUVYAAzxOx.jpg)
Podobnou křivku jsem absolvoval i u prachsprostého LISPu s makry a u FORTHu s kompilujícími a stavově citlivými slovy. Nejdřív člověk nechápe, pak to pochopí, pak to začne sázet všude, kde je to jen trochu možné, pak zjišťuje, že je to dvojsečná zbraň, a nakonec se snaží vymýšlet elegantní řešení tak, aby to pokud možno nebylo nutné příliš používat.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kofeinista 31. 05. 2018, 12:39:02
1) Java (standardní zralá technologie, bude tu s námi ještě dlouho)
2) Rust (budoucnost, místy už současnost)
3) C++ (hlavně kvůli Qt a stávajícím aplikacím)

Ostatní jsou více či méně obskurní/akademické pokusy nebo legacy/proprietární sračky bez budoucnosti. Ty obskurnosti můžou byt fajn na hraní si na vlastních projektech, ale že bys někde našel tým lidi, kteří s tebou budou spolupracovat a někdo vám za to bude platit, to je poměrně nízká pravděpodobnost. Takže jestli to chceš na práci, tak Javu a výhledově ten Rust. C++ se taky neztratí a moderní C++ není špatné, ale nových projektů v C++ bude vznikat méně.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: anonym 31. 05. 2018, 12:48:50
1) Java (standardní zralá technologie, bude tu s námi ještě dlouho)
2) Rust (budoucnost, místy už současnost)
3) C++ (hlavně kvůli Qt a stávajícím aplikacím)

Ostatní jsou více či méně obskurní/akademické pokusy nebo legacy/proprietární sračky bez budoucnosti. Ty obskurnosti můžou byt fajn na hraní si na vlastních projektech, ale že bys někde našel tým lidi, kteří s tebou budou spolupracovat a někdo vám za to bude platit, to je poměrně nízká pravděpodobnost. Takže jestli to chceš na práci, tak Javu a výhledově ten Rust. C++ se taky neztratí a moderní C++ není špatné, ale nových projektů v C++ bude vznikat méně.

Konečně rozumný člověk na tomto foru!
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: I/O 31. 05. 2018, 12:52:29
1) Java (standardní zralá technologie, bude tu s námi ještě dlouho)
2) Rust (budoucnost, místy už současnost)
3) C++ (hlavně kvůli Qt a stávajícím aplikacím)

Ostatní jsou více či méně obskurní/akademické pokusy nebo legacy/proprietární sračky bez budoucnosti. Ty obskurnosti můžou byt fajn na hraní si na vlastních projektech, ale že bys někde našel tým lidi, kteří s tebou budou spolupracovat a někdo vám za to bude platit, to je poměrně nízká pravděpodobnost. Takže jestli to chceš na práci, tak Javu a výhledově ten Rust. C++ se taky neztratí a moderní C++ není špatné, ale nových projektů v C++ bude vznikat méně.
ad 2 - IMHO také patří do té kategorie sračky bez budoucnosti. Současným hype bych se nenechal zmást, tím si prošel ve své době i třebas takový PL/1 a kde je mu dnes konec.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Emanuel 31. 05. 2018, 13:28:24
1) Java (standardní zralá technologie, bude tu s námi ještě dlouho)
2) Rust (budoucnost, místy už současnost)
3) C++ (hlavně kvůli Qt a stávajícím aplikacím)

Ostatní jsou více či méně obskurní/akademické pokusy nebo legacy/proprietární sračky bez budoucnosti. Ty obskurnosti můžou byt fajn na hraní si na vlastních projektech, ale že bys někde našel tým lidi, kteří s tebou budou spolupracovat a někdo vám za to bude platit, to je poměrně nízká pravděpodobnost. Takže jestli to chceš na práci, tak Javu a výhledově ten Rust. C++ se taky neztratí a moderní C++ není špatné, ale nových projektů v C++ bude vznikat méně.

Python nelze rovněž opomenout.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 31. 05. 2018, 13:50:54
ad 2 - IMHO také patří do té kategorie sračky bez budoucnosti. Současným hype bych se nenechal zmást, tím si prošel ve své době i třebas takový PL/1 a kde je mu dnes konec.

Nezapomen dodat, ze budoucnost patri jazyku Ada, ktery umi vsechno co Rust (a lip) a ze opravdovi programatori nepouzivaji Pascal.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: PL 31. 05. 2018, 17:48:39
Citace
Opravdu nerad bych tu začínal flame, ale JavaScript není úplně nejjednodušší opravdu zvládnout.

Přesně tak. Spousta lidí ho na začátku chápe jako takovou lite verzi Javy a když ho tak začnou používat, tak spláčou nad výdělkem. Kromě toho se v JS všechno dá udělat na deset způsobů, přičemž je dobré znát jich všech deset, protože i když je nepoužíváte, tak v cizích kódech na ně prostě narazíte. Dál je potřeba počítat s tím, že je nutné znát minimálně dva dialekty(ES5/ES6), lépe ale tři(TypeScript), pokud chcete mít co nejširší záběr. No a pak už zbývá jenom naučit se asi sto knihoven, buildovacích nástrojů, design patternů a běhových prostředí a můžete prohlásit, že jste zvládli JavaScript.

Takže i když mám JavaScript opravdu rád, tak jako první OOP jazyk bych ho nedoporučil. Do začátku radši nějakou menší divočinu pro získání dobrých návyků, které JS nijak nevynucuje.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: uuuuuuuu 31. 05. 2018, 18:11:30
Javascript je infekcni mem, ktery se siri po slabsich jedincich.
S webassembly doufam v navrat k C/C++
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 31. 05. 2018, 18:20:14
Citace
Opravdu nerad bych tu začínal flame, ale JavaScript není úplně nejjednodušší opravdu zvládnout.
(...)  Dál je potřeba počítat s tím, že je nutné znát minimálně dva dialekty(ES5/ES6), lépe ale tři(TypeScript), pokud chcete mít co nejširší záběr. No a pak už zbývá jenom naučit se asi sto knihoven, buildovacích nástrojů, design patternů a běhových prostředí a můžete prohlásit, že jste zvládli JavaScript.(...)

Ty nástroje a tak bych do něj dvakrát nezahrnoval. Jednak se pořád mění (to mě na komunitě dost štve) a ES6 už dnes povětšinou stačí (zvlášť mi nepřijde jiný, oproti ES5, ale obsáhlejší), TypeScript nemusím. Přinejhorším se dá použít nějaký transpilátor na ES5, ale pokud někdo nepotřebuje podporovat Internet Explorer z přelomu století, tak je to imo ok. :)

Javascript je infekcni mem, ktery se siri po slabsich jedincich.
S webassembly doufam v navrat k C/C++

V C mám naprogramováno víc než v JS (v C++ asi taky), ale nerozumím, proč bych ho měl chtít na web. Na hřebík použiju kladivo, na šroubek šroubovák.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 31. 05. 2018, 18:35:31
Téměř každý z životaschopných jazyků je v základu jednoduchý, ale když se k němu přidá ekosystém v knihovách a frameworcích, tak je z toho monstrum. Postupně bobtná do doby, než ho vývojáři opustí, protože je příliš složitý a nepřehledný. Tím uvolní prostor pro další jednoduchý jazyk a cyklus je uzavřen.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: uuuuuuuu 31. 05. 2018, 18:38:17
Citace
Opravdu nerad bych tu začínal flame, ale JavaScript není úplně nejjednodušší opravdu zvládnout.
(...)  Dál je potřeba počítat s tím, že je nutné znát minimálně dva dialekty(ES5/ES6), lépe ale tři(TypeScript), pokud chcete mít co nejširší záběr. No a pak už zbývá jenom naučit se asi sto knihoven, buildovacích nástrojů, design patternů a běhových prostředí a můžete prohlásit, že jste zvládli JavaScript.(...)

Ty nástroje a tak bych do něj dvakrát nezahrnoval. Jednak se pořád mění (to mě na komunitě dost štve) a ES6 už dnes povětšinou stačí (zvlášť mi nepřijde jiný, oproti ES5, ale obsáhlejší), TypeScript nemusím. Přinejhorším se dá použít nějaký transpilátor na ES5, ale pokud někdo nepotřebuje podporovat Internet Explorer z přelomu století, tak je to imo ok. :)

Javascript je infekcni mem, ktery se siri po slabsich jedincich.
S webassembly doufam v navrat k C/C++

V C mám naprogramováno víc než v JS (v C++ asi taky), ale nerozumím, proč bych ho měl chtít na web. Na hřebík použiju kladivo, na šroubek šroubovák.

K tomu kladivu a sroubovaku.....to je jen vase zkostnazelost si myslet, ze C nepatri na web a patri tam JS.  SMRT JS!!!
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Ondra Satai Nekola 31. 05. 2018, 18:48:30
Citace
Opravdu nerad bych tu začínal flame, ale JavaScript není úplně nejjednodušší opravdu zvládnout.
(...)  Dál je potřeba počítat s tím, že je nutné znát minimálně dva dialekty(ES5/ES6), lépe ale tři(TypeScript), pokud chcete mít co nejširší záběr. No a pak už zbývá jenom naučit se asi sto knihoven, buildovacích nástrojů, design patternů a běhových prostředí a můžete prohlásit, že jste zvládli JavaScript.(...)

Ty nástroje a tak bych do něj dvakrát nezahrnoval. Jednak se pořád mění (to mě na komunitě dost štve) a ES6 už dnes povětšinou stačí (zvlášť mi nepřijde jiný, oproti ES5, ale obsáhlejší), TypeScript nemusím. Přinejhorším se dá použít nějaký transpilátor na ES5, ale pokud někdo nepotřebuje podporovat Internet Explorer z přelomu století, tak je to imo ok. :)

Javascript je infekcni mem, ktery se siri po slabsich jedincich.
S webassembly doufam v navrat k C/C++

V C mám naprogramováno víc než v JS (v C++ asi taky), ale nerozumím, proč bych ho měl chtít na web. Na hřebík použiju kladivo, na šroubek šroubovák.

K tomu kladivu a sroubovaku.....to je jen vase zkostnazelost si myslet, ze C nepatri na web a patri tam JS.  SMRT JS!!!
C nepatří skoro nikam, pokud člověk nemusí stavět na legacy kódu.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 31. 05. 2018, 19:03:17
Téměř každý z životaschopných jazyků je v základu jednoduchý, ale když se k němu přidá ekosystém v knihovách a frameworcích, tak je z toho monstrum. Postupně bobtná do doby, než ho vývojáři opustí, protože je příliš složitý a nepřehledný. Tím uvolní prostor pro další jednoduchý jazyk a cyklus je uzavřen.

A nebo se to uklidní, až jazyk "uzraje" (vývoj se zpomalí) a bude líp. Příkladem by mohl být třeba Perl. :)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 31. 05. 2018, 19:12:12
Téměř každý z životaschopných jazyků je v základu jednoduchý, ale když se k němu přidá ekosystém v knihovách a frameworcích, tak je z toho monstrum. Postupně bobtná do doby, než ho vývojáři opustí, protože je příliš složitý a nepřehledný. Tím uvolní prostor pro další jednoduchý jazyk a cyklus je uzavřen.

A nebo se to uklidní, až jazyk "uzraje" (vývoj se zpomalí) a bude líp. Příkladem by mohl být třeba Perl. :)

Zrovna u Perlu je vidět jak ho z výšeuvedených důvodů vytlačuje Python. Když se začtu do některých perlových skriptů v systému, tak se ani nedivím.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 31. 05. 2018, 19:14:35
Tak o důvodech bychom mohli diskutovat, ale pořád to nic nemění na tom, co jsem psal.

Jak jsou psané některé skripty je také na jinou diskusi. :)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Youda 31. 05. 2018, 19:14:52
Téměř každý z životaschopných jazyků je v základu jednoduchý, ale když se k němu přidá ekosystém v knihovách a frameworcích, tak je z toho monstrum. Postupně bobtná do doby, než ho vývojáři opustí, protože je příliš složitý a nepřehledný. Tím uvolní prostor pro další jednoduchý jazyk a cyklus je uzavřen.

A nebo se to uklidní, až jazyk "uzraje" (vývoj se zpomalí) a bude líp. Příkladem by mohl být třeba Perl. :)

Perl je uz dokonce krapet prezraly.
Asi jako zapomenuty balicek tvaruzku v kufru auta objeveny po tydnu.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: xyz 31. 05. 2018, 19:35:08
Jednoznačně Java, .NET tě svazuje s proprietární platformou - až zavřou Microsoft budeš bez práce.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: o 31. 05. 2018, 19:44:07
Oba jazyky, ktere zminujes jsou na ustupu (to neni muj dojem, jen odkazuji na statistiky stackoverflow a githubu) ale samozrejme za leta je v nich napsana spousta veci, ktere budou jeste dlouhou dobu potrebovat udrzbu.

Pokud jsi mlady a zacinas, zkus zvazit i modernejsi moznosti - GOlang, JS (alias typescript), atd. atp.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: anonym 31. 05. 2018, 19:44:56
Jednoznačně Java, .NET tě svazuje s proprietární platformou - až zavřou Microsoft budeš bez práce.

Ty vole to je logika ve stylu odstěhuju se do vysokých tater, abych si v případě celosvětové potopy zachránil život.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: I/O 31. 05. 2018, 20:21:27
C nepatří skoro nikam, pokud člověk nemusí stavět na legacy kódu.
V čem tedy nejlépe dělat low-level a embedded věci?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: anonym 31. 05. 2018, 21:05:51
C nepatří skoro nikam, pokud člověk nemusí stavět na legacy kódu.
V čem tedy nejlépe dělat low-level a embedded věci?

Tak to ti řeknu naprosto přesně, V Číně  :D :D :D
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Ondrej Nemecek 31. 05. 2018, 22:04:15
Doporučuju sledovat vývoj jazyků postavených na jvm (Clojure, Groovy, Kotlin, Scala).
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Emanuel 01. 06. 2018, 06:13:38
Doporučuju sledovat vývoj jazyků postavených na jvm (Clojure, Groovy, Kotlin, Scala).
To už se radši soustředit na LLVM.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Akiz 01. 06. 2018, 08:35:24
Objektivně? Asi Java, jsou v tom peníze, má to knuhovny a JVM je super.
Subjektivně? Kdybych se chtěl naučit OOP a bavit se u toho, tak SmallTalk (Pharo).
Kdybych si chtěl vyvíjet rychlý aplikace a "psát obyčejnej kód" tak základy Ruby a pak Crystal. Možná Rust.
A kdybych se chtěl OOP naučit jen tak náhodou, protože to vlastně není zas tak hrozně důležitý, tak Python.
A teprve potom bych si troufl na JS, s tím, že bych se cestou naučil ještě Scheme.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 01. 06. 2018, 09:03:37
A kdybych se chtěl OOP naučit jen tak náhodou, protože to vlastně není zas tak hrozně důležitý, tak Python.

 :D :D :D :D
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Karel 01. 06. 2018, 12:16:16
...
Podobnou křivku jsem absolvoval i u prachsprostého LISPu s makry a u FORTHu s kompilujícími a stavově citlivými slovy. Nejdřív člověk nechápe, pak to pochopí, pak to začne sázet všude, kde je to jen trochu možné, pak zjišťuje, že je to dvojsečná zbraň, a nakonec se snaží vymýšlet elegantní řešení tak, aby to pokud možno nebylo nutné příliš používat.

To platí univerzálně, nejen ve světě IT. Kolega z USA, původní profesí armádní pilot, to popisoval takhle:

Dobrý pilot zná plno triků, jak udržet letadlo pod kontrolou.
Špičkový pilot je zná taky, ale snaží se lítat tak, aby je nepotřeboval.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Phi 01. 06. 2018, 12:48:56
Doporučuju sledovat vývoj jazyků postavených na jvm (Clojure, Groovy, Kotlin, Scala).
Groovy je tu co já pamatuji a pořád je obskurita, která občas vypadne ze skříně. To bych spíš věřil na Kotlin (nebo nějakou konvergenci Javy ke Kotlinu) a na Scalu.
Co ten Rust, proč zrovna ten by měl být budoucnost? Jen se ptám.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 01. 06. 2018, 13:14:04
Co ten Rust, proč zrovna ten by měl být budoucnost? Jen se ptám.

0. Asi to nikdy nebude jazyk pro všechny a pro všechno. A jeho autoři ho berou jako cestu dopředu, ne ultimátní řešení na věčné časy.

1. Tlačí se na místo C a C++, kompiluje blízko železu, má "beznákladové abstrakce". Spousta lidí tohle chce nebo potřebuje a spousta holt ne.

2. Má propracovaný typový systém, který pomáhá snižovat chybovost.

3. Má dobrou komunitu nadšených a chytrých lidí.

4. Má dost dobrý ekosystém (cargo atd.).

5. Má za sebou poměrně velkou firmu, která ho používá v reálném produktu.

6. Hodně se pracuje na tom, aby se snížila vstupní bariéra pro začátečníky, byť je to jazyk v lecčems složitější než spousta jiných.

7. Má makra, která jsou k něčemu. Viz třeba println!, které v době kompilace řeší, kolik a jakých parametrů člověk tiskne, namísto toho, aby ho to vyškolilo při běhu.

8. Vývoj jazyka jde opravdu rychle dopředu. Ale spousta věcí, než jde do stabilní verze, čeká "na dopečení" v nightly.

9. Používá dost vlastností funkcionálních jazyků (pattern matching, obsluha chyb), ale bez extrémů typu haskellovských monád.

10. Existuje dost hezkých utilitek (třeba skvělý ripgrep), jejichž kód je radost číst. Některé svoje pythonovské skriptíky jsem převedl do Rustu a jsou jenom o něco málo pracnější než originály v Pythonu. A existuje spousta dost zajímavých věcí k hraní - v oblasti sítí atd. Rust je sexy.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 01. 06. 2018, 13:15:47
Objektivně? Asi Java, jsou v tom peníze, má to knuhovny a JVM je super.
Subjektivně? Kdybych se chtěl naučit OOP a bavit se u toho, tak SmallTalk (Pharo).
Kdybych si chtěl vyvíjet rychlý aplikace a "psát obyčejnej kód" tak základy Ruby a pak Crystal. Možná Rust.
A kdybych se chtěl OOP naučit jen tak náhodou, protože to vlastně není zas tak hrozně důležitý, tak Python.
A teprve potom bych si troufl na JS, s tím, že bych se cestou naučil ještě Scheme.
OOP není jen Java nebo C++, i takové Go je OO.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Ondra Satai Nekola 01. 06. 2018, 13:16:48
Groovy je tu co já pamatuji a pořád je obskurita, která občas vypadne ze skříně.

Neprijde mi. Diky Spocku jsem v nem videl napsanych hodne testu.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 01. 06. 2018, 13:56:16
(...)
9. Používá dost vlastností funkcionálních jazyků (pattern matching, obsluha chyb), ale bez extrémů typu haskellovských monád.
(...)

Můžu se zeptat, v čem jsou haskellovské monády extrémní? :)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: gll 01. 06. 2018, 14:01:23
Objektivně? Asi Java, jsou v tom peníze, má to knuhovny a JVM je super.
Subjektivně? Kdybych se chtěl naučit OOP a bavit se u toho, tak SmallTalk (Pharo).
Kdybych si chtěl vyvíjet rychlý aplikace a "psát obyčejnej kód" tak základy Ruby a pak Crystal. Možná Rust.
A kdybych se chtěl OOP naučit jen tak náhodou, protože to vlastně není zas tak hrozně důležitý, tak Python.
A teprve potom bych si troufl na JS, s tím, že bych se cestou naučil ještě Scheme.

má smysl učit se mrtvé jazyky?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 01. 06. 2018, 14:08:40
(...)
9. Používá dost vlastností funkcionálních jazyků (pattern matching, obsluha chyb), ale bez extrémů typu haskellovských monád.
(...)

Můžu se zeptat, v čem jsou haskellovské monády extrémní? :)

Můžeš, ale podle mě to víš. Jde zejména o IO monádu, která z čistě funkcionálního jazyka dělá něco, co umí komunikovat s vnějším světem.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Akiz 01. 06. 2018, 14:34:33
má smysl učit se mrtvé jazyky?

Má, nehledě na to, že SmallTalk díky PHARO mrtvý není, v žádném případě.

Stejně tak má smysl se učit řemeslo na věcech, které nikdy neprodáte.
Budete mít základy a pak vás toho moc nepřekvapí.
Naopak se budete podivovat, proč jsou nejpopulárnější ty jazyky, které jsou :-).
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: uuuuuuuu 01. 06. 2018, 14:42:21
má smysl učit se mrtvé jazyky?

Má, nehledě na to, že SmallTalk díky PHARO mrtvý není, v žádném případě.

Stejně tak má smysl se učit řemeslo na věcech, které nikdy neprodáte.
Budete mít základy a pak vás toho moc nepřekvapí.
Naopak se budete podivovat, proč jsou nejpopulárnější ty jazyky, které jsou :-).

Nektere mrtve technologie maji podobnou krasu jako parni masinky.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: gll 01. 06. 2018, 15:03:28
má smysl učit se mrtvé jazyky?

Má, nehledě na to, že SmallTalk díky PHARO mrtvý není, v žádném případě.

Stejně tak má smysl se učit řemeslo na věcech, které nikdy neprodáte.
Budete mít základy a pak vás toho moc nepřekvapí.
Naopak se budete podivovat, proč jsou nejpopulárnější ty jazyky, které jsou :-).

Co je na Smalltalku a Scheme tak skvělého oproti moderním jazykům?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 01. 06. 2018, 15:31:36
(...)
9. Používá dost vlastností funkcionálních jazyků (pattern matching, obsluha chyb), ale bez extrémů typu haskellovských monád.
(...)

Můžu se zeptat, v čem jsou haskellovské monády extrémní? :)

Můžeš, ale podle mě to víš. Jde zejména o IO monádu, která z čistě funkcionálního jazyka dělá něco, co umí komunikovat s vnějším světem.

A co je na ní extrémního? Zrovna IO monáda je celkem zajímavý a pěkný koncept, kdy člověk pak víc uvažuje nad kódem (ve smyslu, je tady opravdu nutná?, apod.), ale chápu, že toto bude asi dost individuální. :) Především k čemu by byl takový jazyk, který neumí komunikovat s vnějším světem?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 01. 06. 2018, 15:34:33
má smysl učit se mrtvé jazyky?

Má smysl učit se latinu? (i když ani ta není zas tak mrtvá) Asi hodně záleží který konkrétní jazyk, protože často se i studiem toho, co bylo, člověk spoustu naučí i ve vztahu k tomu, co je nebo bude. :)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 01. 06. 2018, 15:39:58
(...)
9. Používá dost vlastností funkcionálních jazyků (pattern matching, obsluha chyb), ale bez extrémů typu haskellovských monád.
(...)

Můžu se zeptat, v čem jsou haskellovské monády extrémní? :)

Můžeš, ale podle mě to víš. Jde zejména o IO monádu, která z čistě funkcionálního jazyka dělá něco, co umí komunikovat s vnějším světem.

A co je na ní extrémního? Zrovna IO monáda je celkem zajímavý a pěkný koncept, kdy člověk pak víc uvažuje nad kódem (ve smyslu, je tady opravdu nutná?, apod.), ale chápu, že toto bude asi dost individuální. :) Především k čemu by byl takový jazyk, který neumí komunikovat s vnějším světem?

Úplně se argumentačně míjíme. Otázka zněla, zda se má Rust šanci masověji prosadit a proč. Já jsem psal důvody, proč myslím, že má reálnou šanci. Zároveň mám určitý názor na masovou prosaditelnost Haskellu a tomu šanci moc nedávám, bez ohledu na to, zda IO monad považuju za dobrý nápad. Dál se v tom vrtat nebudu, promiň.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 01. 06. 2018, 16:02:15
(...)
9. Používá dost vlastností funkcionálních jazyků (pattern matching, obsluha chyb), ale bez extrémů typu haskellovských monád.
(...)

Můžu se zeptat, v čem jsou haskellovské monády extrémní? :)

Můžeš, ale podle mě to víš. Jde zejména o IO monádu, která z čistě funkcionálního jazyka dělá něco, co umí komunikovat s vnějším světem.

A co je na ní extrémního? Zrovna IO monáda je celkem zajímavý a pěkný koncept, kdy člověk pak víc uvažuje nad kódem (ve smyslu, je tady opravdu nutná?, apod.), ale chápu, že toto bude asi dost individuální. :) Především k čemu by byl takový jazyk, který neumí komunikovat s vnějším světem?

Úplně se argumentačně míjíme. Otázka zněla, zda se má Rust šanci masověji prosadit a proč. Já jsem psal důvody, proč myslím, že má reálnou šanci. Zároveň mám určitý názor na masovou prosaditelnost Haskellu a tomu šanci moc nedávám, bez ohledu na to, zda IO monad považuju za dobrý nápad. Dál se v tom vrtat nebudu, promiň.

Ne, otázka zněla, co je extrémního na monádách v Haskellu, takže se opravdu trochu míjíme. ;) Masová prosaditelnost Haskellu je věc úplně odlišná a tam se pravděpodobně shodneme, ale na to jsem se neptal.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: gll 01. 06. 2018, 16:24:36
má smysl učit se mrtvé jazyky?

Má smysl učit se latinu? (i když ani ta není zas tak mrtvá) Asi hodně záleží který konkrétní jazyk, protože často se i studiem toho, co bylo, člověk spoustu naučí i ve vztahu k tomu, co je nebo bude. :)

Latinská literatura nezastarává, narozdíl od softwaru. Pokud je cílem naučit se moderní románský jazyk, studium latiny moc nepomůže.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 01. 06. 2018, 16:39:33

Latinská literatura nezastarává, narozdíl od softwaru. Pokud je cílem naučit se moderní románský jazyk, studium latiny moc nepomůže.

Tady záleží, co v té latině člověk čte. :)
Pokud je cílem naučit se moderní románský jazyk (ať už se pod tím pojmem skrývá cokoliv), tak latina určitě pomůže, respektive usnadní hlubší pochopení. A ani nemusí jít nutně o románský jazyk, taková angličtina byla obohacována jak francouzštinou, tak i přímo latinou. Ale to už jsme asi trošku OT. :)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: I/O 01. 06. 2018, 16:51:50
má smysl učit se mrtvé jazyky?

Má, nehledě na to, že SmallTalk díky PHARO mrtvý není, v žádném případě.

Stejně tak má smysl se učit řemeslo na věcech, které nikdy neprodáte.
Budete mít základy a pak vás toho moc nepřekvapí.
Naopak se budete podivovat, proč jsou nejpopulárnější ty jazyky, které jsou :-).

Co je na Smalltalku a Scheme tak skvělého oproti moderním jazykům?
Prej oproti "moderním jazykům"! ROFL!!  ;D
Ptal bych se spíš obráceně - co přinášejí ty tzv. "moderní jazyky" navíc oproti třeba Smalltalku nebo Scheme, když z nich v každé nové verzi vykradou nějakou věc a prezentují ji jako něco super new hyper cool. Nemusím aspoň čekat, kdy si nějaký frikulín konečně všimne nebo znovuobjeví/pochopí nějakou 40 let starou fíčuru a konečně ji implementuje v nové verzi do toho svého "moderního" jazyka, čímž samozřejmě outdatuje kód napsaný v předešlé verzi, což je pro praktickou práci fakt moc příjemný.

Úplně se argumentačně míjíme. Otázka zněla, zda se má Rust šanci masověji prosadit a proč. Já jsem psal důvody, proč myslím, že má reálnou šanci. Zároveň mám určitý názor na masovou prosaditelnost Haskellu a tomu šanci moc nedávám, bez ohledu na to, zda IO monad považuju za dobrý nápad. Dál se v tom vrtat nebudu, promiň.
Jenže tyhle věci o prosazení jazyků moc nerozhodují. FORTRAN se rozšířil, protože nic jiného nebylo a protože IBM. Pascal byl ve své době populární, protože CP/M a protože Borland. C se rozšířilo s Unixem. C++ se svezlo na popularitě C a protože Borland a Microsoft. Java se rozšířila, protože C++ bylo populární a protože Sun těžce zafinancoval. Přitom ani jeden z těch jazyků není žádná hitparáda.
Proto si myslím, že se Rust zařadí mezi ty bezvýznamné jazyky - na nic známéno nenavazuje, nic významného v něm není napsáno a nemá tak silnou korporátní podporu, jakou by musel mít, aby měl šanci.

Latinská literatura nezastarává, narozdíl od softwaru. Pokud je cílem naučit se moderní románský jazyk, studium latiny moc nepomůže.
My měli latinu na gymplu a přinejmenším díky ní pasivně románským jazykům rozumím - když si přečtu text, tak přestože ten jazyk neumím, pochopím, o čem to je.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 01. 06. 2018, 17:10:15
(...)
9. Používá dost vlastností funkcionálních jazyků (pattern matching, obsluha chyb), ale bez extrémů typu haskellovských monád.
(...)

Můžu se zeptat, v čem jsou haskellovské monády extrémní? :)
99% vývojářů je nikdy nepochopí :)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 01. 06. 2018, 17:14:34

Latinská literatura nezastarává, narozdíl od softwaru. Pokud je cílem naučit se moderní románský jazyk, studium latiny moc nepomůže.

Tady záleží, co v té latině člověk čte. :)
Pokud je cílem naučit se moderní románský jazyk (ať už se pod tím pojmem skrývá cokoliv), tak latina určitě pomůže, respektive usnadní hlubší pochopení. A ani nemusí jít nutně o románský jazyk, taková angličtina byla obohacována jak francouzštinou, tak i přímo latinou. Ale to už jsme asi trošku OT. :)
gll prostě zase mele nesmysly...
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: gll 01. 06. 2018, 20:27:34
gll prostě zase mele nesmysly...

uveď příklad v některém z těch prehistorických jazyků a já to přepíšu do moderního jazyka lépe.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 01. 06. 2018, 20:44:55
Úplně se argumentačně míjíme. Otázka zněla, zda se má Rust šanci masověji prosadit a proč. Já jsem psal důvody, proč myslím, že má reálnou šanci. Zároveň mám určitý názor na masovou prosaditelnost Haskellu a tomu šanci moc nedávám, bez ohledu na to, zda IO monad považuju za dobrý nápad. Dál se v tom vrtat nebudu, promiň.

Jenže tyhle věci o prosazení jazyků moc nerozhodují. FORTRAN se rozšířil, protože nic jiného nebylo a protože IBM. Pascal byl ve své době populární, protože CP/M a protože Borland. C se rozšířilo s Unixem. C++ se svezlo na popularitě C a protože Borland a Microsoft. Java se rozšířila, protože C++ bylo populární a protože Sun těžce zafinancoval. Přitom ani jeden z těch jazyků není žádná hitparáda.
Proto si myslím, že se Rust zařadí mezi ty bezvýznamné jazyky - na nic známéno nenavazuje, nic významného v něm není napsáno a nemá tak silnou korporátní podporu, jakou by musel mít, aby měl šanci.

Nemyslím si, že se to dá takto generalizovat. Uvidíme.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 01. 06. 2018, 21:57:01
Co je na Smalltalku a Scheme tak skvělého oproti moderním jazykům?

Skvělé je na nich zejména to, že moderní jazyky z nich jen nedokonale kopírují a pracně dodělávají to, co nezkopírovaly. Co například přinesl nového Javascript proti Scheme? Co má lépe udělaného Java proti Smalltalku? Jsou to jen hype napodobeniny.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: balki 01. 06. 2018, 22:08:20
Co je na Smalltalku a Scheme tak skvělého oproti moderním jazykům?

Skvělé je na nich zejména to, že moderní jazyky z nich jen nedokonale kopírují a pracně dodělávají to, co nezkopírovaly. Co například přinesl nového Javascript proti Scheme? Co má lépe udělaného Java proti Smalltalku? Jsou to jen hype napodobeniny.

Aplikacia v jave nezahrna cely cele vyvojove prostredie a image s kopcom zbytocnych objektov. Java je tiez rychlejsia. Javascript oproti scheme ma tu vyhodu, ze je bezne pouzivany vo webovych browseroch.

Viem, ze to mala byt recnicka, ale nedalo mi.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: gll 01. 06. 2018, 22:27:42
Co například přinesl nového Javascript proti Scheme?

hashmapy, pole, prototypové OOP
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 01. 06. 2018, 22:31:42
Aplikacia v jave nezahrna cely cele vyvojove prostredie a image s kopcom zbytocnych objektov. Java je tiez rychlejsia. Javascript oproti scheme ma tu vyhodu, ze je bezne pouzivany vo webovych browseroch.

Když vezmu nejen Javascript, tak celý webový ekosystém by se dal transformovat asi takto:
Zapomněl jsem snad na něco důležitého?

Prohlížeče by byly mnohem výkonnější, protože by jim stačilo zvládat jediný jazyk.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 01. 06. 2018, 22:33:10
Co například přinesl nového Javascript proti Scheme?

hashmapy, pole, prototypové OOP

Tohle přece má Scheme už dávno.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: balki 01. 06. 2018, 22:38:15
Aplikacia v jave nezahrna cely cele vyvojove prostredie a image s kopcom zbytocnych objektov. Java je tiez rychlejsia. Javascript oproti scheme ma tu vyhodu, ze je bezne pouzivany vo webovych browseroch.

Když vezmu nejen Javascript, tak celý webový ekosystém by se dal transformovat asi takto:
  • Javascript -> Scheme
  • CSS -> Scheme
  • HTML -> Scheme
  • HTTP -> Scheme
  • JSON -> Scheme
  • PHP -> Scheme
  • WebSocket -> Scheme
Zapomněl jsem snad na něco důležitého?

Prohlížeče by byly mnohem výkonnější, protože by jim stačilo zvládat jediný jazyk.

Tak, zasa da sa vsade pouzit javascript, ked to takto berieme. A nie je to "byly by", ale proste hotove riesenia. Hram sa tu na diablovho advokata, v skutocnosti mam rad scheme.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: gll 01. 06. 2018, 22:59:02
Co například přinesl nového Javascript proti Scheme?

hashmapy, pole, prototypové OOP

Tohle přece má Scheme už dávno.

SICP Scheme nic takového nemá.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 01. 06. 2018, 23:12:07
Co například přinesl nového Javascript proti Scheme?

hashmapy, pole, prototypové OOP

Tohle přece má Scheme už dávno.

SICP Scheme nic takového nemá.

SICP možná ne, ale jiné implementace Scheme to již mají. Stačí si jen vybrat.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 02. 06. 2018, 15:29:52
Co je na Smalltalku a Scheme tak skvělého oproti moderním jazykům?

Skvělé je na nich zejména to, že moderní jazyky z nich jen nedokonale kopírují a pracně dodělávají to, co nezkopírovaly. Co například přinesl nového Javascript proti Scheme? Co má lépe udělaného Java proti Smalltalku? Jsou to jen hype napodobeniny.

Aplikacia v jave nezahrna cely cele vyvojove prostredie a image s kopcom zbytocnych objektov. Java je tiez rychlejsia. Javascript oproti scheme ma tu vyhodu, ze je bezne pouzivany vo webovych browseroch.

Viem, ze to mala byt recnicka, ale nedalo mi.
Proč by měla být Java rychlejší?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: jsf 03. 06. 2018, 10:04:45
A co je teda spatneho na C++? Dobreho programatora, ktery se umi orientovat v C++11/14/17 by jeden pohledal (a pak taky zaplatil...). Nemluve, ze moderni (11/14/17) C++ nema se starym C++ prakticky nic spolecne, umoznuje psat efektivne rychly a dobre citelny kod.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Milfaus 03. 06. 2018, 11:12:02
A co je teda spatneho na C++?

Protože se jedná o příliš nízkoúrovňový jazyk, který je naprosto nevhodný na řešení business aplikací.
Když děláš pro banku chceš, aby se 1+2+1=4 a ne 897754646, protože přetekla proměnná vedle  ;D


Citace
NEsouhlasím se zpracováním osobních údajů, zejména v rozsahu debilního checkboxu na fóru.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: jsf 03. 06. 2018, 11:19:21

Protože se jedná o příliš nízkoúrovňový jazyk, který je naprosto nevhodný na řešení business aplikací.
Když děláš pro banku chceš, aby se 1+2+1=4 a ne 897754646, protože přetekla proměnná vedle  ;D


Div se svete, ale to uz davno neni pravda... Celkem bezne pouzivam typy jako Safe<uint32_t>, BigInt a pod.. Jak rikam, moderni C++ nema se starym C++98 uz mnoho spolecneho.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 03. 06. 2018, 14:00:53
A co je teda spatneho na C++?

Protože se jedná o příliš nízkoúrovňový jazyk, který je naprosto nevhodný na řešení business aplikací.
Když děláš pro banku chceš, aby se 1+2+1=4 a ne 897754646, protože přetekla proměnná vedle  ;D


Citace
NEsouhlasím se zpracováním osobních údajů, zejména v rozsahu debilního checkboxu na fóru.
To ti řekla domovnice nebo smažky v hospodě?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kiwi 03. 06. 2018, 23:20:04

Protože se jedná o příliš nízkoúrovňový jazyk, který je naprosto nevhodný na řešení business aplikací.
Když děláš pro banku chceš, aby se 1+2+1=4 a ne 897754646, protože přetekla proměnná vedle  ;D


Div se svete, ale to uz davno neni pravda... Celkem bezne pouzivam typy jako Safe<uint32_t>, BigInt a pod.. Jak rikam, moderni C++ nema se starym C++98 uz mnoho spolecneho.
C++ je hlavně neuvěřitelná nastavovaná kaše. A pokud jde o čitelnost, tak ta mi teda nepřipadá kdo ví jaká. Dokonce bych řekl, že je to write only jazyk.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: mikrom 04. 06. 2018, 00:29:30
Co je na Smalltalku ... tak skvělého oproti moderním jazykům?
Podla mna nic, to tu niektori ludia zase iba fantaziruju.
Smalltalk mal velky vyznam, lebo priniesol koncepty OOP, ktore prebrali ine jazyky, ale jeho nevyhodou je, ze je to jazyk zviazany s IDE, co bol vtedy asi experiment, ktory sa ukazal ako neprakticky a preto sa dalej neujal. V dnesnej dobe je mozno dobry na nejaku experimentalnu vyuku principov OOP. Mne sa ako jedina pouzitelna varianta javi GNU Smalltalk, kde sa da program napisat do textoveho suboru a spustit standardne z command line prikazom
Kód: [Vybrat]
gst hello_world.stMusiet v Smalltalku produktivne nieco vacsie naprogramovat by bolo asi utrpenie, zrejme preto sa skoro vobec nepouziva.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 04. 06. 2018, 03:32:33
Co je na Smalltalku ... tak skvělého oproti moderním jazykům?
Podla mna nic, to tu niektori ludia zase iba fantaziruju.
Smalltalk mal velky vyznam, lebo priniesol koncepty OOP, ktore prebrali ine jazyky, ale jeho nevyhodou je, ze je to jazyk zviazany s IDE, co bol vtedy asi experiment, ktory sa ukazal ako neprakticky a preto sa dalej neujal. V dnesnej dobe je mozno dobry na nejaku experimentalnu vyuku principov OOP. Mne sa ako jedina pouzitelna varianta javi GNU Smalltalk, kde sa da program napisat do textoveho suboru a spustit standardne z command line prikazom
Kód: [Vybrat]
gst hello_world.stMusiet v Smalltalku produktivne nieco vacsie naprogramovat by bolo asi utrpenie, zrejme preto sa skoro vobec nepouziva.
Smalltalk má z dnešního pohledu jednu velkou nevýhodu - nemá statické typování.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 04. 06. 2018, 07:23:33
Smalltalk má z dnešního pohledu jednu velkou nevýhodu - nemá statické typování.

Netypovost Smalltalku má v OOP jazyku docela smysl, ale je otázka, zda celé OOP není slepá ulička.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: jsf 04. 06. 2018, 09:24:44

C++ je hlavně neuvěřitelná nastavovaná kaše. A pokud jde o čitelnost, tak ta mi teda nepřipadá kdo ví jaká. Dokonce bych řekl, že je to write only jazyk.
Hmm, a nejake argumenty? Treba tohle je citelne uplne krasne: https://github.com/EOSIO/eos/blob/master/libraries/chain/
(treba zrovna EOS opravdu pouziva moderni C++14/17 a zadou prahistorii)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 04. 06. 2018, 09:29:46
Dobrý pilot zná plno triků, jak udržet letadlo pod kontrolou.
Špičkový pilot je zná taky, ale snaží se lítat tak, aby je nepotřeboval.

A ti nejlepší piloti umějí letadlo nejen kontrolovat, ale i řídit.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: balki 04. 06. 2018, 09:32:04
Dobrý pilot zná plno triků, jak udržet letadlo pod kontrolou.
Špičkový pilot je zná taky, ale snaží se lítat tak, aby je nepotřeboval.

A ti nejlepší piloti umějí letadlo nejen kontrolovat, ale i řídit.

A tí úplne najsamšpičkovejší ovládajú lietadlo telekinézou.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 04. 06. 2018, 10:02:24
Aplikacia v jave nezahrna cely cele vyvojove prostredie a image s kopcom zbytocnych objektov...

Tak to není dobrý argument - zahrnutí vývojového prostředí je implementační záležitostí, nemusí tomu nutně tak být. K tomu části z image např. Phara je možno před nasazením povyhazovat, ale nestojí to za to. Kompletní(!) image, co koukám, má 50 MB, to mají jiná prostředí (např. Nodejs) taky. Mimoto (jako výborný příklad) existoval image Cuis, který neměl sice kdeco, ale směroval se minimalisticky, ten měl 6 MB!
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 04. 06. 2018, 10:09:41
My měli latinu na gymplu a přinejmenším díky ní pasivně románským jazykům rozumím - když si přečtu text, tak přestože ten jazyk neumím, pochopím, o čem to je.

Docela mě mrzí, že my už tu latinu na gymplu neměli, protože postupem času při učení dalších evropských jazyků člověk stejně zjistí, že se v nich projevuje. Např. angličtina je ze 1/3 vykradená latina, čeština vychází z latinského skloňování, všechny jazyky využívají její sloví zásobu, pooužívá se v lékařství, biologii, historických textech, ...
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 04. 06. 2018, 10:16:02
C++ je hlavně neuvěřitelná nastavovaná kaše. A pokud jde o čitelnost, tak ta mi teda nepřipadá kdo ví jaká. Dokonce bych řekl, že je to write only jazyk.

A v tom je právě ten problém - jazyk, který umí všechno, zvládne vytvořit kdejaký debil, ale aby ten jazyk přitom zůstal jednoduchý, přehledný a čistý, neboli velké schopnosti malými prostředky, tak to zvládne málokdo. Proto je takových jazyků pár, ostatní jsou jen jejich slepenci.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 04. 06. 2018, 10:30:14
Co je na Smalltalku ... tak skvělého oproti moderním jazykům?

Jen tak z hlavy: Je pořád jednoduchý i po implementaci např. mixinů ap. Má dosud nepřekonaný debugger, kdy je možno za chodu opravovat chyby a pokračovat ve výpočtu bez nutnosti cosi znovu kompilovat či spouštět. Je message oriented (správný název pro původní záměr autorů) a zároveň zapouzdřuje - to zvládá ze známých jazyků pouze Javascript, ale za cenu složité konstrukce objektů s vnořenými funkčními kontexty.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 04. 06. 2018, 10:33:43
Smalltalk má z dnešního pohledu jednu velkou nevýhodu - nemá statické typování.

Toto je nesmyslná paušalizace. Má to svoje výhody i nevýhody.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 04. 06. 2018, 10:40:55
Netypovost Smalltalku má v OOP jazyku docela smysl, ale je otázka, zda celé OOP není slepá ulička.

Netypovost je především předpokladem pozdní vazby!
Zjevně není, pořád jsou věci, které se v tom modelují jednoduše. Zádrhelem je, že to není pro kdekoho, to ale funkcionální jazyky taky ne.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 04. 06. 2018, 10:58:02
Netypovost Smalltalku má v OOP jazyku docela smysl, ale je otázka, zda celé OOP není slepá ulička.

Netypovost je především předpokladem pozdní vazby!
Zjevně není, pořád jsou věci, které se v tom modelují jednoduše. Zádrhelem je, že to není pro kdekoho, to ale funkcionální jazyky taky ne.

Ono asi zadne programovani neni "pro kdekoho", ale to je zase jina vec. Mas nejaky priklad typicke domeny, kde je "klasicke" OOP vyrazne vyhodnejsi nez treba typova parametrizace? Krome tvorby GUI...
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kiwi 04. 06. 2018, 11:31:48
Smalltalk má z dnešního pohledu jednu velkou nevýhodu - nemá statické typování.
Alan Kay by tě asi za takové tvrzení sežral za živa. Statické typování se s objektovým modelem vůbec nesnese, to je zkrátka fakt, který vychází ze samotné podstaty objektového modelu. Statickým typováním se objektový jazyk neuvěřitelně zkomplikuje - stačí se kouknout na C++ nebo na Javu (a na jejich historický vývoj) a uvědomit si, které všechny konstrukce v těch jazycích jsou jen kvůli typům. Středobodem OOP není dědění ani zapouzdření, jak se s oblibou omílá jako mantra, ale polymorfismus, k němuž je nezbytná pozdní vazba. Na to je třeba mít proměnné spíše jen jako místa pro různé instance, ale není třeba je předem označovat visačkou typu, protože typová kontrola není v OOP zapotřebí - všechny ty objekty jsou dostatečně inteligentní entity k tomu, aby chybu vyřešily samy ad hoc podle momentálních okolností. Nebo vůbec nemusí jít o chybu - pokud několik různých nesouvisejících objektů rozumí stejné zprávě, tak neexistuje rozumný důvod, proč by měl objektový jazyk zakazovat umístit je do stejné proměnné. Typová kontrola mi tuto pozdní vazbu strašně ztěžuje. Prakticky jakýkoliv kus kódu ve Smalltalku je mnohem kratší a přehlednější než ten samý u Javy, o C++ ani nemluvě.

Jako největší výhoda statického typování se uvádí odhalení chyb při kompilaci. Ale to se dá řešit unit testy - a např. Smalltalk k jejich psaní nabízí mocné prostředky.

Stručně - statické typování vychází z myšlenky, že dopředu vím co s čím budu dělat, už v době kompilace. Objektový model ale vychází z přesně opačné myšlenky - že takovéto věci se rozhodnou až za běhu uvnitř objektů. Proto bude statický typový systém v objektovém jazyku vždycky představovat obrovskou kouli na noze.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Ondra Satai Nekola 04. 06. 2018, 11:55:54
Jako největší výhoda statického typování se uvádí odhalení chyb při kompilaci. Ale to se dá řešit unit testy - a např. Smalltalk k jejich psaní nabízí mocné prostředky.

Rozdil mezi unittesty a statickym typovanim, je, ze unitttest ti ukazuje situace, kde to z hlediska typu funguje. Staticke typy ti zarucuji, ze to v ramci typu (ne nutne celeho runtime) funguje.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 04. 06. 2018, 12:02:31
Jako největší výhoda statického typování se uvádí odhalení chyb při kompilaci. Ale to se dá řešit unit testy - a např. Smalltalk k jejich psaní nabízí mocné prostředky.

Java se snažila místo testů použít typy. Testy jsou však stále potřebné, vznikla jakási validační schizofrenie. Podobně se statické typování cpe do PHP,  i když ho nepotřebuje. Smalltalk se o to nepokusil a zůstal u testů, čímž celý návrh aplikace zjednodušil.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Ondra Satai Nekola 04. 06. 2018, 12:16:43
Jako největší výhoda statického typování se uvádí odhalení chyb při kompilaci. Ale to se dá řešit unit testy - a např. Smalltalk k jejich psaní nabízí mocné prostředky.

Java se snažila místo testů použít typy. Testy jsou však stále potřebné, vznikla jakási validační schizofrenie. Podobně se statické typování cpe do PHP,  i když ho nepotřebuje. Smalltalk se o to nepokusil a zůstal u testů, čímž celý návrh aplikace zjednodušil.

Protoze oboji resi jiny problem? To neni schizofrenie, proste pouzivas pro kazdou uroven mozne chyby nejvhodnejsi nastroj. (Ze by se Java misto testu pokousela prosadit typy je samozrejme hovadina. To z principu nejde. Stejne jako z principu nejde mit typovou kontrolu udelanou tak dobre testy jako statickou kontrolou.)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 04. 06. 2018, 20:02:04
Netypovost Smalltalku má v OOP jazyku docela smysl, ale je otázka, zda celé OOP není slepá ulička.
Netypovost je především předpokladem pozdní vazby!
To je nebetyčná blbost.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: ava 05. 06. 2018, 11:36:56
Netypovost Smalltalku má v OOP jazyku docela smysl, ale je otázka, zda celé OOP není slepá ulička.

Netypovost je především předpokladem pozdní vazby!
Zjevně není, pořád jsou věci, které se v tom modelují jednoduše. Zádrhelem je, že to není pro kdekoho, to ale funkcionální jazyky taky ne.

(Bohužel v praxi vymizelí) následovníci Smalltalku jako je Self nebo Newspeak se ubírali směrem k optional (pluggable) type systémům, což mi pro dynamické jazyky jako je Smalltalk přijde jako ideální kompromis.

Pěkné shrnutí je tady: http://bracha.org/pluggableTypesPosition.pdf

Myslím (ale nevím podrobnosti), že optional type system má (měl?) i Dart, http://journal.stuffwithstuff.com/2011/10/21/wrapping-my-head-around-optional-typing/

Spíš pro zajímavost, Optional typing může fungovat jen v jazycích, kde typové anotace neovlivňují význam kódu, takže by asi mohl fungovat v Javě nebo v C#, ale už ne ve Scale (implicity) nebo v Rustu, F# (traity) - alespoň taková je moje intuice, formálně bych za to ruku do ohně nedal.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 05. 06. 2018, 13:39:51
Netypovost Smalltalku má v OOP jazyku docela smysl, ale je otázka, zda celé OOP není slepá ulička.

Netypovost je především předpokladem pozdní vazby!
Zjevně není, pořád jsou věci, které se v tom modelují jednoduše. Zádrhelem je, že to není pro kdekoho, to ale funkcionální jazyky taky ne.

(Bohužel v praxi vymizelí) následovníci Smalltalku jako je Self nebo Newspeak se ubírali směrem k optional (pluggable) type systémům, což mi pro dynamické jazyky jako je Smalltalk přijde jako ideální kompromis.

Pěkné shrnutí je tady: http://bracha.org/pluggableTypesPosition.pdf

Myslím (ale nevím podrobnosti), že optional type system má (měl?) i Dart, http://journal.stuffwithstuff.com/2011/10/21/wrapping-my-head-around-optional-typing/

Spíš pro zajímavost, Optional typing může fungovat jen v jazycích, kde typové anotace neovlivňují význam kódu, takže by asi mohl fungovat v Javě nebo v C#, ale už ne ve Scale (implicity) nebo v Rustu, F# (traity) - alespoň taková je moje intuice, formálně bych za to ruku do ohně nedal.
A co ObjC?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 05. 06. 2018, 14:17:56
...Mas nejaky priklad typicke domeny, kde je "klasicke" OOP vyrazne vyhodnejsi nez treba typova parametrizace? Krome tvorby GUI...

Tak zrovna GUI určitě není něco, kvůli čemu OOP vzniklo. Pro mě(!) pořád platí snadné modelování obchodních systémů. Jiné užití mě nyní nenapadá.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 05. 06. 2018, 14:48:00
...Středobodem OOP není dědění ani zapouzdření, jak se s oblibou omílá jako mantra, ale polymorfismus, k němuž je nezbytná pozdní vazba...

Tak pozor, zapouzdření JE jednou z klíčových vlastností OOP, protože tím zajišťuje izolaci problému v objektu, ale dohadovat se tu o tom nemíním, to už tu bylo.
Polymorfismus pochopitelně, ale ten je vlastně pouze důsledkem té pozdní vazby, ne vytvořený překladačem jako u podtypového kvazipolymorfismu.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 05. 06. 2018, 14:53:54
Rozdil mezi unittesty a statickym typovanim, je, ze unitttest ti ukazuje situace, kde to z hlediska typu funguje. Staticke typy ti zarucuji, ze to v ramci typu (ne nutne celeho runtime) funguje.

Ale hovno. Statické typování zajišťuje shody "typu", nanejvýš "podtypu". Nic víc, nic míň. To samo o sobě pochopitelně ještě nezaručuje správnost. Jednotkové testy NEMAJÍ s typy co do činění, pouze ověřují, zda pro dané vstupy vznikají požadované výstupy. To je vše. Zde pro změnu vzniká problém se správným pokrytím testy.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 05. 06. 2018, 14:57:29
Netypovost je především předpokladem pozdní vazby!
To je nebetyčná blbost.

Jak se instanci třídy "Kniha" v typovém systému posílá zpráva "diDoPyči", kterou Kniha vůbec nemá v protokolu?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Cikáda 05. 06. 2018, 15:05:10
Netypovost je především předpokladem pozdní vazby!
To je nebetyčná blbost.

Jak se instanci třídy "Kniha" v typovém systému posílá zpráva "diDoPyči", kterou Kniha vůbec nemá v protokolu?

Blbě
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: ava 05. 06. 2018, 15:20:32

(Bohužel v praxi vymizelí) následovníci Smalltalku jako je Self nebo Newspeak se ubírali směrem k optional (pluggable) type systémům, což mi pro dynamické jazyky jako je Smalltalk přijde jako ideální kompromis.

Pěkné shrnutí je tady: http://bracha.org/pluggableTypesPosition.pdf

Myslím (ale nevím podrobnosti), že optional type system má (měl?) i Dart, http://journal.stuffwithstuff.com/2011/10/21/wrapping-my-head-around-optional-typing/

Spíš pro zajímavost, Optional typing může fungovat jen v jazycích, kde typové anotace neovlivňují význam kódu, takže by asi mohl fungovat v Javě nebo v C#, ale už ne ve Scale (implicity) nebo v Rustu, F# (traity) - alespoň taková je moje intuice, formálně bych za to ruku do ohně nedal.
A co ObjC?

ObjC moc neznám, jen si vybavuji že je to mix C a Smalltalku, pro tu Smalltalkovou část by to asi šlo, pro tu C asi ne (muselo by to být hodně ohnuté C).
Ještě abych upravil svůj předchozí příspěvek - u Rustu a F# jsem myslel nikoliv traity ale typeclassy (které se v Rustu uvádějí klíčovým slovem trait, proto mě to zmátlo), a u typeclass si nejsem úplně jistý, jestli by se daly nějak napasovat na optional type system, možná jo..

A když jsem psal Self a Newspeak, myslel jsem StrongTalk a Newspeak, sorry :) Ale i na StrongTalku i na Dartu pracoval Gilad Bracha, takže k tomuhle tématu už budou asi relevatntnější dokumenty týkající se novějšího Dartu než staršího StrongTalku (třeba zde: http://www.bracha.org/nwst.html)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: BoneFlute 05. 06. 2018, 15:37:41
Podobně se statické typování cpe do PHP,  i když ho nepotřebuje.
Optional statické typy jsou věc, která činí PHP výjimečným (v rámci toho, že je to bastl). Říct, že ho nepotřebuje je zoufalé nepochopení vo co de.

Pokud nechápeš typy, tak používej jazyky, které je nemají. Python, nebo Javascript jsou v takovém případě mnohem lepší volbou.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 05. 06. 2018, 16:03:25
Podobně se statické typování cpe do PHP,  i když ho nepotřebuje.
Optional statické typy jsou věc, která činí PHP výjimečným (v rámci toho, že je to bastl). Říct, že ho nepotřebuje je zoufalé nepochopení vo co de.

Pokud nechápeš typy, tak používej jazyky, které je nemají. Python, nebo Javascript jsou v takovém případě mnohem lepší volbou.

Řekl bych, že jsi zoufale nepochopil, o co mi šlo.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kiwi 05. 06. 2018, 17:21:38
...Středobodem OOP není dědění ani zapouzdření, jak se s oblibou omílá jako mantra, ale polymorfismus, k němuž je nezbytná pozdní vazba...

Tak pozor, zapouzdření JE jednou z klíčových vlastností OOP, protože tím zajišťuje izolaci problému v objektu, ale dohadovat se tu o tom nemíním, to už tu bylo.
Polymorfismus pochopitelně, ale ten je vlastně pouze důsledkem té pozdní vazby, ne vytvořený překladačem jako u podtypového kvazipolymorfismu.
Izolace problému v objektu se principiálně neliší od izolace problému v modulu u jakéhokoli typu návrhu, neboli to není nic nového, co by přišlo až s OOP. Tak se člověk snažil programovat i v BASICu na 8bitech v rámci možností, které ten jazyk nabízel, tj. při absenci lokálních proměnných. Na "zapouzdřené" funkční moduly se dělí i samotný počítač, ale třeba i rádio, nejde-li o nějakou reflexní konstrukci. U OOP se to začalo zdůrazňovat hlavně v souvislosti s jazykovými prostředky, které to zapoudření zabezpečují i fakticky, což je podle mě celkem zbytečná věc.

Odvozování podtříd pomocí dědění je zase spíše taková zkratka, jak zrecyklovat existující kód, ale není v ničem významnější než třeba kompozice, která se tak zdaleka nezdůrazňuje.

Ovšem polymorfismus, to je něco, na čem OOP stojí a padá - ať už realizovaný na základě zpráv, nebo pomocí generických funkcí (u nichž zase ztrácí smysl zapouzdření, jak ho chápou jazyky jako Java). A ten zase stojí a padá s pozdní, přesněji velmi pozdní vazbou. Nechci se hádat o tom, co je předpokladem čeho, já chápu pozdní vazbu jako technické řešení polymorfismu a pojem polymorfismus za výstižnější, protože přesně popisuje, oč tu jde - o mnohotvárnost v typech objektů, jež se mohou vyskytnout na těch samých místech v různých okamžicích běhu programu. Časná vazba u statického typování je v příkrém rozporu s tímto přístupem, proto je tak obtížné toho polymorfismu ve staticky typovaných jazycích dosáhnout, proto je k tomu nezbytný rozsáhlý aparát na obcházení té časné vazby, proto jsou vymýšlený různé idiomy, jak typový systém obejít, a.k.a design patterns. A proto je většina programů v Javě nebo v C++ ve skutečnosti jen pramálo objektová.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 05. 06. 2018, 17:45:53
Časná vazba u statického typování je v příkrém rozporu s tímto přístupem, proto je tak obtížné toho polymorfismu ve staticky typovaných jazycích dosáhnout, proto je k tomu nezbytný rozsáhlý aparát na obcházení té časné vazby, proto jsou vymýšlený různé idiomy, jak typový systém obejít, a.k.a design patterns. A proto je většina programů v Javě nebo v C++ ve skutečnosti jen pramálo objektová.

V Javě se to dá obejít v jednodušších případech přes Object nebo je možné ho rozšířit o nějaké rozhraní.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 05. 06. 2018, 22:36:56
Podobně se statické typování cpe do PHP,  i když ho nepotřebuje.
Optional statické typy jsou věc, která činí PHP výjimečným (v rámci toho, že je to bastl). Říct, že ho nepotřebuje je zoufalé nepochopení vo co de.

Pokud nechápeš typy, tak používej jazyky, které je nemají. Python, nebo Javascript jsou v takovém případě mnohem lepší volbou.
Python i JavaScript mají typy, nějak se v tom plácáš.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: BoneFlute 05. 06. 2018, 22:56:02
Python i JavaScript mají typy, nějak se v tom plácáš.

To vykládej někomu, kdo tomu nerozumí.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: BoneFlute 05. 06. 2018, 23:03:23
Ovšem polymorfismus, to je něco, na čem OOP stojí a padá - ať už realizovaný na základě zpráv, nebo pomocí generických funkcí (u nichž zase ztrácí smysl zapouzdření, jak ho chápou jazyky jako Java).

Jen pro pořádek, polymorfizmus v haskellu:

Kód: [Vybrat]
format (JSON x) = ...
format (XML x) = ...
format (HTML x) = ...

IMHO základní princip, který opravdu charakterizuje OOP je umístění stavu do objektu. Vše ostatní tu bylo, je, a častokrát i líp.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 06. 06. 2018, 01:57:07
Python i JavaScript mají typy, nějak se v tom plácáš.

To vykládej někomu, kdo tomu nerozumí.
To evidentně právě dělám.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: BoneFlute 06. 06. 2018, 03:00:09
Python i JavaScript mají typy, nějak se v tom plácáš.

To vykládej někomu, kdo tomu nerozumí.
To evidentně právě dělám.

Že já vždycky těmhle trollům naběhnu...
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 06. 06. 2018, 11:04:05
IMHO základní princip, který opravdu charakterizuje OOP je umístění stavu do objektu. Vše ostatní tu bylo, je, a častokrát i líp.

Vidim to podobne.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: balki 06. 06. 2018, 11:23:31
IMHO základní princip, který opravdu charakterizuje OOP je umístění stavu do objektu. Vše ostatní tu bylo, je, a častokrát i líp.

Vidim to podobne.

Dodam este, ze ciste OOP samo o sebe neexistuje, vzdy je niecim "pokazene" a teda ide skor o multiparadigmovy pristup.  Kod moze byt viac objektovo-orientovany, alebo menej-objektovo orientovany podla toho, ake  je programator prasa, alebo ake obmedzenia su kladene na aplikaciu/system. OOP je stavove a stav je v objekte, to bez debaty.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: BoneFlute 06. 06. 2018, 15:00:34
Dodam este, ze ciste OOP samo o sebe neexistuje, vzdy je niecim "pokazene" a teda ide skor o multiparadigmovy pristup.  Kod moze byt viac objektovo-orientovany, alebo menej-objektovo orientovany podla toho, ake  je programator prasa, alebo ake obmedzenia su kladene na aplikaciu/system. OOP je stavove a stav je v objekte, to bez debaty.

Smalltalk by se do toho nevešel?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 06. 06. 2018, 15:57:32
Izolace problému v objektu se principiálně neliší od izolace problému v modulu u jakéhokoli typu návrhu, neboli to není nic nového, co by přišlo až s OOP.

Samotná izolace ne, ale objekty jsou mnohem víc! Jsou to izolované výpočetní jednotky, kterých si za běhu můžete jednoduše vytvořit, kolik chcete, a zase je smazat, jednoduše na ně ukazovat, nebo je naopak skrýt zapouzdřením, aby se viděly jen některé. To už je kurva novinkou!

...jazykovými prostředky, které to zapoudření zabezpečují i fakticky, což je podle mě celkem zbytečná věc.

Jasně, zapouzdření je přece na hovno. V ložnici přece taky nebudeme věšet záclony, aby nebylo dovnitř vidět, jak (a s kým) tam šukáte, stačí na okno napsat "NEKOUKAT". Nebo zamykání baráku. Taky na hovno, opět stačí napsat "NEPOVOLANÝM VSTUP ZAKÁZÁN" a už vám to nikdo nemůže vybrabčit. Nebo na kino stačí pověsit cedulku "Bezezbraňová zóna" a diváci jsou v bezpečí. Vždyť je to tak jednoduché!

Ovšem polymorfismus ... realizovaný ... pomocí generických funkcí (u nichž zase ztrácí smysl zapouzdření, jak ho chápou jazyky jako Java).

Generické funkce jsou taková ta omrdávka typového systému, pamatuju si to dobře, ne? Jak ale souvisejí se zapouzdřením, mi musíte vysvětlit.

...nezbytný rozsáhlý aparát na obcházení té časné vazby, proto jsou vymýšlený různé idiomy, jak typový systém obejít, a.k.a design patterns. A proto je většina programů v Javě nebo v C++ ve skutečnosti jen pramálo objektová.

Z návrhových vzorů řešících nedostatky v implementaci OOP si z hlavy vybavuju pouze dekorátor, což je ovšem typický příklad řešící chybějící pozdní vazbu v jazycích s podtypovým kvazipolymorfismem.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 06. 06. 2018, 16:03:58
Python i JavaScript mají typy, nějak se v tom plácáš.

To vykládej někomu, kdo tomu nerozumí.

Teď ještě si ujasnit, co jsou to ty typy. Jestli jsou protipólem tříd, tak třeba Javascript primitivní typy má (však už kolem jejich fungování bylo dost dusno).
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 06. 06. 2018, 16:26:27
Jen pro pořádek, polymorfizmus v haskellu:

Kód: [Vybrat]
format (JSON x) = ...
format (XML x) = ...
format (HTML x) = ...

IMHO základní princip, který opravdu charakterizuje OOP je umístění stavu do objektu. Vše ostatní tu bylo, je, a častokrát i líp.

Super. A zvládne to taky zpracovat zprávu "format", která nemá v parametru JSON, XML nebo HTML? A zvládne to zpracovat zprávu, pro kterou nemá vůbec žádný předpis?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 06. 06. 2018, 16:28:39
...jazykovými prostředky, které to zapoudření zabezpečují i fakticky, což je podle mě celkem zbytečná věc.

Jasně, zapouzdření je přece na hovno. V ložnici přece taky nebudeme věšet záclony, aby nebylo dovnitř vidět, jak (a s kým) tam šukáte, stačí na okno napsat "NEKOUKAT". Nebo zamykání baráku. Taky na hovno, opět stačí napsat "NEPOVOLANÝM VSTUP ZAKÁZÁN" a už vám to nikdo nemůže vybrabčit. Nebo na kino stačí pověsit cedulku "Bezezbraňová zóna" a diváci jsou v bezpečí. Vždyť je to tak jednoduché!

Někteří si však pod pojmem zapouzdření představují kukátko, kterým se do té ložnice smí koukat a kterým je vidět všechno, co se děje uvnitř.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 06. 06. 2018, 16:31:00
IMHO základní princip, který opravdu charakterizuje OOP je umístění stavu do objektu.

Stav tam je, ale na objekt to nestačí. Stav má v sobě kdeco.

Vše ostatní tu bylo, je, a častokrát i líp.

Rádi se necháme poučit.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 06. 06. 2018, 16:32:21
Izolace problému v objektu se principiálně neliší od izolace problému v modulu u jakéhokoli typu návrhu, neboli to není nic nového, co by přišlo až s OOP.

Samotná izolace ne, ale objekty jsou mnohem víc! Jsou to izolované výpočetní jednotky, kterých si za běhu můžete jednoduše vytvořit, kolik chcete, a zase je smazat, jednoduše na ně ukazovat, nebo je naopak skrýt zapouzdřením, aby se viděly jen některé. To už je kurva novinkou!

...jazykovými prostředky, které to zapoudření zabezpečují i fakticky, což je podle mě celkem zbytečná věc.

Jasně, zapouzdření je přece na hovno. V ložnici přece taky nebudeme věšet záclony, aby nebylo dovnitř vidět, jak (a s kým) tam šukáte, stačí na okno napsat "NEKOUKAT". Nebo zamykání baráku. Taky na hovno, opět stačí napsat "NEPOVOLANÝM VSTUP ZAKÁZÁN" a už vám to nikdo nemůže vybrabčit. Nebo na kino stačí pověsit cedulku "Bezezbraňová zóna" a diváci jsou v bezpečí. Vždyť je to tak jednoduché!

Ovšem polymorfismus ... realizovaný ... pomocí generických funkcí (u nichž zase ztrácí smysl zapouzdření, jak ho chápou jazyky jako Java).

Generické funkce jsou taková ta omrdávka typového systému, pamatuju si to dobře, ne? Jak ale souvisejí se zapouzdřením, mi musíte vysvětlit.

...nezbytný rozsáhlý aparát na obcházení té časné vazby, proto jsou vymýšlený různé idiomy, jak typový systém obejít, a.k.a design patterns. A proto je většina programů v Javě nebo v C++ ve skutečnosti jen pramálo objektová.

Z návrhových vzorů řešících nedostatky v implementaci OOP si z hlavy vybavuju pouze dekorátor, což je ovšem typický příklad řešící chybějící pozdní vazbu v jazycích s podtypovým kvazipolymorfismem.
Zapouzdření hlavně vůbec nesouvisí s OOP.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 06. 06. 2018, 16:32:37
Dodam este, ze ciste OOP samo o sebe neexistuje, vzdy je niecim "pokazene" a teda ide skor o multiparadigmovy pristup.  Kod moze byt viac objektovo-orientovany, alebo menej-objektovo orientovany podla toho, ake  je programator prasa, alebo ake obmedzenia su kladene na aplikaciu/system. OOP je stavove a stav je v objekte, to bez debaty.

Smalltalk by se do toho nevešel?

Nic mě nenapadá. Zkuste uvést příklad.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 06. 06. 2018, 16:35:25
Jen pro pořádek, polymorfizmus v haskellu:

Kód: [Vybrat]
format (JSON x) = ...
format (XML x) = ...
format (HTML x) = ...

IMHO základní princip, který opravdu charakterizuje OOP je umístění stavu do objektu. Vše ostatní tu bylo, je, a častokrát i líp.

Super. A zvládne to taky zpracovat zprávu "format", která nemá v parametru JSON, XML nebo HTML? A zvládne to zpracovat zprávu, pro kterou nemá vůbec žádný předpis?

Asi tam bude potřeba pro tyto účely přidat pravidlo na způsob
Kód: [Vybrat]
format (f x) = ...
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 06. 06. 2018, 16:37:13
Zapouzdření hlavně vůbec nesouvisí s OOP.

Souvisí. Hlavně je však potřebné vědět, co je to zapouzdření.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 06. 06. 2018, 16:41:11
IMHO základní princip, který opravdu charakterizuje OOP je umístění stavu do objektu.

Stav tam je, ale na objekt to nestačí. Stav má v sobě kdeco.

V objektu je nejen stav, ale hlavně algoritmy, které s tímto stavem pracují.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 06. 06. 2018, 16:43:37
Zapouzdření hlavně vůbec nesouvisí s OOP.

Naopak, OOP přímo ZÁVISÍ na zapouzdření, jinak by došlo k porušení izolace modelované subdomény od okolního světa a jejímu průniku mimo objekt, čímž by objekt ztratil zodpovědnost za svůj stav a jeho konsistenci, takže by už nešlo o objekt jako atomickou výpočetní jednotku.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 06. 06. 2018, 16:44:48
Jen pro pořádek, polymorfizmus v haskellu:

Kód: [Vybrat]
format (JSON x) = ...
format (XML x) = ...
format (HTML x) = ...

IMHO základní princip, který opravdu charakterizuje OOP je umístění stavu do objektu. Vše ostatní tu bylo, je, a častokrát i líp.

Super. A zvládne to taky zpracovat zprávu "format", která nemá v parametru JSON, XML nebo HTML? A zvládne to zpracovat zprávu, pro kterou nemá vůbec žádný předpis?

Asi tam bude potřeba pro tyto účely přidat pravidlo na způsob
Kód: [Vybrat]
format (f x) = ...

Supr. A co ta druhá otázka?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 06. 06. 2018, 17:10:19
Jen pro pořádek, polymorfizmus v haskellu:

Kód: [Vybrat]
format (JSON x) = ...
format (XML x) = ...
format (HTML x) = ...

IMHO základní princip, který opravdu charakterizuje OOP je umístění stavu do objektu. Vše ostatní tu bylo, je, a častokrát i líp.

Super. A zvládne to taky zpracovat zprávu "format", která nemá v parametru JSON, XML nebo HTML? A zvládne to zpracovat zprávu, pro kterou nemá vůbec žádný předpis?

Asi tam bude potřeba pro tyto účely přidat pravidlo na způsob
Kód: [Vybrat]
format (f x) = ...

Supr. A co ta druhá otázka?

V Haskellu neumím, ale to dodatečné pravidlo by mělo vyřešit obě otázky.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kiwi 06. 06. 2018, 20:36:20
Izolace problému v objektu se principiálně neliší od izolace problému v modulu u jakéhokoli typu návrhu, neboli to není nic nového, co by přišlo až s OOP.

Samotná izolace ne, ale objekty jsou mnohem víc! Jsou to izolované výpočetní jednotky, kterých si za běhu můžete jednoduše vytvořit, kolik chcete, a zase je smazat, jednoduše na ně ukazovat, nebo je naopak skrýt zapouzdřením, aby se viděly jen některé. To už je kurva novinkou!

...jazykovými prostředky, které to zapoudření zabezpečují i fakticky, což je podle mě celkem zbytečná věc.

Jasně, zapouzdření je přece na hovno. V ložnici přece taky nebudeme věšet záclony, aby nebylo dovnitř vidět, jak (a s kým) tam šukáte, stačí na okno napsat "NEKOUKAT". Nebo zamykání baráku. Taky na hovno, opět stačí napsat "NEPOVOLANÝM VSTUP ZAKÁZÁN" a už vám to nikdo nemůže vybrabčit. Nebo na kino stačí pověsit cedulku "Bezezbraňová zóna" a diváci jsou v bezpečí. Vždyť je to tak jednoduché!
To je spíš jen otázka organizace struktury programu. V neobjektovém návrhu mi nic nebrání vytvářet, mazat a ukazovat na proměnné, představující vzájemně izolovaná data, nad nimiž operují příslušné procedury. Zásadní je rozbití vazby mezi jménem procedury a konkrétním typem dat a odložení svázání s konkrétní procedurou až na poslední chvíli, tím vzniká polymorfismus. Ale to lze realizovat i jinak, třeba v Lispu se to dělá pomocí generických funkcí, které nejsou součástí žádné třídy, ale podle typu objektů, na které je volám, poznají, jakou konkrétní metodu mají zavolat. Třída je pak jen seznam jmen atributů a metod, její instance seznam konkrétních dat. Polymorfní to celé je, ale zapouzdřené? Sémanticky ano, technicky vůbec. À propos - znáš hodně lidí, kteří třeba v C pitvají útroby struktury FILE, jen protože jim v tom nic nebrání? Takovéhle operace jsou jak střelit se do vlastní nohy. Určitý smysl by to dávalo jen u objektů uchovávajících citlivá data, jež nejsou určena mně. Ale pokud by jejich zabezpečení mělo záviset na zapouzdření (v tom technickém smyslu), tak by byla zabezpečená dost mizerně. Proto v tom technickém znepřístupnění nevidím nic zásadního. Pokud by bylo myšleno to zapouzdření v sémantickém smyslu, tak to by bylo něco jiného. Ale taky nic až tak zásadního.

Ovšem polymorfismus ... realizovaný ... pomocí generických funkcí (u nichž zase ztrácí smysl zapouzdření, jak ho chápou jazyky jako Java).

Generické funkce jsou taková ta omrdávka typového systému, pamatuju si to dobře, ne? Jak ale souvisejí se zapouzdřením, mi musíte vysvětlit.
Nikoliv. Viz výše. To jsem se jen špatně vyjádřil.

...nezbytný rozsáhlý aparát na obcházení té časné vazby, proto jsou vymýšlený různé idiomy, jak typový systém obejít, a.k.a design patterns. A proto je většina programů v Javě nebo v C++ ve skutečnosti jen pramálo objektová.

Z návrhových vzorů řešících nedostatky v implementaci OOP si z hlavy vybavuju pouze dekorátor, což je ovšem typický příklad řešící chybějící pozdní vazbu v jazycích s podtypovým kvazipolymorfismem.
A taky všechny možné factory, proxy, mediátory, state, template method... To jsou všechno obraty v dynamicky typovaných jazycích jednoduché jak facka, takže nikoho nenapadlo je nějak pojmenovávat, ale teprve u těch statických se muselo přijít na idiomy, jakými se to chování známé z těch dynamických nasimuluje.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 07. 06. 2018, 00:00:47
Zapouzdření hlavně vůbec nesouvisí s OOP.
Souvisí. Hlavně je však potřebné vědět, co je to zapouzdření.
To je dost logické. Pak právě člověk ví, že nesouvisí ;)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 07. 06. 2018, 10:16:30
Zapouzdření hlavně vůbec nesouvisí s OOP.
Souvisí. Hlavně je však potřebné vědět, co je to zapouzdření.
To je dost logické. Pak právě člověk ví, že nesouvisí ;)

OOP bez zapouzdreni asi neni uplne koser, ale spousta lidi netusi, ze treba ve funkcionalnim Haskellu je mozne pomoci modulu dosahnout prakticky tehoz - s danym typem muze pracovat jenom dotycny modul, kdyz se z modulu nevyexportuje informace o vnitrku toho typu, proste se dovnitr funkce z jineho modulu vubec nepodiva.

Tudiz bych trval na tom, ze zapouzdreni neni to, co dela OOP. Natoz aby bylo jeho vysadou.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 07. 06. 2018, 10:39:02
Zapouzdření hlavně vůbec nesouvisí s OOP.
Souvisí. Hlavně je však potřebné vědět, co je to zapouzdření.
To je dost logické. Pak právě člověk ví, že nesouvisí ;)

OOP bez zapouzdreni asi neni uplne koser, ale spousta lidi netusi, ze treba ve funkcionalnim Haskellu je mozne pomoci modulu dosahnout prakticky tehoz - s danym typem muze pracovat jenom dotycny modul, kdyz se z modulu nevyexportuje informace o vnitrku toho typu, proste se dovnitr funkce z jineho modulu vubec nepodiva.

Tudiz bych trval na tom, ze zapouzdreni neni to, co dela OOP. Natoz aby bylo jeho vysadou.
Ano, tak nějak. Zapouzdření a OOP jsou dva ortogonální koncepty. Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 07. 06. 2018, 10:49:29
Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...

Sloučení dat s relevantními funkcemi je právě to zapouzdření.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Onestone 07. 06. 2018, 11:06:31
Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...

Sloučení dat s relevantními funkcemi je právě to zapouzdření.
Ne, to není.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: listoper 07. 06. 2018, 12:18:53
Ano, tak nějak. Zapouzdření a OOP jsou dva ortogonální koncepty. Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...

Tak sem si cetl o te studii a pokusu co Dunning a Kruger udelali. Jestli jsem to pochopil spravne tak prave potom co ty nekompetentni byli pouceni tak se jejich sebehodnoceni i uroven kompetence zlepsily.
Takze jestli radis javisty do skupiny nekompetentnich tak podle Dunning-Kruger by prave vysvetleni melo pomoci.
Pokud radis javisty do skupiny kompetentnich tak to asi vysvetlovat nebudou potrebovat.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: ava 07. 06. 2018, 13:49:29
Pojem OOP jako takový jen zastřešuje vlastnosti jako polymorfismus a sloučení dat s relevantními funkcemi. Javistům to ale vysvětlit nejde, protože Dunning-Kruger. O PHPčkářích už vůbec nemluvě...

Sloučení dat s relevantními funkcemi je právě to zapouzdření.
Ne, to není.

Mohl by ses teda konečně vymáčknout, co podle tebe zapouzdření je, místo toho aby jsi jen říkal "tohle ne, tohle taky ne"?

Wikipedia říká: In object oriented programming languages, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination[1][2] thereof:

     - A language mechanism for restricting direct access to some of the object's components.[3][4]
     - A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.[5][6]

to druhé to podle tebe není, takže ty za zapouzdření považuješ tu první odrážku? Nebo máš nějakou vlastní definici?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 08. 06. 2018, 09:01:38
Z návrhových vzorů řešících nedostatky v implementaci OOP si z hlavy vybavuju pouze dekorátor, což je ovšem typický příklad řešící chybějící pozdní vazbu v jazycích s podtypovým kvazipolymorfismem.
A taky všechny možné factory, proxy, mediátory, state, template method... To jsou všechno obraty v dynamicky typovaných jazycích jednoduché jak facka, takže nikoho nenapadlo je nějak pojmenovávat, ale teprve u těch statických se muselo přijít na idiomy, jakými se to chování známé z těch dynamických nasimuluje.

Pořád jsou to popisy typizovaných, i když často triviálních řešení, takže v pořádku. Akorát využitelnost oněch vzorů záleží na jazyku, takže nejsou obecné.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 08. 06. 2018, 09:08:38
Tudiz bych trval na tom, ze zapouzdreni neni to, co dela OOP.

Už jsem to psal - bez zapouzdření padá izolace problému v rámci objektu, takže už se nejedná o objekt.

Natoz aby bylo jeho vysadou.

To tu nikdo nikdy netvrdil.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: SB 08. 06. 2018, 09:12:07
Sloučení dat s relevantními funkcemi je právě to zapouzdření.

To je druhým významem termínu vedle izolace.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kiwi 08. 06. 2018, 13:24:28
Tudiz bych trval na tom, ze zapouzdreni neni to, co dela OOP.

Už jsem to psal - bez zapouzdření padá izolace problému v rámci objektu, takže už se nejedná o objekt.
Objekt je abstraktní pojem. Už jsem to tu psal - můžu mít fungující objektový systém, kde v objektech vůbec žádné funkce nejsou. Důležitý je mechanismus, který vybere správnou metodu pro konkrétně předhozený objekt. A je fuk, jestli mám přímo v objektu nějaké metody, které přímo korespondují s názvy zpráv, nebo ty metody vybírá nějaký dispečer na základě zpráv, nebo ty metody stojí úplně mimo objekty a jsou s nimi (nebo klidně s více objekty) svázány jen pomocí nějaké opět mimo stojící funkce, např. print, kdy print(obj) koukne, co to je za typ objektu, a když zjistí, že string, tak zavolá string_print(obj), když double, tak zavolá double_print(obj), když float, tak taky zavolá double_print(obj), protože ten doublí print umí vypisovat i float atp. "Zapouzdření" konkrétních metod s konkrétními daty se tu děje jen na abstraktní úrovni, žádná fyzická izolace se tu nekoná, přesto se dá v takovém prostředí pohodlně objektově programovat.

Na druhou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 08. 06. 2018, 13:50:41
ou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Proč bych, do pytle, ale měl chtít, aby si objekt něco kreativně domýšlel? Jakože třeba (zjednodušeně) namísto operátoru + zmáčknu jedničku, objektu dojde, že je to na klávesnici někde poblíž a tudíž jsem chtěl asi říct objektu, že se má sečíst s nějakým objektem, který jsem mu poslal coby parametr zprávy? Tohle mi celé přijde na hlavu, pan Alan Kay navrhnul Smalltalk podle mě z nouze tak, jak je, protože tenkrát neviděl možnost, jak udělat jazyk s typovým systémem, který by mu přišel OK. A další a další apologeti "čistých objektů" se rozplývají nad tím, jak je super, když si objekt může nějak poradit se zprávou, kterou nemá explicitně definovanou.

Sorry, nic osobního, ale fakt Ti tohle nepřijde uhozené?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 08. 06. 2018, 14:06:41
Na druhou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Zachycení špatné zprávy není problém. To jen špatně navržené jazyky si s tím neporadí.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Ondra Satai Nekola 08. 06. 2018, 14:16:39
Na druhou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Zachycení špatné zprávy není problém. To jen špatně navržené jazyky si s tím neporadí.

A objekt, co volal, se ma jit vycpat...
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Inkvizitor 08. 06. 2018, 14:23:53
Na druhou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Zachycení špatné zprávy není problém. To jen špatně navržené jazyky si s tím neporadí.

Zkus to prosím rozvést. Ne to se "špatně navrženými jazyky", ale proč bych to měl chtít a jak se takový chytrý objekt má typicky chovat.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: anonym 08. 06. 2018, 14:29:39
Na druhou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Zachycení špatné zprávy není problém. To jen špatně navržené jazyky si s tím neporadí.

Zkus to prosím rozvést. Ne to se "špatně navrženými jazyky", ale proč bych to měl chtít a jak se takový chytrý objekt má typicky chovat.

Dám ti radu, nepouštěj se do diskuze s Kitem.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kiwi 08. 06. 2018, 15:29:36
ou stranu můžu mít jazyk, který perfektně izoluje data od okolí a pevně spojuje metody s těmi daty, ale když bych náhodou zavolal špatnou metodu, tak neexistuje síla, jak takovou špatnou zprávu zachytit za běhu a vyrovnat se s ní nějak kreativně, než že mi už při kompilaci vyskočí error, konstruktor bude volán až po fyzickém vyrobení objektu a nebude moci vrátit jinou instanci nebo třeba úplně jiný objekt, atd. Takový jazyk by byl jen zkripleně objektový, třebaže dokonale zapouzdřuje.

Proč bych, do pytle, ale měl chtít, aby si objekt něco kreativně domýšlel? Jakože třeba (zjednodušeně) namísto operátoru + zmáčknu jedničku, objektu dojde, že je to na klávesnici někde poblíž a tudíž jsem chtěl asi říct objektu, že se má sečíst s nějakým objektem, který jsem mu poslal coby parametr zprávy? Tohle mi celé přijde na hlavu, pan Alan Kay navrhnul Smalltalk podle mě z nouze tak, jak je, protože tenkrát neviděl možnost, jak udělat jazyk s typovým systémem, který by mu přišel OK. A další a další apologeti "čistých objektů" se rozplývají nad tím, jak je super, když si objekt může nějak poradit se zprávou, kterou nemá explicitně definovanou.

Sorry, nic osobního, ale fakt Ti tohle nepřijde uhozené?
Pak je ale otázkou, co Ti z OOP zbyde, když dáš pryč věci, které Ti připadají uhozené. Chápal bych názor, že OOP je uhozené - když už. Ale OOP bez těch "uhozených" věcí mi připadá jen jako dost perverzní fetiš. To je pak něco naprosto k ničemu, jen obfuskátor strukturovaného návrhu (což je ovšem přesně to, s čím se většinou také setkávám - bohužel).

Proč by měl mít možnost objekt něco kreativně domýšlet? S těmi objekty se dá totiž dělat mnohem víc, než jen dědit a instanciovat, což mi připadá, že je taková průměrná představa o OOP u javistů a pluskařů. Dá se za běhu rozhodovat, který objekt bude nejvhodnější v dané situaci vrátit, dá se použít objekt, který vůbec nemusí být veřejně znám, dokonce ani jeho třída nemusí být veřejná. Dá se podstrčit objekt, který namísto objektu volajícím očekávaného třeba jen přesměrovává ty zprávy jinam, nebo je nějak filtruje. A to vše klidně dynamicky měnit za běhu. Dají se snadno vytvářet notifikační centra, observery, zástupné objekty - budoucí objekty, distribuované objekty, filtry, agenty, guardy, supervisory... Dají se tak snadno vyrábět třeba heterogenní kolekce, které samy přeposílají zprávy objektům, které obsahují, a vytvářet tak dynamicky komponované objekty - různé proxy apod. Je toho strašně moc, jak se taková volnost dá využít, přičemž lze jednoduše dosáhnout něčeho, co by se bez těchto možností dělalo jen dost komplikovaně a s hromadou kódu.

Já Ti nevím, ale mně to Tvoje "proč bych to měl chtít" připadá jak "proč by měl někdo chtít víc než 640 KB RAM".  ;)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Youda 08. 06. 2018, 16:00:24
Jak tady sleduju, co vsecho ne mozne vymyslet, kolik kol se da znovuvynalezt, jak se daji kreativne vykladat bezne terminy jako je napr. zapouzdreni - a to v kontextu bezne inzenyrske cinnosti jakou je objektova dekompozice.

Diskutujicim bych doporucil si precist alespon slajdy k uvodni prednasce
https://web.natur.cuni.cz/~bayertom/images/courses/Prog2/prog2_0.pdf

A taky doporucuju Allenovu povidku - Kdyby byli impresioniste dentisty
http://www.ceskaliteratura.cz/translat/allen.htm
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: anonym 08. 06. 2018, 17:26:01
Jak tady sleduju, co vsecho ne mozne vymyslet, kolik kol se da znovuvynalezt, jak se daji kreativne vykladat bezne terminy jako je napr. zapouzdreni - a to v kontextu bezne inzenyrske cinnosti jakou je objektova dekompozice.

Diskutujicim bych doporucil si precist alespon slajdy k uvodni prednasce
https://web.natur.cuni.cz/~bayertom/images/courses/Prog2/prog2_0.pdf

A taky doporucuju Allenovu povidku - Kdyby byli impresioniste dentisty
http://www.ceskaliteratura.cz/translat/allen.htm

CITUJI:

Modularita
Každý objekt lze udržovat a spravovat nezávisle na jiném objektu, aniž
by to nejak ovlivnilo celkovou funk ˇ cnost programu.  :D :D :D

Jak realizovat zapouzdˇrení:
1 Skrytí všech implementacní detail ˚u: ˇ
Veˇrejné tˇrídy nepoužívají veˇrejné atributy. <<< WTF :DDD

Objekty tvoˇrí instance techto datových typ˚u.ˇ
Jeden objekt nezávislý na druhém. NO TO URČITĚ :D :D :D

Cíl: Navržení tˇrídy Auto, která pˇredstavuje abstrakci skutecného automobilu. ˇ
Možná kritéria ovlivnující vlastnosti automobilut: hmotnost, okamžitá rychlost, ˇ
maximální rychlost, rok výroby, délka, stav.
Datové položky instance: hmotnost, o_rychlost, m_rychlost, rok_vyroby,
stav.
Chování automobilu je dáno vlastnostmi: zabrzdi, pˇridej plyn, jsi na opravu, jdi
do šrotu :-).
Metody instance: zabrzdi(), pridej(), oprava(), srot(). :D :D :D



Dál to raději nečtu, ale udělal jsi mi radost Youdo, protože vidím, že i na věhlasné ČVUT se učí úplně ty samé sračky, co zaručeně každého nového programátopra zmatou na hezkých pár let.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kiwi 08. 06. 2018, 17:29:18
Dál to raději nečtu, ale udělal jsi mi radost Youdo, protože vidím, že i na věhlasné ČVUT se učí úplně ty samé sračky, co zaručeně každého nového programátopra zmatou na hezkých pár let.
ČVUT?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: v 08. 06. 2018, 19:04:52
Já Ti nevím, ale mně to Tvoje "proč bych to měl chtít" připadá jak "proč by měl někdo chtít víc než 640 KB RAM".  ;)
nabízím alternativní pohled: mi, jako uživateli haskellu s velmi schopným typovým systémem, připadají dynamické jazyky jako 640kB paměti :)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 08. 06. 2018, 21:51:02
Já Ti nevím, ale mně to Tvoje "proč bych to měl chtít" připadá jak "proč by měl někdo chtít víc než 640 KB RAM".  ;)
nabízím alternativní pohled: mi, jako uživateli haskellu s velmi schopným typovým systémem, připadají dynamické jazyky jako 640kB paměti :)

Jediné, co mi na Haskellu vadí, že jsem ho dosud nezvládl. Možná ještě blbý zvyk psát šíleně dlouhé názvy funkcí, jako kdyby Haskell neměl namespaces. Jinak se mi ten jazyk líbí. XSLT mi také trvalo asi rok, než jsem ho vstřebal a teď na něj nedám dopustit. Zdravím Jirku Koska.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Ladislav Jech 09. 06. 2018, 13:44:26
1) Který jazyk je jednodušší zvládnout, aby člověk mohl být zaměstnán jakožto junior a rychleji?
JavaScript

2) Pokud bych chtěl dělat enterprise aplikace - je vhodnější java (EE) nebo .net?
JavaScript

3) S kterým jazykem lze jednodušeji se dostat do IT světa?
JavaScript

Opravdu nerad bych tu začínal flame, ale JavaScript není úplně nejjednodušší opravdu zvládnout. :) Ale jinak je to pěkný jazyk.

Ad 1) bych možná zvážil Python, ač ho dvakrát nemusím.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: uetoyo 09. 06. 2018, 20:04:28
Jak tady sleduju, co vsecho ne mozne vymyslet, kolik kol se da znovuvynalezt, jak se daji kreativne vykladat bezne terminy jako je napr. zapouzdreni - a to v kontextu bezne inzenyrske cinnosti jakou je objektova dekompozice.

Diskutujicim bych doporucil si precist alespon slajdy k uvodni prednasce
https://web.natur.cuni.cz/~bayertom/images/courses/Prog2/prog2_0.pdf
Tyto přednášky jste absolvoval?
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Fernet 09. 06. 2018, 20:22:30
Vím, že jsou si velmi podobné, ale jde mi o:
1) Který jazyk je jednodušší zvládnout, aby člověk mohl být zaměstnán jakožto junior a rychleji?
Python

2) Pokud bych chtěl dělat enterprise aplikace - je vhodnější java (EE) nebo .net?
Erlang/Elixir a OTP

3) S kterým jazykem lze jednodušeji se dostat do IT světa?
Python

Jediné, co mi na Haskellu vadí, že jsem ho dosud nezvládl. Možná ještě blbý zvyk psát šíleně dlouhé názvy funkcí, jako kdyby Haskell neměl namespaces. Jinak se mi ten jazyk líbí. XSLT mi také trvalo asi rok, než jsem ho vstřebal a teď na něj nedám dopustit. Zdravím Jirku Koska.

Naprosto tě chápu. Já měl brutální problém se switchem z OOP na FP (erlang/elixir). Elixir a OTP se mi už od začátku strašně líbili, ale cca půl roku mi trvalo, než jsem to vstřebal a přestal jsem psát imperativně. Teď když musím něco napsat v imperativním jazyku (C#), je to jako bych se škrábal pravou nohou za levým uchem. Díky bohu za F# :)

Haskell mám jako "guilty pleasure" a hraju si s ním ve volných chvílích, Teď čtu Real world Haskell a stále mě ten jazyk překvapuje.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 09. 06. 2018, 21:30:35
Jediné, co mi na Haskellu vadí, že jsem ho dosud nezvládl. Možná ještě blbý zvyk psát šíleně dlouhé názvy funkcí, jako kdyby Haskell neměl namespaces. Jinak se mi ten jazyk líbí. XSLT mi také trvalo asi rok, než jsem ho vstřebal a teď na něj nedám dopustit. Zdravím Jirku Koska.

Naprosto tě chápu. Já měl brutální problém se switchem z OOP na FP (erlang/elixir). Elixir a OTP se mi už od začátku strašně líbili, ale cca půl roku mi trvalo, než jsem to vstřebal a přestal jsem psát imperativně. Teď když musím něco napsat v imperativním jazyku (C#), je to jako bych se škrábal pravou nohou za levým uchem. Díky bohu za F# :)

Haskell mám jako "guilty pleasure" a hraju si s ním ve volných chvílích, Teď čtu Real world Haskell a stále mě ten jazyk překvapuje.

Díky za tip, ta kniha o Haskellu vypadá dobře. Je dobré ho znát, i když v něm třeba ani nebudeš programovat.
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Fernet 09. 06. 2018, 21:56:09

Díky za tip, ta kniha o Haskellu vypadá dobře. Je dobré ho znát, i když v něm třeba ani nebudeš programovat.

Jo, je super. Hlavně ukazuje, že i takový původně akademický jazyk, je použitelný v produkci a dá se v tom udělat cokoliv.
Ještě mám ve frontě https://www.yesodweb.com/book-1.6  To by pro tebe, jako PHPčkáře možná bylo ještě zajímavější.

Sranda je, že jsem se v devadesátých letech na FI MUNI smál Liboru Škarvadovi, který mj učil Funkcionální programování, že takovou blbost nikdy v praxi potřebovat nebudeme :)   A teď mě FP živí a trpím, když musím něco dělat v imperativních jazycích :)
Název: Re:Výběr vhodného OOP jazyka
Přispěvatel: Kit 09. 06. 2018, 22:58:37

Díky za tip, ta kniha o Haskellu vypadá dobře. Je dobré ho znát, i když v něm třeba ani nebudeš programovat.

Jo, je super. Hlavně ukazuje, že i takový původně akademický jazyk, je použitelný v produkci a dá se v tom udělat cokoliv.
Ještě mám ve frontě https://www.yesodweb.com/book-1.6  To by pro tebe, jako PHPčkáře možná bylo ještě zajímavější.

Sranda je, že jsem se v devadesátých letech na FI MUNI smál Liboru Škarvadovi, který mj učil Funkcionální programování, že takovou blbost nikdy v praxi potřebovat nebudeme :)   A teď mě FP živí a trpím, když musím něco dělat v imperativních jazycích :)

Tato kniha vypadá také dobře, podle obsahu bude i čtivá. Díky.