Příspěvky

271

Vývoj / Re:Investor pro C++ IDE

« kdy: 18. 09. 2021, 14:36:28 »

Smalltalk místo na typové kontroly vsadil na testy, které je mohou bez problémů nahradit. Typová kontrola je dnes už i v PHP v takové míře, která vývojářům vyhovuje. Tzn. že není vyžadována, ale je podporována.

Tak ale testy ti neohalia fakt ze scitas jablka a hrusky, ak jablka a hrusky su odvodene od integer. Jedine ze by si si definoval operator ktory ti pri scitani typu jablka a typu hrusky, vratil typ malvice. Toto ti moze odhalit len prekladac.

Jak tedy C++ rozliší mezi jablky a hruškami, pokud jsou odvozeny od int? Zabrání jejich sečtení?

myslis nieco taketo?

Kód: [Vybrat]

#include <iostream>
using namespace std;

typedef int apple;
typedef int pear;

int main() {
   apple a1 = 10;
   pear p1 = 20;
   int n = a1 + p1;
   cout << "Result : " << n << endl;
   return 0;
}

ani len pri tom nezanadava. Typovo silny jazyk by ti vynadal ze nepozna operator scitania pre apple a pear...

Ako tento nedostatok jazyka zachranis testami?

v dynamickem jazyku ten kod spadne, pokud ho spustis

Což dokazuje co?

ze to na to prijdes pri testu

Ale ty testy musím napsat, že? A musím je napsat správně, že?

272

Vývoj / Re:Investor pro C++ IDE

« kdy: 18. 09. 2021, 02:47:42 »

Smalltalk místo na typové kontroly vsadil na testy, které je mohou bez problémů nahradit. Typová kontrola je dnes už i v PHP v takové míře, která vývojářům vyhovuje. Tzn. že není vyžadována, ale je podporována.

Tak ale testy ti neohalia fakt ze scitas jablka a hrusky, ak jablka a hrusky su odvodene od integer. Jedine ze by si si definoval operator ktory ti pri scitani typu jablka a typu hrusky, vratil typ malvice. Toto ti moze odhalit len prekladac.

Jak tedy C++ rozliší mezi jablky a hruškami, pokud jsou odvozeny od int? Zabrání jejich sečtení?

myslis nieco taketo?

Kód: [Vybrat]

#include <iostream>
using namespace std;

typedef int apple;
typedef int pear;

int main() {
   apple a1 = 10;
   pear p1 = 20;
   int n = a1 + p1;
   cout << "Result : " << n << endl;
   return 0;
}

ani len pri tom nezanadava. Typovo silny jazyk by ti vynadal ze nepozna operator scitania pre apple a pear...

Ako tento nedostatok jazyka zachranis testami?

v dynamickem jazyku ten kod spadne, pokud ho spustis

Což dokazuje co?

273

Vývoj / Re:Investor pro C++ IDE

« kdy: 17. 09. 2021, 23:59:32 »

místo na typové kontroly vsadil na testy, které je mohou bez problémů nahradit.

Toto je nepravda. Milý čtenáři tohoto příspěvku, doporučoval bych ti si toto tvrzení ověřit.

274

Vývoj / Re:Investor pro C++ IDE

« kdy: 17. 09. 2021, 21:24:24 »

V každém netriviálním programu je chyba. To je axiom.

Geniální mozky jako je např. D. Knuth těch chyb dělají velmi málo (nějaké ty šeky za chyby v TeX snad ale nakonec vypsat musel).

Běžní smrtelníci omyly dělají běžně. Ti ješitnější si to nepřipouštějí a ti pragmatičtější hledají nástroje, jak minimalizovat (jimi způsobené) škody.

Součástí toho toolsetu je jednoduchý a bezpečný jazyk a k tomu IDE nebo tooly na analýzu kódu (nejlépe současně integrované v tom IDE), které pomáhají zabít bugy v zárodku. Plus jim jít naprosti určitou disciplínou, "štábní kulturou" a nesnažit se být moc chytrý (méně je někdy více, příliš rafinovaném kódu nerozumí analyzátor v IDE, kolega ani já po roce).

