Investor pro C++ IDE

[BoneFlute]

Linter odhali stejny typ chyb jako kompiler.

Odvážné tvrzení. Ale budiž, nebudem se o tom přít.

[Reklama]

[Google CTCCTCGGCGGGCACGTAG]

Linter odhali stejny typ chyb jako kompiler.

Odvážné tvrzení. Ale budiž, nebudem se o tom přít.

Nemuzes normalne priznat, ze ma druha strana pravdu?

[BoneFlute]

Linter odhali stejny typ chyb jako kompiler.

Odvážné tvrzení. Ale budiž, nebudem se o tom přít.

Nemuzes normalne priznat, ze ma druha strana pravdu?

Kdo mě zná tak ví, že nemám problém přiznat, že má druhá strana pravdu. Ale má to pár podmínek:
- musí přinést do diskuse něco nového, zajímavého, užitečného
- musí dokázat, že má pravdu, nebo alespoň dokázat, že to co říká je zajímavé
- musí předvést, že tomu rozumí, alespoň trochu
- abych přiznal že se mýlím (není problém) musí dokazovat něco, co jsem tvrdil

Co z toho je tvůj případ?

Pokud se do těchto podmínek nevejdeš, nebudu se obtěžovat na tebe reagovat bez ohledu na to, jak vychytralé psychologické triky na mě budeš zkoušet. Děkuji za pozornost a sbohem.

[Death Walker]

konkretne u toho scitani, ktere je v prikladu, pokud ta operace dela neco s cisly (hadam ze scita), ruzne out of range chyby bezny kompiler neodhali, vetsinou je jednodussi napsat testy na ruzne krajni pripady

Ak ma jazyk dostatocne prostriedky, tak je jednoduchsie tie prostriedky vyuzit a dodat prekladacu dostatok informacii o scitanych typoch a o type do ktoreho bude priradeny vysledok.

Inak povedane, nie je dobre znasilnovat jazyk k comu nie je urceny a zacharanovat to testami. Ludia su nevrly uz ked musia pisat funkcne testy, ak im k testom ohladne zadania pridas este testy ktore budu zachranovat slabu typovu kontrolu, tak o to viac na to budu kaslat.

[Death Walker]

Linter odhali stejny typ chyb jako kompiler.

Odvážné tvrzení. Ale budiž, nebudem se o tom přít.

Ak by linter odhalil rovnaky typ chyb ako kompiler, tak by bol tak trocha zbytocny, nie?

[Reklama]

[BoneFlute]

Testy dělají to, co typy nesvedou. Typy obvykle nezabrání abych do proměnné měsíc nevložil hodnotu 14, aby se do indexu nedostala hodnota mimo rozsah pole.

Na to jsou enumy a závislostní typy. Důležité jsou typy i testy, vzájemně se doplňují a pokrývají jiná rizika (typy symbolicky, testy ošetřením typických případů).

To s tím indexem mě zaujalo. Zkusil jsem se zamyslet, a uvažovat jak by se dal řešit nějaký jednoduchý příklad s kolekcí.

Postavil jsem to na jednom reálném zadání z práce:

U položky evidujeme 0, 1 nebo 2 záznamy, přičemž buď může být jeden záznam draft, nebo jeden accepted, nebo jeden draft a jeden accepted. Budeme to řešit jako kolekci/pole.

Takže celkem přímočaře si z toho udělám čtyři varianty (pseudokód):

Kód: [Vybrat]

type State = Draft | Accepted

type Choices
= []
| [(State)]
| [(Draft), (Accepted)]

-- Funkce pro přidání:
add :: Choices -> State -> Choices
add xs@[] x = [x]
add xs@[Draft] x@Accepted = [xs : x]
add xs@[Accepted] x@Draft = [xs : x]

Je to trochu humpolácky napsané, příklad je ne úplně reprezentativní, ale berme to jako výhodu.

V podobném duchu si dokážu snadno představit třeba pole o maximální velikosti 42 prvků. Ale už by to asi chtělo nějaký cukr, nebo něco, aby to bylo příjemné.

[BoneFlute]

Linter odhali stejny typ chyb jako kompiler.

Odvážné tvrzení. Ale budiž, nebudem se o tom přít.

Ak by linter odhalil rovnaky typ chyb ako kompiler, tak by bol tak trocha zbytocny, nie?

Zásadní rozdíl mezi linterem a kompilerem (staticky typovaného jazyka) je v tom, že linter lze nepoužít. (Plus je tam ta historická souvislost, že linter se používá na jazyky, které nebyly navrženy se statickými typy - Python, JS například.)

[Google CTCCTCGGCGGGCACGTAG]

Linter odhali stejny typ chyb jako kompiler.

Odvážné tvrzení. Ale budiž, nebudem se o tom přít.

Ak by linter odhalil rovnaky typ chyb ako kompiler, tak by bol tak trocha zbytocny, nie?

protoze obracene to neplati, linter (zalezi na linteru) casto odhali vic chyb. priklad hlint a ghc. navic linter negeneruje binarku, tak bezi mnohem rychleji, IDE ho muze spoustet na pozadi.

[Google CTCCTCGGCGGGCACGTAG]

Linter odhali stejny typ chyb jako kompiler.

Odvážné tvrzení. Ale budiž, nebudem se o tom přít.

Ak by linter odhalil rovnaky typ chyb ako kompiler, tak by bol tak trocha zbytocny, nie?

Zásadní rozdíl mezi linterem a kompilerem (staticky typovaného jazyka) je v tom, že linter lze nepoužít. (Plus je tam ta historická souvislost, že linter se používá na jazyky, které nebyly navrženy se statickými typy - Python, JS například.)

otazka nastaveni CI.

[Death Walker]

Linter odhali stejny typ chyb jako kompiler.

Odvážné tvrzení. Ale budiž, nebudem se o tom přít.

Ak by linter odhalil rovnaky typ chyb ako kompiler, tak by bol tak trocha zbytocny, nie?

protoze obracene to neplati, linter (zalezi na linteru) casto odhali vic chyb. priklad hlint a ghc. navic linter negeneruje binarku, tak bezi mnohem rychleji, IDE ho muze spoustet na pozadi.

To ze mnozina uloh ktore vykonava linter sa ciastocne prekryva s mnozinou uloh ktore vykonava kompilator, neznamena ze linter odhali rovnaky typ chyb ako kompilator.

Linter sa skor pouziva na staticku analyzu kodu. Stylisticke chyby, programatorske chyby (ako napr. funkcia bez return)...
Ale co sa tyka typovej kontroly, tak k ma dispozicii len tie informacie ako kompilator. Cize ak je linter urceny pre dynamicky jazyk, tak nema podla coho vykonat typovu kontrolu. V tom zdrojaku proste nenajde potrebne informacie.

[Idris]

Linter odhali stejny typ chyb jako kompiler.

Odvážné tvrzení. Ale budiž, nebudem se o tom přít.

Pokud jde o typovou kontrolu, tak existují algoritmy, které u “dynamicky” typovaného jazyka doplní typy. Ovšem příslušný type checker musí podporovat generické typy včetně unifikace, aby eliminoval false negatives (hlášení typové chyby u korektního kódu).

Ten algoritmus musí ale pochopitelně mít přístup ke zdrojákům všech použitých knihoven, a pokud existují zabudované typy nebo funkce, musí k nim být typová informace.

[Idris]

Linter odhali stejny typ chyb jako kompiler.

Odvážné tvrzení. Ale budiž, nebudem se o tom přít.

Ak by linter odhalil rovnaky typ chyb ako kompiler, tak by bol tak trocha zbytocny, nie?

Zásadní rozdíl mezi linterem a kompilerem (staticky typovaného jazyka) je v tom, že linter lze nepoužít. (Plus je tam ta historická souvislost, že linter se používá na jazyky, které nebyly navrženy se statickými typy - Python, JS například.)

Původní linter vznikl pro C

[Idris]

Testy dělají to, co typy nesvedou. Typy obvykle nezabrání abych do proměnné měsíc nevložil hodnotu 14, aby se do indexu nedostala hodnota mimo rozsah pole.

Na to jsou enumy a závislostní typy. Důležité jsou typy i testy, vzájemně se doplňují a pokrývají jiná rizika (typy symbolicky, testy ošetřením typických případů).

To s tím indexem mě zaujalo. Zkusil jsem se zamyslet, a uvažovat jak by se dal řešit nějaký jednoduchý příklad s kolekcí.

Postavil jsem to na jednom reálném zadání z práce:

U položky evidujeme 0, 1 nebo 2 záznamy, přičemž buď může být jeden záznam draft, nebo jeden accepted, nebo jeden draft a jeden accepted. Budeme to řešit jako kolekci/pole.

Takže celkem přímočaře si z toho udělám čtyři varianty (pseudokód):

Kód: [Vybrat]

type State = Draft | Accepted

type Choices
= []
| [(State)]
| [(Draft), (Accepted)]

-- Funkce pro přidání:
add :: Choices -> State -> Choices
add xs@[] x = [x]
add xs@[Draft] x@Accepted = [xs : x]
add xs@[Accepted] x@Draft = [xs : x]

Je to trochu humpolácky napsané, příklad je ne úplně reprezentativní, ale berme to jako výhodu.

V podobném duchu si dokážu snadno představit třeba pole o maximální velikosti 42 prvků. Ale už by to asi chtělo nějaký cukr, nebo něco, aby to bylo příjemné.

Zajímavý příklad. U takovýchto zadání je vždy otázka, co ještě řešit v době překladu. Někdy je lepší nechat kontrolu na runtime, než učit juniory závislostní typy.

[jano6]

A ty sedáváš při čem? Kromě ohně na salaši teda...

Keď si prídete k nám hôrnym chlapcom dať kus žinčice, tak si nezabudnite do svojich
sandálov dať hrubé ponožky. Tunáka sú podmienky drsnejšie.

Kód: [Vybrat]

type Month is range 1 .. 12;

Práca s dátumami a časom je jedna z najzaujímavejších sfér. Etiópsky kalendár používa
13 mesiacov; jeden indický má 13 mesiacov každé tri roky.

[Ink]

Zásadní rozdíl mezi linterem a kompilerem (staticky typovaného jazyka) je v tom, že linter lze nepoužít. (Plus je tam ta historická souvislost, že linter se používá na jazyky, které nebyly navrženy se statickými typy - Python, JS například.)

Původní linter vznikl pro C

C bylo z hlediska typů dost děravé - raw pointery, implicitní konverze, neexistence booleovského typu, pak spousta nástražných min typu i++ a ++i, příkaz switch, který si přímo koleduje o průšvih, docela dost důvodů kód hlídat na tak malý jazyk.