Kdo nezažil situaci, kdy jde do práce nevyspalý (protože třeba malé dítě v noci trápila rýma), nemá prostě "svůj den", pracuje v prostředí, které není stopro ideální z pohledu focusu a do toho ještě šéf ječí s termínem, ať se přihlásí. Samozřejmě vystupujeme jako profíci a snažíme se odvádět kvalitní práci a ty chyby nedělat. Ale proklamace typu "já ve svém kódu prostě chyby nikdy nemám" jsou úsměvné a z mé zkušnosti i o dotyčném něco vypovídají.

Moc pěkně popsáno. Souhlas.

275

Vývoj / Re:Investor pro C++ IDE

« kdy: 16. 09. 2021, 15:10:57 »

Rozdíl je v tom, jestli to je fakt integrované (konzistentní) nebo nějak poslepované. Když se řekne IDE, představuju si, že se nad tím někdo zamyslel, dá se to snadno ovládat (GUI nebo TUI), jednotlivé komponenty se nastavují v menu "Preferences" pomocí nějakého klikání a ne editací JSONu nebo obskurního skriptovacího jazyka.

Je vidět, že každý máme nějakou představu

Technicky vzato, v dobách DOSu bylo IDE přirozená věc, protože bylo jenom jedno okno.

Dneska už jsou ty požadavky trochu jinde. Kromě subjektivních pocitů - lépe se mi dělá v jednom prostředí, které je promyšlené, provázané, etc. Tak další požadavek je, aby ten nástroj rozuměl tomu kódu, uměl mi našeptávat, ukazovat chyby, usnadnil vytváření nových funkcí, metod, tříd, správu všech závislostí a tak. Což někdy tak úplně roztříštit do více aplikací není jednoduché.

Někdo fakt potřebuje našeptávání. Někdo fakt potřebuje, aby to byla jedna aplikace. A je ochoten za to zaplatit jinde, třeba v tom, že to načítá pomalu, že je to nekonzistentní.
Někdo ne.
IMHO je to styl.

276

Vývoj / Re:Investor pro C++ IDE

« kdy: 16. 09. 2021, 14:54:16 »

Ja stejne porad nerozumim tomu co je to IDE.
Kdyz si do Vimu "naintegruju" dost pluginu na vyvoj v konkretnim jazyce tak uz je to IDE nebo je to porad jen obycejny editor?

A Kdyz si v IDEA odinstaluju pluginy pro VCS a build tools... je to jeste IDE nebo uz jen editor?

Nebo je to o tom v jakem stavu to je kdyz to poprve nainstaluju?

Integrated Development Environment - představím si TurboPascal od Borlandu. To znamená editor se zvýrazněním kódu, správa projektu, spuštění a překlad projektu, případně debuger (dneska tam bude ještě správa závislostí, verzování,...). Tedy jak to chápu, IDE je, když nemusím (moc) opouštět to prostředí, abych spustil nějakou akci jinde. Všechno, nebo alespoň většinu toho dělám z něj.

V protikladu, jak to třeba dělám já, že mám editor s otevřenými soubory projektu, vedle správce souborů, vedle konzoly s gitem, vedle Meld pro porovnávání rozdílů, vedle Gitg pro prohlížení git historie, prohlížeč s dokumentací, ... a tak. Na všechno spešl samostatnou aplikaci.

OK pak tvoje IDE je window manager a/nebo operacni system....

S tím bych souhlasil. Ale viz dále:

Nebo lepe... pojem IDE je jen marketingovy nesmysl... jde jen o to, jestli se rozhodnu pouzit nejaky prepripraveny balicek nebo jestli si to "integruju" sam.

Asi bych nebyl tak ostrej a netvrdil, že je to marketingový nesmysl. Když někdo řekne, "hele používám Foo, je to IDE", tak si pod tím představím že spustí nějakou tu aplikaci Foo, a pak v ní dělá všechno. Takže svůj účel to plní.

277

Vývoj / Re:Investor pro C++ IDE

« kdy: 16. 09. 2021, 13:47:38 »

Ja stejne porad nerozumim tomu co je to IDE.
Kdyz si do Vimu "naintegruju" dost pluginu na vyvoj v konkretnim jazyce tak uz je to IDE nebo je to porad jen obycejny editor?

A Kdyz si v IDEA odinstaluju pluginy pro VCS a build tools... je to jeste IDE nebo uz jen editor?

Nebo je to o tom v jakem stavu to je kdyz to poprve nainstaluju?

Integrated Development Environment - představím si TurboPascal od Borlandu. To znamená editor se zvýrazněním kódu, správa projektu, spuštění a překlad projektu, případně debuger (dneska tam bude ještě správa závislostí, verzování,...). Tedy jak to chápu, IDE je, když nemusím (moc) opouštět to prostředí, abych spustil nějakou akci jinde. Všechno, nebo alespoň většinu toho dělám z něj.

V protikladu, jak to třeba dělám já, že mám editor s otevřenými soubory projektu, vedle správce souborů, vedle konzoly s gitem, vedle Meld pro porovnávání rozdílů, vedle Gitg pro prohlížení git historie, prohlížeč s dokumentací, ... a tak. Na všechno spešl samostatnou aplikaci.

278

Vývoj / Re:Investor pro C++ IDE

« kdy: 16. 09. 2021, 01:16:45 »

Rust? Dakujem, nechcem. Skuste si ked tak otvorit binarku co stvoril, v cutter alebo inom nastroji pre reverse enginering... Ak clovek vie v assembleri, tak by z toho grcal. Go z tohoto pohladu este horsie. Len pre to ze sa v ruste nauci pisat hocijaka lopata, podobne ako v c++, tak ho nemusim pouzivat tiez.

Brečíš na nesprávné mohyle, Rust používá LLVM. Jinak Rust má zrovna tu vlastnost, že "hocijaká lopata" s bídou přeloží "Hello, world" a pak už ji překladač spolehlivě odfiltruje, takže i kdybys nakrásně chtěl, Rust není pro tebe.

To neděláš dobře Vladimíre..., s tím krmením.

279

Server / Re:Laravel chyba 403

« kdy: 16. 09. 2021, 01:12:49 »

Localhost má localhost dtb, nemohu propojit webovou dtb s aplikací na localhostu.

Tak teoreticky tomu nic nebrání, pokud je ten webhosting soudný, ale ok.

Dobrý den,
mám CRM aplikaci v Laravelu, kde řeším problém s oprávněním. Pokud chci editovat nějaký záznam (např. název klienta), vyskočí mi hláška o tom, že nemám oprávnění (což se =chybě 403). Zkontroloval jsem .htaccess, ten je v pořádku.

Vyzkoušeno na localhostu, tam funguje korektně. Napadá vás co ještě ověřit? Mohu mít něco blokované na straně webhostingu?

Možná bych jenom zdůraznil, že ta chyba vůbec nemusí být v hostingu, nebo .htaccess. Je docela dost možné, že vám ta CRM aplikace tou 403 hlásí, že nemáte oprávnění v rámci té aplikace. Tudiž si ověřit, zda máte všechno správně nastavené, přiřazená práva a tak - v té aplikaci.

Co třeba udělat si dump sql na hostingu a dump na lokále a porovnat? Pokud to není moc dat, tak v zoufalství to může být řešení :-)

280

Vývoj / Re:Investor pro C++ IDE

« kdy: 15. 09. 2021, 17:25:10 »

[Ten kdo brojil proti offtopic sám se ho dopouští 

Zpátky ale k IDE. Psal jsi, že děláš mimo jiné jazyky ML, Lua, Haskell. Používáš k tomu něco jako IDE, pokud ano, tak proč a pokud ne, tak proč ne?

Spíše nepoužívám.

U C# na Windows používám MSVS. Na jednom projektu v Javě jsem používal Eclipse, protože to mělo předpřipravený plugin pro ten projekt (Wowza), který mi nestál za námahu obcházet. Občas nějaké to IDE zkusím, abych si to ošahal.
V drtivé většině případů ale používám Geany (Haskell, Lua, ...).

Důvod je v tom, že jsem nerváček a děsně mě rozčiluje jak jsou ta IDE rozvážná. To, že než se nějaká činnost provede trvá, to by mi ani tak nevadilo. Ale hodně mě vadí lagování. Konkrétní příklad:
V VS, které je u mě na hraně použitelnosti dám Ctrl+Space pro zobrazení voleb refactoringu. Očekávám, že to menu se mi otevře okamžitě. Když zvolím nějakou volbu, třeba oprava toho a toho, tak pak ať to klidně pár vteřin chroupe.
Ve skutečnosti ta klávesová zkratka, ta ještě jde. Ale použít myšítko je tak zdlouhavé.
Další věc které mě rozčilují, že otevření souboru, vyhledávání souboru, a podobně trvá strašný věky.

Pro mě je to tak nervy ničící věc, že si všechny ty věci raději držím v hlavě, a programuju jenom s lehkým editorem, který ale vyhledává rychle, soubory otevírá rychle a vůbec. Musím sice obětovat nějaké ty pokročilejší funkce IDE, ale kromě C# a Javy mě to zas tak moc nebolí. Obejdu se bez toho.

281

Vývoj / Re:Investor pro C++ IDE

« kdy: 14. 09. 2021, 21:02:47 »

pro ignoranty (BoneFlute, Death Walker), cely webovy framework postaveny nad pydanticem https://fastapi.tiangolo.com/ . Z otypovanych entit se generuje JSON schema validace a databazove modely.

A na klientovi opises tu schemu do anotacii, tak to mas 3x... to je tak ked sa pouziva format pre serializaciu javascript objektov ako format pre prenos dat... este stastie ze k tomu  nikoho nenapadlo pouzit pickle...

Jak by to melo vypadat, abyste to mel jen JEDNOU? Z tech anotaci generujete JSON schema.

Jak server tak klient by mal respektovat schema ktore je definovane. Pretoze ak sa meni schema podla toho ako si niekto patla anotacie, je na vrazdu. Teda ak niekto tu api pouziva.

Swagger a podobne vifikundacie sa ako schema sice tvaria, ale je to asi ako pouzivat json na prenos dat, nejako to funguje ale inak nic moc.

Soap napriklad ma schemu definovanu presne, vratane validacnych obmedzeni, anotacii, dokumentacie... teda ak tu schemu programator dokaze napisat. Potom uz len staci generovat mapovanie elementov na objekty a funguje to same (vacsina jazykov pre soap linkuje c kniznicu).  Toto je DRY, pretoze tu deklaraciu napisete len raz.

Akurat ze sa tu schemu treba naucit napisat a nie to generovat.

Muzete tu webarinu presunout do jineho vlakna? Dik.

Sme moc hlucny a rusime ta? Staci zavriet okno.

To ze sa nieco prenasa cez internet, tak to este nemusi byt o webe.

Vlastne ak ti webarina tak vadi, preco vlastne lezies na web?

Ten kdo brojil proti offtopic sám se ho dopouští 

282

Vývoj / Re:Investor pro C++ IDE

« kdy: 14. 09. 2021, 00:14:13 »

Takhle to u typovaných jazyků nefunguje. Nech to bejt.

pokud typove informace zahodite pri kompilaci, nemuze to fungovat. Pokud je zachovate a umoznite jejich cteni v case behu, lze je vyuzit.

Když myslíš.

283

Vývoj / Re:Investor pro C++ IDE

« kdy: 13. 09. 2021, 23:53:15 »

V runtime žádné typy nepotřebuju

urcite lze informace o typech vyuzit i v runtime, treba pro ruzne validace vstupnich dat. Priklad z Pythonu https://pydantic-docs.helpmanual.io/ ,

Takhle to u typovaných jazyků nefunguje. Nech to bejt.

284

Vývoj / Re:Investor pro C++ IDE

« kdy: 13. 09. 2021, 22:14:56 »

Já ho třeba používám protože implementace Amulet (https://amulet.works/) je podobná Haskellu, umí nějaké ty zajímavé featury a kompiluje mi to do Lui. Žádná další zvláštní motivace v tom není.

Kompilace do Luy? Proč? Zrovna Lua mi pro tenhle účel přijde extrémně nevhodná. A s dokumentací na stránkách toho jazyka je to takové nijaké.

Asi nerozumím tvému příspěvku. Extrémně nevhodná na co?

Jako cílový jazyk kompilace. Síla Luy je IMO v tom, že je to jednoduchoučký jazyk s malinkým runtimem který se dá jednoduše embednout kamkoliv. Přijde mi trochu zvláštní mít mocný typový systém a v runtime všechny tyhle informace zahodit a všechno to nasypat do jedné univerzální hashmapy. To už by mi přišlo rozumnější, aby si Amulet zrovna interpretoval svůj AST než tohle.
Tohle kombinuje nevýhody z obou světů. Pro kompilaci potřebuje mocnou parní mlátičku a v runtime platí za nevyužitou flexibility Luy.

Obávám se, že je to přesně naopak.

V runtime žádné typy nepotřebuju, snad tam ani žádné nejsou (dobře, to není tak docela pravda, ale to je fuk). Mocný typový systém potřebuju jen na začátku, při překladu. Pak už jej prakticky nevyužiju - maximálně se mi tam hodí typy jako tagy při nějakém switchi, což je přesně to co ten Amulet dělá. V runtime se mi naopak hodí to, že tam není žádné zbytečné smetí a může optimalizovat po svém (LuaJIT etc, i když to jsem ještě nezkoušel).

Asi jsem se vyjádřil špatně, protože jste mě pochopil úplně opačně, než jsem to myslel.

U staticky typovaného jazyka můžete typy zahodit, jen nechat data v paměti a přistupuje k nim kód vygenerovaný na základě typů. A to přesně v dynamicky typované lue moc nejde. Tam musíte jednu každou položku separátně alokovat jako boxovanou dvojici typ + hodnota a celé to nasypat do hierarchie hashmap. Takže v runtime máte hromady zbytečných typových informací.

Tak nemusíte. Když nikde v cestě není žádný switch, tak není nutné tam ty typy uchovávat, a taky se tam neuchovávají.

Druhak, já používám Amulet nikoliv proto, že je to tak výborný jazyk, ale proto, že mi to z jazyka se silnými typy kompiluje do Lui. Původně jsem zkoušel TypeScript (do Lui), ale to zlobilo a nedal jsem tomu druhou šanci.

V runtime žádné typy nepotřebuju

Někdy se hodí vědět o typových parametrech. Viz třeba Java vs. Go, Java je všechny zahodí.

Tak určitě. Ale jednak v Javě ta motivace je prej dost jinak, protože VM těm typům nevěří. A druhak ty typy potřebuješ vědět jen někdy a u typovaného jazyka víš kdy.

285

Vývoj / Re:Investor pro C++ IDE

« kdy: 13. 09. 2021, 16:01:22 »

Já ho třeba používám protože implementace Amulet (https://amulet.works/) je podobná Haskellu, umí nějaké ty zajímavé featury a kompiluje mi to do Lui. Žádná další zvláštní motivace v tom není.

Kompilace do Luy? Proč? Zrovna Lua mi pro tenhle účel přijde extrémně nevhodná. A s dokumentací na stránkách toho jazyka je to takové nijaké.

Asi nerozumím tvému příspěvku. Extrémně nevhodná na co?

Jako cílový jazyk kompilace. Síla Luy je IMO v tom, že je to jednoduchoučký jazyk s malinkým runtimem který se dá jednoduše embednout kamkoliv. Přijde mi trochu zvláštní mít mocný typový systém a v runtime všechny tyhle informace zahodit a všechno to nasypat do jedné univerzální hashmapy. To už by mi přišlo rozumnější, aby si Amulet zrovna interpretoval svůj AST než tohle.
Tohle kombinuje nevýhody z obou světů. Pro kompilaci potřebuje mocnou parní mlátičku a v runtime platí za nevyužitou flexibility Luy.

Obávám se, že je to přesně naopak.

V runtime žádné typy nepotřebuju, snad tam ani žádné nejsou (dobře, to není tak docela pravda, ale to je fuk). Mocný typový systém potřebuju jen na začátku, při překladu. Pak už jej prakticky nevyužiju - maximálně se mi tam hodí typy jako tagy při nějakém switchi, což je přesně to co ten Amulet dělá. V runtime se mi naopak hodí to, že tam není žádné zbytečné smetí a může optimalizovat po svém (LuaJIT etc, i když to jsem ještě nezkoušel).

Ale to není úplně Ocaml, ne?

Ne? Já bych řekl že jo. Ale i kdybych se mýlil, tak co? 

Kdyby ses mýlil, tak bys nedával přímou odpověď na otázku, kterou jsem položil. Pokud si vzpomínám, tak Ocaml má poměrně mnoho jazykových vlastností (OOP, moduly a functory...), které "A simple, functional programming language in the ML tradition" (Amulet) mít všechny nebude. Tudíž beru, že používáš "nějaký jazyk z rodiny ML", akorát to holt asi není to samé co Ocaml.

Ok, přesvědčili jste mě, není to OCaml. Ale opravdu je mi to jedno. Já vlastně původně jen nechtěl vytahovat, že používám zrovna takovou obskurní věc, a tak jsem to zařadil do nejbližší kategorie která mě napadla. Netrefil jsem se. Přiznávám vinu v plném rozsahu.