Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: vyvojar 15. 01. 2016, 19:09:17
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
-
nemá a IMHO ne, nezajímá (nemám dojem, že by vedle visual cpp, qt creator a eclipse bylo moc místa)
-
Vedle LagClipsu je spousta místa. Ale naštěstí je mnoho lepších alternativ.
-
Myslim, ze bohuzel zajimat nebude. Orestoze na trhu podle mne misto je. Pro c++ je z IDE funkcni pouze qt creator a visual studio(nejspis, co jsem testoval, tak umelo, ale provadel jsem jen zakladni testy). Qt creator c++ zvlada (s liblacngim complete), ale prijde mi oproti ostatnim ide dost nezvykly a navic mam pocit ze taky moc nepodporuje zakladni funkce jako refaktoring(hlavu bych za to ale nedal). Tim chci rict ze misto na trhu 100% je, ale musel bys to udelat lepe, nez to co je dnes(polofunkcnich bazmeku je plna zadek) a to je podle mne na hodne dlouhe lokty.
-
Neviem, ci je rozumne nechat si radit od odbornikov, ktori tvrdia, ze visual studio "nejspis" funguje.
-
Neviem, ci je rozumne nechat si radit od odbornikov, ktori tvrdia, ze visual studio "nejspis" funguje.
Ja jsem rekl svuj nazor. K tematu. Tys nevyblil nic.
-
Zajímavou ale velmi riskantní by možná byla investice do C++ IDE které nějakým způsobem kombinuje C++ a Emscripten (http://kripken.github.io/emscripten-site/). Emscripten umožňuje překlad C++ do JavaScriptu pomocí LLVM. Takové IDE by muselo nějakým způsobem integrovat webový prohlížeč a umožnit i kvalitní debugování výsledného JavaScriptu (source mapy či něco navíc?...). To by mohlo být zajímavé, protože to nikdo nemá a v současné době je už určitý ruch kolem "compiles to javascript" jazyků a je potenciál že z toho bude i trend.
-
Neviem, ci je rozumne nechat si radit od odbornikov, ktori tvrdia, ze visual studio "nejspis" funguje.
Ja jsem rekl svuj nazor. K tematu. Tys nevyblil nic.
Naopak. V priamej nadvaznosti na temu a vyjadreny nazor som vyjadril relevatnu pochybnost o tom, ci ma predchadzajuci prispievatel dostatocne skusenosti a prehlad o vyvojovych prostrediach, co ma urcite vlyv na doveryhodnost rady.
-
Kazdeho investora bude asi zaujimat nieco ako prieskum trhu, aka je sucastna situacia a preco by si ludia kupovali tvoj produkt.
C++ ide su visualstudio, netbeans, eclipse, clion, qtcreator, ta apple vec, codeblocks, ultimate++ ide a mnoho dalsich. Tak prajem vela stastia..
-
Šanci na investici samozřejmě má, protože i investoři se často chovají iracionálně.
Jestli to ale má smysl je dost sporné. V bude tvoje IDE lepší než Netbeans, Eclipse a Qt Creator? Je to natolik významná výhoda, aby se vyplatilo psát nové IDE místo vylepšování některého ze stávajících nebo napsání zásuvného modulu do něj?
-
Šanci na investici samozřejmě má, protože i investoři se často chovají iracionálně.
Jestli to ale má smysl je dost sporné. V bude tvoje IDE lepší než Netbeans, Eclipse a Qt Creator? Je to natolik významná výhoda, aby se vyplatilo psát nové IDE místo vylepšování některého ze stávajících nebo napsání zásuvného modulu do něj?
Oprava: V čem bude tvoje IDE lepší…
-
Kazdeho investora bude asi zaujimat nieco ako prieskum trhu, aka je sucastna situacia a preco by si ludia kupovali tvoj produkt.
C++ ide su visualstudio, netbeans, eclipse, clion, qtcreator, ta apple vec, codeblocks, ultimate++ ide a mnoho dalsich. Tak prajem vela stastia..
Krome QT creatru a mozna Visual Studia ty ostatni jmenovane IDE c++ nepodporuji. Ne u vetsiny funkci ktere by si clovek u IDE predstavoval. Nerozumi c++, jen se to snazi nejak ofejkovat. S novejsim c++ je to ale hodne spatne a ty jejich parsery to delaji spatne. Neda se to rozumne pouzivat na novejsi c++ kod.
-
Šanci na investici samozřejmě má, protože i investoři se často chovají iracionálně.
Jestli to ale má smysl je dost sporné. V bude tvoje IDE lepší než Netbeans, Eclipse a Qt Creator? Je to natolik významná výhoda, aby se vyplatilo psát nové IDE místo vylepšování některého ze stávajících nebo napsání zásuvného modulu do něj?
Oprava: V čem bude tvoje IDE lepší…
Kdyby vypadalo jak JetBrainsi produkty, opravdu podporovalo c++ a bylo multiplatformni,tak ja bych do toho sel. :)
-
Kdyby vypadalo jak JetBrainsi produkty, opravdu podporovalo c++ a bylo multiplatformni,tak ja bych do toho sel. :)
Něco jako https://www.jetbrains.com/clion/ ?
Což myslím odpovídá i na původní otázku: investor by byl blázen aby investoval do takového projektu, pokud nemá něco opravdu extra převratného.
-
Kdyby vypadalo jak JetBrainsi produkty, opravdu podporovalo c++ a bylo multiplatformni,tak ja bych do toho sel. :)
Něco jako https://www.jetbrains.com/clion/ ?
Což myslím odpovídá i na původní otázku: investor by byl blázen aby investoval do takového projektu, pokud nemá něco opravdu extra převratného.
Koukám že vedle jsi to ohodnotil jako "křáp" - nemohu osobně posoudit, vcelku tomu i věřím - ale jaká je šance že je někdo začínající od nuly dožene a předežene?
-
Kdyby vypadalo jak JetBrainsi produkty, opravdu podporovalo c++ a bylo multiplatformni,tak ja bych do toho sel. :)
Něco jako https://www.jetbrains.com/clion/ ?
Což myslím odpovídá i na původní otázku: investor by byl blázen aby investoval do takového projektu, pokud nemá něco opravdu extra převratného.
Koukám že vedle jsi to ohodnotil jako "křáp" - nemohu osobně posoudit, vcelku tomu i věřím - ale jaká je šance že je někdo začínající od nuly dožene a předežene?
Jj, to je pravda, ze s tim bude urcite strasne moc prace. Myslim, ale ze u clionu udelali spatne manazerske rozhodnuti. A to to, ze si napisou vlastni parser. Spousta lidi jim to psala uz od pocatku. Myslim, ze to bylo zpusobeno tim, ze u predchozich svych produktu to tak delali a vzdy se jim to povedlo. C++ je bohuzel na to ale prilis rozsahly a tady se jim to proste nedari. Mozna za tim byly i jine, relevantni duvody, ktere nelze tak lehce obejit. Tak dalece do toho nevidim, kazdopadne hlavni problem je pouziti vlastniho nefunknciho parseru. Ze to jde s vyse zminovanym libclangem dokazuje qt creator a kdevelop(ktery ale neni mutliplatformni)
-
... a kdevelop(ktery ale neni mutliplatformni)
Naopak! KDevelop 5 uz bude multiplatformovy. Okrem linuxu sa objavuje aj verzia pre
- win https://www.kdevelop.org/screenshots/kdevelop-5-pre-alpha-windows (https://www.kdevelop.org/screenshots/kdevelop-5-pre-alpha-windows)
- mac https://www.kdevelop.org/screenshots/kdevelop-5-beta-1-mac-os-x (https://www.kdevelop.org/screenshots/kdevelop-5-beta-1-mac-os-x)
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
ahoj
kolik bys potřeboval pučit jakou očekáváš návratnost a kolik bys mi z toho dal??
-
... a kdevelop(ktery ale neni mutliplatformni)
Naopak! KDevelop 5 uz bude multiplatformovy. Okrem linuxu sa objavuje aj verzia pre
- win https://www.kdevelop.org/screenshots/kdevelop-5-pre-alpha-windows (https://www.kdevelop.org/screenshots/kdevelop-5-pre-alpha-windows)
- mac https://www.kdevelop.org/screenshots/kdevelop-5-beta-1-mac-os-x (https://www.kdevelop.org/screenshots/kdevelop-5-beta-1-mac-os-x)
Zatim neni. Tyhle screenshoty znam. Jsou rok a pul stare a mezitim nevysla ani beta. Ne pro widle. Spis mam obavy, ze to spis odumre. Naka polofunkcni verze se da stahnout pro suse(ale spis nefungije, nez jo)
-
Jses si jisty, ze invetor to je nejdulezitejsi co potrebujes? Uz mas nejakou implementaci, ktera by se dala realne predvest? Dokazal bys' odpovedet na otazku "V cem by byla tvoje implementace lepsi nez stavajici produkty?"
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
ahoj
kolik bys potřeboval pučit jakou očekáváš návratnost a kolik bys mi z toho dal??
Zeptej se nejdřív někoho chytřejšího, než jsi ty sám, jaký je rozdíl mezi investicí a půjčkou.
-
... a kdevelop(ktery ale neni mutliplatformni)
Naopak! KDevelop 5 uz bude multiplatformovy. Okrem linuxu sa objavuje aj verzia pre
- win https://www.kdevelop.org/screenshots/kdevelop-5-pre-alpha-windows (https://www.kdevelop.org/screenshots/kdevelop-5-pre-alpha-windows)
- mac https://www.kdevelop.org/screenshots/kdevelop-5-beta-1-mac-os-x (https://www.kdevelop.org/screenshots/kdevelop-5-beta-1-mac-os-x)
Zatim neni. Tyhle screenshoty znam. Jsou rok a pul stare a mezitim nevysla ani beta. Ne pro widle. Spis mam obavy, ze to spis odumre. Naka polofunkcni verze se da stahnout pro suse(ale spis nefungije, nez jo)
Ako môžeš vidieť, v tomto smere sa už niečo deje. Ak máš energiu a chuť niečo robiť, tak by bolo lepšie, keby si ju využil na stiahnutie zdrojákov KDevelop-u a skúsil niečo z bugzilly vyriešiť/do-implementovať a tak zlepšiť aj smerovanie tohto IDE. Veď to je čaro open source...
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
Investice do nastroju pro vyvojare (v celem spektru, od prvniho napadu/designu po release) jsou obecne velmi bezpecne a vyhledavane, takze najit investora v tehle oblasti i v cesku neni problem. Je to dane hlavne tim, ze vyvojari sou pomerne dobre definovana cilovka, ze ktere se da i pri malem poctu vytezit dost penez.
Ale funguje to tak, ze:
1) Neinvestuje se do produktu/technologie, investuje se do reseni konkretniho problemu. Vyvojari maji problem s generovanim kodu z coredata modelu, vyrobime plugin pro xcode, ktery to resi. Navratnost se pocita tak, ze se vezme velikost trhu (kolik lidi ma ten problem), kolik jsou za reseni ochotni zaplatit a prenasobi se to nejakym koeficientem jak moc chci vrazit do obchodu (jak velkou cast trhu dokazu ziskat).
Z tohohle pohledu odpoved na puvodni otazku:
Kolika vyvojarum chybi C++ IDE => nikomu => nema to sanci na zainvestovani
2) Dulezita vec v tehle oblasti jsou zkusenosti lidi, kteri ty nastroje vytvari, zkusenosti s technologiemi na kterych to stoji a zaroven obchodni schopnosti v tehle oblasti, faktor "ukaz drzku" (tedy, ze za tim stoji znama osobnost ze sveta vyvoje).
Odpoved na otazku z tohohle pohledu je velmi jednoducha:
Nevime o tobe nic => nema to sanci na zainvestovani
Obecne kdyz chces delat nejaky vyvojovy nastroj a udelas si prezentaci pro investory typu:
1) Predstaveni lidi na projektu
2) Popis problemu s vypoctem potencionalniho trhu
3) Co uz je hotove a naklady na dodelani do finalni faze
4) Ze zkusenosti neni treba ze zacatku resit obchod, tedy jak chcete docilit toho, ze urvete x% trhu, protoze tohle si zkuseny investor dokaze odhadnout sam na zaklade prvnich 2 bodu.
Pokud tohle bude davat celkove smysl, tak neni problem sehnat v cesku investora. Dobre na setkani s potencionalnim IT investorem je, ze vetsina nerika zadny bs a kdyz vidi nejaky problem, tak vam ho reknou a slusne vas poslou domu, takze to de velmi jednoduse vychytat netodou pokus/omyl.
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
ahoj
kolik bys potřeboval pučit jakou očekáváš návratnost a kolik bys mi z toho dal??
Zeptej se nejdřív někoho chytřejšího, než jsi ty sám, jaký je rozdíl mezi investicí a půjčkou.
jasně 8)
budu mu platit jeho radosti ze svýho jen tak pro srandu 8) 8)
hochu zadarmo ani to kuře nehrabe 8)
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
...
Kolika vyvojarum chybi C++ IDE => nikomu => nema to sanci na zainvestovani
...
Toto zrovna neni pravda. Mne chybi. :)
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
ahoj
kolik bys potřeboval pučit jakou očekáváš návratnost a kolik bys mi z toho dal??
Zeptej se nejdřív někoho chytřejšího, než jsi ty sám, jaký je rozdíl mezi investicí a půjčkou.
jasně 8)
budu mu platit jeho radosti ze svýho jen tak pro srandu 8) 8)
hochu zadarmo ani to kuře nehrabe 8)
Zeptej se nejdřív někoho chytřejšího, než jsi ty sám, jaký je rozdíl mezi investicí a darem.
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
ahoj
kolik bys potřeboval pučit jakou očekáváš návratnost a kolik bys mi z toho dal??
Zeptej se nejdřív někoho chytřejšího, než jsi ty sám, jaký je rozdíl mezi investicí a půjčkou.
jasně 8)
budu mu platit jeho radosti ze svýho jen tak pro srandu 8) 8)
hochu zadarmo ani to kuře nehrabe 8)
Zeptej se nejdřív někoho chytřejšího, než jsi ty sám, jaký je rozdíl mezi investicí a darem.
Rozdil je jenom v tobe, existence je chimera a jestirci te milujou
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
ahoj
kolik bys potřeboval pučit jakou očekáváš návratnost a kolik bys mi z toho dal??
Zeptej se nejdřív někoho chytřejšího, než jsi ty sám, jaký je rozdíl mezi investicí a půjčkou.
jasně 8)
budu mu platit jeho radosti ze svýho jen tak pro srandu 8) 8)
hochu zadarmo ani to kuře nehrabe 8)
Zeptej se nejdřív někoho chytřejšího, než jsi ty sám, jaký je rozdíl mezi investicí a darem.
Špatná investice je snad ještě horší než dar...
-
Profi C++ IDEciek je uz dost: Visual Studio, XCode, RadStudio, QtCreator, Eclipse, NetBeans, JetBrains aj ked v tych poslednych troch menovanych by som nechcel vyvyjat.
-
Kazdeho investora bude asi zaujimat nieco ako prieskum trhu, aka je sucastna situacia a preco by si ludia kupovali tvoj produkt.
C++ ide su visualstudio, netbeans, eclipse, clion, qtcreator, ta apple vec, codeblocks, ultimate++ ide a mnoho dalsich. Tak prajem vela stastia..
Nejlepším průzkumem trhu je počet uživatelé tvého software. Platících uživatelů, protože to si nejde vycucat z prstu. Investory prvoplánově nezajímá nějaká technická vyspělost, ale čísla.
-
Vývoj se musí provádět s ohledem na budoucnost, do IDE pro C zahrněte testování komunikace mezi IoT zařízeními, jejich emulátory, prostředky pro správu těchto zařízení. Tím byste mohl získat náskok. Nebo vyviňte pluginy pro existující IDE, až získáte zákazníky, můžete jim dodat vlastní IDE.
Konkurenci máte například zde https://www.wyliodrin.com/
-
do IDE pro C zahrněte testování komunikace mezi IoT zařízeními, jejich emulátory, prostředky pro správu těchto zařízení.
Pane Novy, existujete, a nebo jste jen nejake (kolektivni?) humoristicke dilo po zpusobu J.Cimrmana?
-
Vývoj se musí provádět s ohledem na budoucnost, do IDE pro C zahrněte testování komunikace mezi IoT zařízeními, jejich emulátory, prostředky pro správu těchto zařízení. Tím byste mohl získat náskok. Nebo vyviňte pluginy pro existující IDE, až získáte zákazníky, můžete jim dodat vlastní IDE.
Konkurenci máte například zde https://www.wyliodrin.com/
A hlavně to udělejte ve Windows, protože už mám plné zuby těch multiplatformních hraček v Javě, ve kterých se nedá pracovat.
-
do IDE pro C zahrněte testování komunikace mezi IoT zařízeními, jejich emulátory, prostředky pro správu těchto zařízení.
Pane Novy, existujete, a nebo jste jen nejake (kolektivni?) humoristicke dilo po zpusobu J.Cimrmana?
No když někdo chce vyvíjet IDE pro C++, tak to už samo o sobě je dost cimrmanovské, nemyslíte :-) Ale ve spojení s IoT by to mohlo mít smysl, protože to vytváří alespoň marketingový prostor pro nové myšlenky a vývojáři nezažité postupy, nebo alespoň marketingové šance plynoucí z generační výměny vývojářů.
Ono vývojáři ne vždy jsou dost kreativní, jak by se na první pohled mohlo zdát, a někdy jsou to dost konzervy. Čím nesmyslnější jazyk, tím více potřebujete do něj investovat energie, abyste ho zvládl, tím ho více máte v oblibě a tím ho hůře opuštíte. Je to takový imprintig, známý z biologických systémů. Nejvíce patrné je to u lidí, co jejich prvním programovacím jazykem byl bash :-)))
Ostatně všechno už v IT bylo vymyšleno do 70. let minulého století, dnes se to už jenom oprašuje a možná trochu vylepšuje. Ale vychází se z těch základních nápadů z té doby. A spoustu z těch věcí se už i zapomnělo a bude se znovu objevovat.
Třeba za pár let si někdo uvědomí, že když quibit je tak mocný výpočetní nástroj, že nemusí být hned miniaturizovaný a že se dá realizovat elektronkovou technologií :-)))
-
Zdravím
Já vyvíjím (vlastně už ani ne) už od 90 let vizualizační program https://youtu.be/4qVC8sr-iL8 (https://youtu.be/4qVC8sr-iL8) , je to postaveno na nějakém jádře, které si dle předpisu přilinkovává moduly (tlačítko, textbox, ale i komunikační dll s různými protokoly,...), použil jsem nějaké IDE pro C++, jenže technologie se mění, přichází nové Windows, 64 bit,... a IDE tak nějak to vše přestalo podporovat a dnes už ho ani nespustím (krom wine na Linuxu, koketuji z myšlenkou spouštění na ReactOs).
Takže to je ošemetná věc, ještě že se mi pár aplikací pod tím mým softwarem podařilo udat, někdy v době W2k ale to jen proto že jsem si mohl udělat customizaci pro nestandartní moduly různých zařízení a vizualizovat tak jejich provoz.
-
Zdravím
Já vyvíjím (vlastně už ani ne) už od 90 let vizualizační program https://youtu.be/4qVC8sr-iL8 (https://youtu.be/4qVC8sr-iL8) , je to postaveno na nějakém jádře, které si dle předpisu přilinkovává moduly (tlačítko, textbox, ale i komunikační dll s různými protokoly,...), použil jsem nějaké IDE pro C++, jenže technologie se mění, přichází nové Windows, 64 bit,... a IDE tak nějak to vše přestalo podporovat a dnes už ho ani nespustím (krom wine na Linuxu, koketuji z myšlenkou spouštění na ReactOs).
Takže to je ošemetná věc, ještě že se mi pár aplikací pod tím mým softwarem podařilo udat, někdy v době W2k ale to jen proto že jsem si mohl udělat customizaci pro nestandartní moduly různých zařízení a vizualizovat tak jejich provoz.
páni
obdivuju že se někdo tak starej pustí do it. máš můj respekt!
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
ahoj
kolik bys potřeboval pučit jakou očekáváš návratnost a kolik bys mi z toho dal??
Zeptej se nejdřív někoho chytřejšího, než jsi ty sám, jaký je rozdíl mezi investicí a půjčkou.
jasně 8)
budu mu platit jeho radosti ze svýho jen tak pro srandu 8) 8)
hochu zadarmo ani to kuře nehrabe 8)
Zeptej se nejdřív někoho chytřejšího, než jsi ty sám, jaký je rozdíl mezi investicí a darem.
investice se ti musí vrátit 8) to ví přece každej aspoň trochu chytrej 8) 8)
když tvý firmy nevyužijou ten produkt tak logicky budeš investovat proto aby se ti vrátil větší cash než jsi dotoho narval 8)
-
investice se ti musí vrátit 8) to ví přece každej aspoň trochu chytrej 8) 8)
když tvý firmy nevyužijou ten produkt tak logicky budeš investovat proto aby se ti vrátil větší cash než jsi dotoho narval 8)
Tak už ses zeptat tatíčka na rozdíl mezi investicí a darem, teď ještě na rozdíl mezi investicí a půjčkou.
Hint: kdo se stará o to, aby se ty peníze vrátily?
-
investice se ti musí vrátit 8) to ví přece každej aspoň trochu chytrej 8) 8)
když tvý firmy nevyužijou ten produkt tak logicky budeš investovat proto aby se ti vrátil větší cash než jsi dotoho narval 8)
Tak už ses zeptat tatíčka na rozdíl mezi investicí a darem, teď ještě na rozdíl mezi investicí a půjčkou.
Hint: kdo se stará o to, aby se ty peníze vrátily?
hochu moc to neobracej tys to nevědel ne já 8) 8) proč by jsi jinak z citace odstranil ty starší citace co jsou v tom co cituješ?? 8)
a o to aby se peníze vrátili se nejlíp starají bouchači vymahačů dluhů 8)
-
hochu moc to neobracej tys to nevědel ne já 8) 8) proč by jsi jinak z citace odstranil ty starší citace co jsou v tom co cituješ?? 8)
Obracíš to ty. Ale co by se dalo od spratka, co mu tatínek všechno až na rozum zaplatí, taky dalo čekat.
Mažu je, protože jsou hrozně dlouhý a zbytečný, když stačí odskrolovat trochu nahoru.
a o to aby se peníze vrátili se nejlíp starají bouchači vymahačů dluhů 8)
Zase vedle. Jdi se zeptat tatínka.
-
hochu moc to neobracej tys to nevědel ne já 8) 8) proč by jsi jinak z citace odstranil ty starší citace co jsou v tom co cituješ?? 8)
Obracíš to ty. Ale co by se dalo od spratka, co mu tatínek všechno až na rozum zaplatí, taky dalo čekat.
Mažu je, protože jsou hrozně dlouhý a zbytečný, když stačí odskrolovat trochu nahoru.
a o to aby se peníze vrátili se nejlíp starají bouchači vymahačů dluhů 8)
Zase vedle. Jdi se zeptat tatínka.
nebudu se s tebou o tom bavit dokud se nepřiznáš žes to nevěděl protože by ses jinak neptal a že mažeš citace aby to nebylo vidět 8)
hlavě tohle celý je jenom tvoje hloupá snaha ze mě tahat managerský tipy a nevím proč bych měl radit zrovna takovýmu člověkoj jako seš ty 8) 8)
-
Moze autor odpovedat, ako to napokon dopadlo?
Dost ma tato tema zaujima, nakolko som kedysi aj ja uvazoval nad vyvojom vlastneho IDE (pre Windows, ale nie C++), ale napokon som to nerealizoval pretoze sa ukazalo, ze je dost komplikovane spravit to poriadne.
Navyse som nechcel znova "vyvijat koleso", ale kedze som sa ani nechcel vzdat tejto myslienky, tak som to spravil tak, ze som vyvinul len rozsirenie (plugin) pre Visual Studio a RAD Studio, cim som vlastne podporil 2 najpouzivanejsie IDE (ak by to niekoho zaujimalo kuknite www.visual-installer.com (http://www.visual-installer.com)).
-
Nejlepším průzkumem trhu je počet uživatelé tvého software. Platících uživatelů, protože to si nejde vycucat z prstu. Investory prvoplánově nezajímá nějaká technická vyspělost, ale čísla.
K čemu mi bude investor, když už to budu mít hotové a budu mít i zákazníky ?
-
IMHO C++ IDE nemá smysl v dnešní době psát. Nových vývojářů moc nepřibývá a ti starší už mají svoje workflow a IDE je nezajímá (lidi co oceňují IDE dávno dělají v Javě nebo něčem podobném). Když už tak pro nějaký modernější jazyk, ale tam je buď konkurence velká nebo je těžké odhadnout co se bude za pár let skutečně používat.
Jinak ale všechny C++ IDE jsou dost polovičaté. Prakticky žádné nezvládne složitější refaktoring nebo generování kódu a věci jako podpora NVI nebo parsování a navigace složitějších šablonách atd. jsou mokré sny.
-
IMHO C++ IDE nemá smysl v dnešní době psát. Nových vývojářů moc nepřibývá a ti starší už mají svoje workflow a IDE je nezajímá (lidi co oceňují IDE dávno dělají v Javě nebo něčem podobném).
Ja bych opravdu ocenil ;)
-
Protože mě zajímá, jak lidé investují své peníze do aplikace C++, napadlo mě, že by bylo užitečné dozvědět se co nejvíce o tom, proč lidé investují své peníze.
Vím, že existuje mnoho lidí, kteří investují své peníze, a musím se ptát, jaká je jejich motivace investovat do vývojářů softwaru (C++).
Peníze na platformě jsou sice velké, ale proč do ní investuje tolik lidí?
-
A máte Vy, nebo někdo další, zkušenost s https://www.jetbrains.com/clion/ ?
Nejsem Cčkař a produkt neznám, ale znám a používám jiná prostředí/pluginy (JIDEA, PyCharm, Goland..) od nich a vím, že schopnosti refaktoringu, code inspection atd. mají na velmi dobré úrovni.
-
Na C++ je už dosť kvalitných IDE, osobne pod Windows používam:
Visual Studio 2022 Community toto idečko od MS je jedno z TOP idečiek pre C++, podporuje okrem ekosystému od MS (UWP, .NET, .NET core, nmake, msvc compiler) aj open source vývoj pre ostatné platformy (Linux, iOS, Mac OS, Android). Už v základe má okrem msvc compileru podporu clangu. A tiež okrem projektov založených na Visual Studio Solutions podporuje aj CMake projekty. Pre vývojára nového ide, môže byť prekážko,u že je takéto kvalitné ide v Community verzii zadarmo. Samozrejme na nekomerčné použitie (ale prax býva iná)
Pre vývojárov, ktorí preferujú editory je tu zase Visual Studio Code (nemýliť s Visual Studiom 2019 - 2022 spoločný majú len názov, inak sú to úplne odlišné Aplikácie) pre tých čo nechcú nič od MS existuje aj open source alternatíva VSCodium, ktoré má odstránenú telemetriu atď.
Ďalšie vynikajúce IDE je CLion od JetBrains nedávno som ho skúšal a uvažujem nad tým, že si ho tiež kúpim.
Ďalej je na trhu X ďalších editorov a IDEčiek prakticky zadarmo:
- Atom editor postavený na Electrone podobne ako VSCode je o niečo pomalší ako VSCode ale je tiež vynikajúci a zadarmo
- NetBeans resp Oracle Developer Studio (Net Beans s podporou od Oracle)
- Eclipse
- QTCreator
- CodeBlocks a CodeLite
- KDevelop
- potom sú tu ešte IDEčka zo sveta Gnome ako: Gnat, Anjuta, Geany tie už nie sú také kvalitné, ale sú tiež zadarmo.
- Pre WXWidghets je tu WxDev C++, ktoré umožňuje vizuálny vývoj podobne ako v Delphi (akurát v C++).
A potom je tu starý dobrý pokračovateľ Turbo C od Borlandu (momentálne Embarcadero Technologies): IDE C++ Builder - ten je síce komerčný, ale tiež má free Community Edition.
A potom sú tu vynikajúce editory ako Neovim a Emacs, ktoré sú síce náročnejšie na naučenie, ale práca v nich je veľmi efektívna a s pomocou pluginov, si z nich vieš spraviť plnohodnotné IDE. Na to, aby sa dnes presadilo nové IDE v takej obrovskej konkurencii, by muselo priniesť nejakú revolučnú myšlienku.
-
A máte Vy, nebo někdo další, zkušenost s https://www.jetbrains.com/clion/ ?
Nejsem Cčkař a produkt neznám, ale znám a používám jiná prostředí/pluginy (JIDEA, PyCharm, Goland..) od nich a vím, že schopnosti refaktoringu, code inspection atd. mají na velmi dobré úrovni.
Používám na Rust, jsem celkem spokojen a stále se to lepší.
-
Zajímavé jazyky mohou snadno získat investora.
Na to, na co seženete v USA investici $1M, tady dostanete třeba 300 000,- Kč.
Investice mohou dávat vysoké školy, státní instituce, fondy i privátní společnosti.
Pokud bych měl třeba C++ IDE, které umí vizualizovat kód, tj. ve druhém okně zobrazuje stromovou strukturu programu nebo třeba ve formě vývojového diagramu, dokážu si představit, že by do toho někdo šel.
Rozhodně bych na to šel ale přes USA.
-
Zrovna pro C++ nevim nevim... C++ není jen o tom editovat zdrojáky - code assist, integrace build systemu, debuggeru, atd... Moje predikce je, že VSCode časem zničí všechny ostatní :)
-
Moje predikce je, že VSCode časem zničí všechny ostatní :)
To samé kdysi dávno kamarád javista předpovídal pro Eclipse, že zahubí všechny (obě) konkurenční IDE. Nestalo se.
Co se týče Code, osobně tam vidím podobný problém jako u Vimu a Emacsu s tisíci rozšířeními - už to umí ledacos, ale pořád to není IDE (pokud to vůbec nějak rozumně chodí - moje zkušenost se Spacemacsem byla například hrůzná). Když si vystačím s editorem, nemám problém, ale editovat JSONy, pořád dokola si to nějak flikovat... Prostě to není ono.
-
VSCode je dnes na C++ lepší než sračky typu KDevelop. Je to snad jediné multiplatformní řešení, které mi fungovalo dobře všude. Jasně, na VS to zatím nemá, ale když se člověk podívá na jejich roadmapu, tak to tam směřuje - třeba disassembly view a celkově podpora debuggeru jako je ve VS, atd... plány mají opravdu odvážné a je to taková konkurence uvnitř MS :)
Pro mě je VSCode v Linuxu jednoznačná volba - integrace s CMake, debugging, intellisense, všechno funguje tak jak má i ve velkém projektu + možnost jednoduše scriptovat project specific věci popř. mít launchery různých dalších scriptů a možnost je i ladit (třeba python, node.js). Chybí mi jen disassembly view - v tomto VSCode na VS zatím nemá. Já dřív používal KDevelop, ale už bych se vracet nechtěl.
-
V dnesnej dobe vyvijat vlastne IDE nema zmysel, vid vyssie uvedene dovody. Jediny dovod kde by sa to asi nejak presadilo je nejaky bohom zabudnuty jazyk, tam je vsak problem v tom ze to budu pouzivat asi tak 15ti ludia na svete a ti proste vyvoj financne tahat odmietnu (predsalen kto by si kupil IDE ktore stoji tisice eur za jednu licenciu). Inak ten vyvoj ufinancujes jedine ak si velka firma a mas dost volnych penazi na to aby si ich v tom topil niekolko rokov kym (ak) sa to tvoje IDE presadi a zacne ti to aj nieco naspat vynasat.
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
Nemam. Ne. Nema.
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
Nemam. Ne. Nema.
Ok, trochu to rozvedu. Investovat do IDE pro 40 let stary jazyk neni IMHO dobry napad.
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
Nemam. Ne. Nema.
Ok, trochu to rozvedu. Investovat do IDE pro 40 let stary jazyk neni IMHO dobry napad.
Stáří první verze jazyka je naprosto irelevantní. Pro investici je důležité jen jestli v tom jazyce píše dost lidí a budou ochotní za to nové IDE zaplatit. Tady jsem si jistý že ne, ale se stářím jazyka to nemá co dělat.
C++ je jeden z jazyků (stejně jako třeba Cobol), které s námi budou až do kolapsu civilizace. Prostě je v něm napsané tolik kritické infrastruktury, že na světě není dost peněz na to, aby se dal nahradit.
I takovému Javascriptu, který je naprosto neodmyslitelnou součástí každého nového projektu, už táhne na 30 let. :)
-
Máte někdo zkušenosti s návštovou investora pro vaši aplikaci, či jste někdy do něčeho investovali?
Má aplikace např. C++ IDE šanci na nějakou investici, nebo to dneska celkem nikoho nezajímá?
Nemam. Ne. Nema.
Ok, trochu to rozvedu. Investovat do IDE pro 40 let stary jazyk neni IMHO dobry napad.
V dobe kdy se na to vyvojar ptal to bylo spis +- 30 let.
A myslim, ze zrovna zhruba v te dobe taky teprve vznikal clion. Takze tenkrat zrejme nekomu ta investice jako dobry napad prisla.
-
Slyšeli jste o věcech jako:
- robot Karel (http://karel.oldium.net/ (http://karel.oldium.net/))
- projekt Lazarus (https://cs.wikipedia.org/wiki/Lazarus (https://cs.wikipedia.org/wiki/Lazarus))
- Mathlab (https://www.pnopava.cz/ (https://www.pnopava.cz/))
Představa, že udělám kulervoucí náhradu VisualStudia v týmu tří lidí je možná směšná, možná šílená, možná nainvní.
Ale třeba nějaké IDE pro školy by se chytit mohlo.
Navíc, do budoucna bude potřeba programátorů víc a víc.
Stejně tak by se mohlo chytit AI programování / vizuální programování, kdy nepotřebujete umět programovat.
Dám vám soudruzi kontrolní otázku, v čem v roce 2005 programovalo na světě nejvíc lidí? V Excelu vole...
Udělat vizuální IDE pro datové transformace, které vezme data ze schránky, provede jejich transformaci a pak je vyzvrací do SAP/Excelu/Účetnictví... Každý den spousta účetních jen přebouchává data z tabulek do účetních programů, importy jdou pomalu. Spousta vocasů přebouchává data z webových stránek do eshopů....to by se dalo krásně transformovat.
Takže, ano, pro nějaký super projekt by to IDE mělo význam.
A co IDE pro Cčko?
Jasně, je pro to obrovský a nikým nepolíbený trh.
Jenže to nesmí být bžumbiliontá kopie PSpadu.
-
PanVP: Ty si mimo - ale tak můžeš začít s IDE, co si přečte JIRA ticket a rovnou ho naprogramuje, je to dost challenging :)
-
PanVP: Ty si mimo - ale tak můžeš začít s IDE, co si přečte JIRA ticket a rovnou ho naprogramuje, je to dost challenging :)
Jira, preboha kto ti nakecal pouzivat taku sprostost. Citanie myslienok clovece, citanie myslienok je buducnost.
To IDE si musi vediet precitat tvoju mysel (kludne aj cez internet) a interpretovat to ako neuronovu siet ktora sa vie sama vylepsit aby si rovno sama vychytala potencionalne bugy. :)
-
Chudák AI - když vidím některé lidi, tak číst jejich mysl raději fakt ne:)
-
Slyšeli jste o věcech jako:
- robot Karel (http://karel.oldium.net/ (http://karel.oldium.net/))
- projekt Lazarus (https://cs.wikipedia.org/wiki/Lazarus (https://cs.wikipedia.org/wiki/Lazarus))
- Mathlab (https://www.pnopava.cz/ (https://www.pnopava.cz/))
Představa, že udělám kulervoucí náhradu VisualStudia v týmu tří lidí je možná směšná, možná šílená, možná nainvní.
Ale třeba nějaké IDE pro školy by se chytit mohlo.
Navíc, do budoucna bude potřeba programátorů víc a víc.
Stejně tak by se mohlo chytit AI programování / vizuální programování, kdy nepotřebujete umět programovat.
Dám vám soudruzi kontrolní otázku, v čem v roce 2005 programovalo na světě nejvíc lidí? V Excelu vole...
Udělat vizuální IDE pro datové transformace, které vezme data ze schránky, provede jejich transformaci a pak je vyzvrací do SAP/Excelu/Účetnictví... Každý den spousta účetních jen přebouchává data z tabulek do účetních programů, importy jdou pomalu. Spousta vocasů přebouchává data z webových stránek do eshopů....to by se dalo krásně transformovat.
Takže, ano, pro nějaký super projekt by to IDE mělo význam.
Naprostej souhlas.
Mě přijde, že se ten vývoj furt točí v kruhu, ve spirále. V sestupný.
A co IDE pro Cčko?
Jasně, je pro to obrovský a nikým nepolíbený trh.
Jenže to nesmí být bžumbiliontá kopie PSpadu.
C/C++ je imho mrtvá záležitost.
-
C/C++ je tak mrtvé, že bez něho bys neposlal tvůj příspěvek nebo nenabootoval tvůj oblíbený OS :)
-
C/C++ je imho mrtvá záležitost.
Desktopovku v tom nebudeš vyvíjet, ale řeknu ti, jak prasím aplikace pro ESP a podobný.
Nejprve si otevřu okna prohlížeče v hojném počtu a pak v každém z nich hledám návod, jak zrovna kdo komunikuje s SPI. Najebu to do nějakého prototypu třeba v Micropythonu.
Otevřu si další milion oken a dívám se, jak se stejná věc dělá třeba v čistém C.
Tj. to IDE by kombinovalo dva jazyky, jeden na prototypování a druhý "na finální práci".
Kdysi, je to už drahně let, jsem si hrál s projektem "vizuálního programování", prostě drag&drop prvků.
(Něco jako umisťování ovládacích prvků do formuláře a jejich propojení "mašličkou".)
Tak to pojďme spojit.
Otevřu si nový projekt, načtu si definiční soubor pro ESP, drag&drop si přetáhnu PIN 1 do kódu editoru a MicroPythonem ho nastavím. Paralelně se mi v Cčkovém kódu (někde na pozadí) objevil vzorek kódu (v C/C++), který tu samou věc dělá v Cčku. Jasně, můj Micropython by to do Cčkového programu zkopírovalo zakomentovaný, ale to nevadí (Funguje jen jako kostra).
Párkrát klikneš na PIN, vybereš funkci a místo toho, abys měli milion oken na googlování, ti to ukáže ukázky kódu, které někdo jiný už takhle naprasil.
Než se objevil github a podobný vyfikundace, všechno se dělalo dřevně. Proč by nemohlo být IDE napojené na vlastní jako-Github, kam bys vkládat vlastní segmenty kódu, který v různých projektech používáš? Neplatící uživatel by svoje části kódu sdílel s ostatními, členství třeba za $24.
Vím, že to popisuji možná málo srozumitelně a že někdo řeknete, že jsou některé projekty, které něco podobného umí, že jen zbabělec programuje v něčem jiném než v Brainfucku, že bych si ty věci neměl googlovat, ale po nocích se navlékat do hubertusu, chodit lovit do parku a v mezičase se to memorovat. ::)
A pak mi někdo připomeňte, že s těžkým zbytkáčem se nemá psát na root ;D
-
C/C++ je imho mrtvá záležitost.
Desktopovku v tom nebudeš vyvíjet, ale řeknu ti, jak prasím aplikace pro ESP a podobný.
Nejprve si otevřu okna prohlížeče v hojném počtu a pak v každém z nich hledám návod, jak zrovna kdo komunikuje s SPI. Najebu to do nějakého prototypu třeba v Micropythonu.
Otevřu si další milion oken a dívám se, jak se stejná věc dělá třeba v čistém C.
Tj. to IDE by kombinovalo dva jazyky, jeden na prototypování a druhý "na finální práci".
Kdysi, je to už drahně let, jsem si hrál s projektem "vizuálního programování", prostě drag&drop prvků.
(Něco jako umisťování ovládacích prvků do formuláře a jejich propojení "mašličkou".)
Tak to pojďme spojit.
Otevřu si nový projekt, načtu si definiční soubor pro ESP, drag&drop si přetáhnu PIN 1 do kódu editoru a MicroPythonem ho nastavím. Paralelně se mi v Cčkovém kódu (někde na pozadí) objevil vzorek kódu (v C/C++), který tu samou věc dělá v Cčku. Jasně, můj Micropython by to do Cčkového programu zkopírovalo zakomentovaný, ale to nevadí (Funguje jen jako kostra).
Párkrát klikneš na PIN, vybereš funkci a místo toho, abys měli milion oken na googlování, ti to ukáže ukázky kódu, které někdo jiný už takhle naprasil.
Než se objevil github a podobný vyfikundace, všechno se dělalo dřevně. Proč by nemohlo být IDE napojené na vlastní jako-Github, kam bys vkládat vlastní segmenty kódu, který v různých projektech používáš? Neplatící uživatel by svoje části kódu sdílel s ostatními, členství třeba za $24.
Rozumím a souhlasím. Měl bych následující poznámky:
1/ Nemůže ti nabízet fragmenty v C, protože to bude matoucí a IMHO to nebudeš dělat (soudím od stolu, máš-li z reálu jiné zkušenost, beru zpět). Třeba já používám na některé své projekty OCaml-like jazyk kvůli typům, které se mi na pozadí překládají do lua kódu. Někdy se do toho lua kodu podívám, ale ne moc často.
2/ Takové fragmenty budou snadno rozbitelné. Takže se postupným zohledňováním dostaneš ke knihovnám. V souvislosti k bodu 1/ nebudeš vůbec nabízet C, ale prostě to tam frkneš na pozadí a basta. Postupným zohledňováním se dostaneš k něčemu takovém jako je VCL/CLX.
3/ Domnívám se, že strategie nafrkat butonky a pak to provázat (aka Delphi, VisualStudio, XCode) je nešťastné. Mnohem vhodnější mi přijde strategie vytvořit datový model, a nechat si butonky generovat (aka Zope/Django). Sám mám v tomto duchu načrtnutý nějaký projekt, ale známe se.
4/ Že by si používal existující fragmenty kódu - to by si nejdřív musel naučit stroj, aby těm fragmentům kódu rozuměl - pokud by si to chtěl extrahovat. Nebo by si musel přimět vývojáře, aby tyto fragmenty poskytovali vhodně kategorizovaný. Obojím jsem si prošel a nevidím to optimisticky.
-
C/C++ je imho mrtvá záležitost.
A co je teda in?
-
C/C++ je imho mrtvá záležitost.
A co je teda in?
Na nízkoúrovňové záležitosti Rust. Na ostatní věci cokoliv jiného.
Abyste mě neobviňovali z ignorance - já jsem na C vyrůstal. Umím ho používat, něco jsem v něm napsal, je to jazyk, který ve své době spasil svět. Ale taky je to hnusná mrcha, která vůbec nepomáhá a při sebemenším zaváhání či ztrátě pozornosti se ti vysměje do obličeje s ironickým core-dump.
-
C/C++ je imho mrtvá záležitost.
A co je teda in?
Na nízkoúrovňové záležitosti Rust. Na ostatní věci cokoliv jiného.
Rust má taky svoje mouchy. Ale bezpečnější je, to jo.
-
Nene, v mnoha věcech máš nejspíš pravdu, nepovažuji se za vševěda. Hájím to, že zajímave -inovativní- IDE by si "kupce" mohlo najít. Jen přij⁸t s něčím, co nebude stá kopie stávajícího řešení.
-
Inovativní IDE je právě VSCode - co neumí nascriptuješ :)
BTW: BoneFlute - a vyděláváš si Rustem? Mi se třeba Rust líbí, ale práci mám v C++ - díky zkušenostem moje hodnota na trhu práce roste velmi rychle. I kdyby byl C++ mrtvý jazyk, tak je mi to vlastně jedno, protože je v tom napsané všechno a já se nebojím o to, že by najednou nebyl zájem o programátory :) Hodně lidí zmiňuje různé jazyky a jaká je to budoucnost, ale když se člověk podívá na trh práce, tak tam nejsou :)
-
BTW: BoneFlute - a vyděláváš si Rustem? Mi se třeba Rust líbí, ale práci mám v C++ - díky zkušenostem moje hodnota na trhu práce roste velmi rychle. I kdyby byl C++ mrtvý jazyk, tak je mi to vlastně jedno, protože je v tom napsané všechno a já se nebojím o to, že by najednou nebyl zájem o programátory :) Hodně lidí zmiňuje různé jazyky a jaká je to budoucnost, ale když se člověk podívá na trh práce, tak tam nejsou :)
Já ti to samozřejmě přeju. Pokud máš práci v C++, a baví tě to, tak v tom určitě není problém. Určitě bude ještě dlouhé desetiletí po něm poptávka, stejně jako po cobolu, javě, fortranu, a dalších.
Nové jazyky vznikají proto, aby usnadnili práci vývojářům a zvýšila se kvalita software. Proto třeba Rustu predikuju budoucnost.
Poptávka po něm je a IMHO se bude zvyšovat. To, že není tak velká jako po C/C++ je jen otázka času. Vždyť je to mlaďoch, vznikl v roce 2009.
-
Len by ma zaujimalo preco prave Rust, co je na Ruste take dobre, v com je Rust lepsi ako napr. D ?
Pred 5 rokmi som skusal D a bol som z toho celkom nadseny, pekny univerzalny jazyk, syntaxou podobny C, dokonca ma prikaz rdmd, kedy v jednom kroku skompiloval a spustil program, co sa mi zdalo vhodne aj na nejake skriptovanie.
-
Podle mě se D neprosadil, protože měl GC, takže nedokázal nahradit C++.
-
Mozno ze se D este presadi.
Rust nema GC ?
-
Rust nema GC ?
Nemá, ani jinou formu správy paměti v runtimu. Alokace na haldě je záležitostí knihovních “wrapperů” jako Box, Rc, Vec apod., které používají malloc z libc.
-
Len by ma zaujimalo preco prave Rust, co je na Ruste take dobre, v com je Rust lepsi ako napr. D ?
Pred 5 rokmi som skusal D a bol som z toho celkom nadseny, pekny univerzalny jazyk, syntaxou podobny C, dokonca ma prikaz rdmd, kedy v jednom kroku skompiloval a spustil program, co sa mi zdalo vhodne aj na nejake skriptovanie.
Víš, jsou dva přístupy. Jeden tvrdí, že dokonalý návrh je takový, že už k němu není co přidat a druhý zase, že dokonalý návrh je takový, že z něj nemůžeš nic odebrat, aniž by to celé přestalo fungovat. Rust je výsledkem druhého způsobu uvažování. Na Rustu je dobré to, že dělá všechno proto, aby výsledné programy byly korektní a veškeré chyby se pokud možno projevily už v době implementace, ať už tím, že je zachytí kompilátor nebo tím, že donutí uživatele "výjimky" vidět a na místě řešit.
A víš, proč D nikdy nenahradí C++, kromě problémů s načasováním a historicky s licencí? Protože je to pořád jenom převlečené C++, jenom přidává další a další vlastnosti a C++ to dělá taky.
-
Kdyby to IDE chybelo na trhu, tak uz se toho nekdo chytne (pravdepodobne v daleke Americe) a nebude se cekat na investora z Rootu.
-
Len by ma zaujimalo preco prave Rust, co je na Ruste take dobre, v com je Rust lepsi ako napr. D ?
Pred 5 rokmi som skusal D a bol som z toho celkom nadseny, pekny univerzalny jazyk, syntaxou podobny C, dokonca ma prikaz rdmd, kedy v jednom kroku skompiloval a spustil program, co sa mi zdalo vhodne aj na nejake skriptovanie.
Víš, jsou dva přístupy. Jeden tvrdí, že dokonalý návrh je takový, že už k němu není co přidat a druhý zase, že dokonalý návrh je takový, že z něj nemůžeš nic odebrat, aniž by to celé přestalo fungovat. Rust je výsledkem druhého způsobu uvažování. Na Rustu je dobré to, že dělá všechno proto, aby výsledné programy byly korektní a veškeré chyby se pokud možno projevily už v době implementace, ať už tím, že je zachytí kompilátor nebo tím, že donutí uživatele "výjimky" vidět a na místě řešit.
casto je rychlejsi a jednodussi oddebugovat zivy program, nez bojovat s kompilatorem.
A víš, proč D nikdy nenahradí C++, kromě problémů s načasováním a historicky s licencí? Protože je to pořád jenom převlečené C++, jenom přidává další a další vlastnosti a C++ to dělá taky.
D neni prevlecene C++, napr ma automatickou zpravu pameti
-
Len by ma zaujimalo preco prave Rust, co je na Ruste take dobre, v com je Rust lepsi ako napr. D ?
Pred 5 rokmi som skusal D a bol som z toho celkom nadseny, pekny univerzalny jazyk, syntaxou podobny C, dokonca ma prikaz rdmd, kedy v jednom kroku skompiloval a spustil program, co sa mi zdalo vhodne aj na nejake skriptovanie.
Víš, jsou dva přístupy. Jeden tvrdí, že dokonalý návrh je takový, že už k němu není co přidat a druhý zase, že dokonalý návrh je takový, že z něj nemůžeš nic odebrat, aniž by to celé přestalo fungovat. Rust je výsledkem druhého způsobu uvažování. Na Rustu je dobré to, že dělá všechno proto, aby výsledné programy byly korektní a veškeré chyby se pokud možno projevily už v době implementace, ať už tím, že je zachytí kompilátor nebo tím, že donutí uživatele "výjimky" vidět a na místě řešit.
casto je rychlejsi a jednodussi oddebugovat zivy program, nez bojovat s kompilatorem.
S kompilátorem bojuje ten, kdo dosud jazyk dostatečně neovládl. Naprasit program a pak ho "debugovat" je funkční přístup pro malé prográmky, na které člověk už potom nesahá. V ostatních případech je třeba mít to napsáno slušně a spolehlivě.
-
casto je rychlejsi a jednodussi oddebugovat zivy program, nez bojovat s kompilatorem.
Boj s překladačem Rustu je mýtus. Pokud někdo se zkušenostmi třeba s C++ nebo Javou musí po přečtení “The Book” urputně “bojovat” s překladačem, neměl by být vůbec vývojářem.
-
S kompilátorem bojuje ten, kdo dosud jazyk dostatečně neovládl.
Na jednoho dobrého programátora připadá 20 pasičů.
Že ty děláš fisting neznamená, že ho zvládnou i ostatní, většina se zmůže na "nic moc misionáře" :-D
Co se líbí jednomu nevyhovuji jinému - proto je na trhu spoustu místa a není univerzální produkt.
-
Kdyby to IDE chybelo na trhu, tak uz se toho nekdo chytne (pravdepodobne v daleke Americe) a nebude se cekat na investora z Rootu.
Amerikánec programátor bere 200 měsíčně jako junior a některý si přijdou i na 400.
Ti vymýšlí něco, co jim vydělá násobně tolik, co berou.
Češi berou málo - velmi líní programátoři i třeba jen 80 hrubého, ti mohou pošilhávat po částce půl míče zisku z projektu.
-
S kompilátorem bojuje ten, kdo dosud jazyk dostatečně neovládl. Naprasit program a pak ho "debugovat" je funkční přístup pro malé prográmky, na které člověk už potom nesahá. V ostatních případech je třeba mít to napsáno slušně a spolehlivě.
pokud se ridite heslem "if it compiles, ship it"
v opacnem pripade musite program prubezne kompilovat a testovat, v takovem pripade ocenite zejmena rychlou kompilaci a moznost "praseni" ruznych docasnych uprav
priklad z realneho sveta - Parity nikdy nenahradilo Geth
-
S kompilátorem bojuje ten, kdo dosud jazyk dostatečně neovládl. Naprasit program a pak ho "debugovat" je funkční přístup pro malé prográmky, na které člověk už potom nesahá. V ostatních případech je třeba mít to napsáno slušně a spolehlivě.
pokud se ridite heslem "if it compiles, ship it"
v opacnem pripade musite program prubezne kompilovat a testovat, v takovem pripade ocenite zejmena rychlou kompilaci a moznost "praseni" ruznych docasnych uprav
priklad z realneho sveta - Parity nikdy nenahradilo Geth
Promiň, na tohle nemám čas. V Rustu existuje spousta možností rychlého prototypování, počínaje unwrap() a konče typovými aliasy. Pokud si někdo myslí, že mu v jiném jazyce (ať už to je Go nebo třeba Smalltalk) půjde práce líp, nemá smysl se hádat a přeju mu to, ale dát takovýto příklad jako "důkaz", to je až nedůstojné. Hezký den.
-
Rust ma oblasti pouziti, ale cpat ho vsude je jen honeni ega
kdyz GC vylozene neprekazi, neni duvot nepouzit jednodussi jazyk s GC
-
S kompilátorem bojuje ten, kdo dosud jazyk dostatečně neovládl. Naprasit program a pak ho "debugovat" je funkční přístup pro malé prográmky, na které člověk už potom nesahá. V ostatních případech je třeba mít to napsáno slušně a spolehlivě.
pokud se ridite heslem "if it compiles, ship it"
v opacnem pripade musite program prubezne kompilovat a testovat, v takovem pripade ocenite zejmena rychlou kompilaci a moznost "praseni" ruznych docasnych uprav
priklad z realneho sveta - Parity nikdy nenahradilo Geth
V Rustu existuje spousta možností rychlého prototypování, počínaje unwrap() a konče typovými aliasy.
Jak souvisí typové aliasy s prototypováním?
-
V Rustu existuje spousta možností rychlého prototypování, počínaje unwrap() a konče typovými aliasy.
Jak souvisí typové aliasy s prototypováním?
Nemusím se hned ze začátku detailně zamýšlet nad strukturou dat, pojmenuju si daný typ a dosadím si za něj třeba jenom (). Až si to situace vyžádá, bude z něj struct, enum nebo něco podobného.
-
V Rustu existuje spousta možností rychlého prototypování, počínaje unwrap() a konče typovými aliasy.
Jak souvisí typové aliasy s prototypováním?
Nemusím se hned ze začátku detailně zamýšlet nad strukturou dat, pojmenuju si daný typ a dosadím si za něj třeba jenom (). Až si to situace vyžádá, bude z něj struct, enum nebo něco podobného.
Nejvíc “cool” jsou v Rustu derived makra.
-
Rust ma oblasti pouziti, ale cpat ho vsude je jen honeni ega
Kdo ho cpe všude?
kdyz GC vylozene neprekazi, neni duvot nepouzit jednodussi jazyk s GC
Pointa je v tom, že Rust se svým počítáním referencí může být pohodlnější než ledasjaký jazyk s GC.
-
Vsimli ste si ze akonahle niekto zacne diskusiu okolo C/C++, tak hned je tam kopa prispeckov o tom aky je rust skvely, i ked je to total offtopic?
-
Vsimli ste si ze akonahle niekto zacne diskusiu okolo C/C++, tak hned je tam kopa prispeckov o tom aky je rust skvely, i ked je to total offtopic?
To je fakt. 15.1.2016 vzniklo tohle téma a netrvalo ani pět a tři čtvrtě roku a někdo do něj injektoval Rust.
-
Vsimli ste si ze akonahle niekto zacne diskusiu okolo C/C++, tak hned je tam kopa prispeckov o tom aky je rust skvely, i ked je to total offtopic?
To je fakt. 15.1.2016 vzniklo tohle téma a netrvalo ani pět a tři čtvrtě roku a někdo do něj injektoval Rust.
Datum vzniku nejako ovplyvnuje skutocnost ze je to offtopic?
-
BoneFlute: Ale neodpověděls na otázku. Dokáže tě (jako tebe, BoneFlute) uživit Rust?
Já jen aby to nebylo tak, že tu něco sice opěvuješ, ale v práci stejně boucháš něco jiného :) Takových teoretiků je tu hodně.
-
Vsimli ste si ze akonahle niekto zacne diskusiu okolo C/C++, tak hned je tam kopa prispeckov o tom aky je rust skvely, i ked je to total offtopic?
To je fakt. 15.1.2016 vzniklo tohle téma a netrvalo ani pět a tři čtvrtě roku a někdo do něj injektoval Rust.
Datum vzniku nejako ovplyvnuje skutocnost ze je to offtopic?
Klidně mě oprav, ale pokud si dobře pamatuju, vývoj debaty byl zhruba následující: Někdo napsal, že trh s nástroji pro C++ neroste i proto, že C++ začíná upadat. No a pak se řešilo, co má jako C++ nahradit. A když jsme u toho topicu, tématem nebylo C++ jako jazyk, ale podnikatelský záměr s vytvořením IDE.
Určitě rozumím Tvojí frustraci, když furt někde čteš, že Tvůj jazyk je na odpis nebo něco takového. Ale zrovna tady mi to přijde jako velice relevantní, protože nejde o srovnání dvou jazyků, ale odhad trendů. A přiznejme si, pokud dosud není nějaké "dokonalé" IDE pro C++, revoluce už se asi čekat nedá. Udělat IDE pro víc "trendy" jazyk, kde ta konkurence zatím moc není, by mohlo být zajímavé, i když osobně bych do toho svoje prachy nedal.
-
Vsimli ste si ze akonahle niekto zacne diskusiu okolo C/C++, tak hned je tam kopa prispeckov o tom aky je rust skvely, i ked je to total offtopic?
To je fakt. 15.1.2016 vzniklo tohle téma a netrvalo ani pět a tři čtvrtě roku a někdo do něj injektoval Rust.
Datum vzniku nejako ovplyvnuje skutocnost ze je to offtopic?
Klidně mě oprav, ale pokud si dobře pamatuju, vývoj debaty byl zhruba následující: Někdo napsal, že trh s nástroji pro C++ neroste i proto, že C++ začíná upadat. No a pak se řešilo, co má jako C++ nahradit. A když jsme u toho topicu, tématem nebylo C++ jako jazyk, ale podnikatelský záměr s vytvořením IDE.
Určitě rozumím Tvojí frustraci, když furt někde čteš, že Tvůj jazyk je na odpis nebo něco takového. Ale zrovna tady mi to přijde jako velice relevantní, protože nejde o srovnání dvou jazyků, ale odhad trendů. A přiznejme si, pokud dosud není nějaké "dokonalé" IDE pro C++, revoluce už se asi čekat nedá. Udělat IDE pro víc "trendy" jazyk, kde ta konkurence zatím moc není, by mohlo být zajímavé, i když osobně bych do toho svoje prachy nedal.
Frustracia nie je, aktivne vyuzivam viacero jazykov, podla usecase. Nie len jeden a preto ho nevidim ako vsemocnu nahradu.
Otravna je skutocnost, ze do vela diskusii (nie len tejto), ma niekto potrebu prooagovat rust. To je na tom rust tak zle ze potrebuje offtopic reklamu? Ze je to len nezaujimava otravna reklama, podporuje skutocnost ako ludia na taketo prispevky zvedsa reaguju...
-
Pointa je v tom, že Rust se svým počítáním referencí může být pohodlnější než ledasjaký jazyk s GC.
V čem je RC pohodlnější? Má hodně výhod, ale zrovna pohodlnost se k nim většinou neřadí.
-
Otravna je skutocnost, ze do vela diskusii (nie len tejto), ma niekto potrebu prooagovat rust. To je na tom rust tak zle ze potrebuje offtopic reklamu? Ze je to len nezaujimava otravna reklama, podporuje skutocnost ako ludia na taketo prispevky zvedsa reaguju...
Nevím, jak dlouho chodíš na Root, ale tohle tu bylo odpradávna. Podobně se "offtopic propagovaly" PHP, Java, Ruby, Python, Go... Kdybys reagoval k věci a nevyvořil si vlastní off topic (přesně tohle jsi udělal, k tématu nic, k předchozím argumentům nic, jen jakási generalizace zkušeností z diskusí), udělal bys asi líp.
-
Pointa je v tom, že Rust se svým počítáním referencí může být pohodlnější než ledasjaký jazyk s GC.
V čem je RC pohodlnější? Má hodně výhod, ale zrovna pohodlnost se k nim většinou neřadí.
Nejsem BoneFlute, ale on přece netvrdí, že RC je pohodlnější. Jenom to, že konkrétní jazyk s RC se může někomu jevit jako příjemnější nástroj, než jiný jazyk s GC. Původní příspěvek totiž zaváněl manipulací - proč nepoužít jazyk s GC, když to jde...
-
Otravna je skutocnost, ze do vela diskusii (nie len tejto), ma niekto potrebu prooagovat rust. To je na tom rust tak zle ze potrebuje offtopic reklamu? Ze je to len nezaujimava otravna reklama, podporuje skutocnost ako ludia na taketo prispevky zvedsa reaguju...
Nevím, jak dlouho chodíš na Root, ale tohle tu bylo odpradávna. Podobně se "offtopic propagovaly" PHP, Java, Ruby, Python, Go... Kdybys reagoval k věci a nevyvořil si vlastní off topic (přesně tohle jsi udělal, k tématu nic, k předchozím argumentům nic, jen jakási generalizace zkušeností z diskusí), udělal bys asi líp.
Argumentujes tym ze moja reakcia na offtopic je rovnako offtopic. No, ak si taky programator ako retor, tak sa nedivim ze sa nedokazes naucit C...
-
Argumentujes tym ze moja reakcia na offtopic je rovnako offtopic. No, ak si taky programator ako retor, tak sa nedivim ze sa nedokazes naucit C...
Tím ad hominem jsi to vylepšil. :)
-
Argumentujes tym ze moja reakcia na offtopic je rovnako offtopic. No, ak si taky programator ako retor, tak sa nedivim ze sa nedokazes naucit C...
Tím ad hominem jsi to vylepšil. :)
Ty asi tusis len priblizne co je argumentum ad hominem. Ad hominem sa kategorizuje viacero typov, ktory konkretne je podla teba tento?
Podla mna je ten argumet ad rem.
-
No, ak si taky programator ako retor, tak sa nedivim ze sa nedokazes naucit C...
Tím ad hominem jsi to vylepšil. :)
Ty asi tusis len priblizne co je argumentum ad hominem. Ad hominem sa kategorizuje viacero typov, ktory konkretne je podla teba tento?
Podla mna je ten argumet ad rem.
Jdi se vyspat.
-
Jdi se vyspat.
Njn, retor na urovni ;)
-
Pointa je v tom, že Rust se svým počítáním referencí může být pohodlnější než ledasjaký jazyk s GC.
V čem je RC pohodlnější? Má hodně výhod, ale zrovna pohodlnost se k nim většinou neřadí.
Nejsem BoneFlute, ale on přece netvrdí, že RC je pohodlnější. Jenom to, že konkrétní jazyk s RC se může někomu jevit jako příjemnější nástroj, než jiný jazyk s GC. Původní příspěvek totiž zaváněl manipulací - proč nepoužít jazyk s GC, když to jde...
Díky, sám bych se neobhájil lépe :)
Mě Rust rozsekal v okamžiku, kdy jsem viděl nějaký kód, který byl schopen vytvořit program bez závislosti na libc. Tehdá jsem prozřel.
Rust, dle mého chápání, je skvělý jazyk na nízkoúrovňové programování. Takové ty mikročipy etc. Což znamená, že uvažuješ nějakým způsobem, počítáš každý bajt, etc. Začít tam cpát GC je poněkud nepohodlné, zatímco Rc a spol jsou přirozené. (Říká se, že první věc, kterou si vývojář pro mikročipy naprogramuje je vlastní správu paměti ;D )
Pak máš složitější/větší/komplexnější aplikace - opět se bavíme o aplikaci, na kterou by si normálně použil C/C++. A tam buď potřebuješ výkon a rychlost (takže GC asi padá, navíc už to máš v ruce, když ten Rust tam chceš použít), a nebo změníš komplet jazyk na něco jako Java, Python, C#. A tam motivace pro změnu jazyka asi fakt nebude GC v první řadě.
Hodně mě zaujalo Go. Tam díky brutální escape-analýze se GC skoro nedostane ke slovu. To mi přišlo dost dobré.
BoneFlute: Ale neodpověděls na otázku. Dokáže tě (jako tebe, BoneFlute) uživit Rust?
Já jen aby to nebylo tak, že tu něco sice opěvuješ, ale v práci stejně boucháš něco jiného :) Takových teoretiků je tu hodně.
Ano, dokáže mě uživit.
Ne, neživí mě. Nedělám v něm. Dokonce nedělám ani v C. Živí mě mišmaš všelijakých technologií a jazyků.
A na soukromé programování mám Haskell, OCaml, a Luu.
(Aktuálně)
-
Hodně mě zaujalo Go. Tam díky brutální escape-analýze se GC skoro nedostane ke slovu. To mi přišlo dost dobré.
Jo, to je jeden způsob, jak zcela obejít alokaci na haldě. Zrovna v Go je teda ten jejich alokátor (tcmalloc) poměrně pomalý, pokud už se musí na haldě alokovat, ale jinak to šlape dobře.
-
A na soukromé programování mám Haskell, OCaml, a Luu.
OCaml rulez! :)
-
A na soukromé programování mám Haskell, OCaml, a Luu.
OCaml rulez! :)
Můžu se zeptat, proč? Koukal jsem, že se v něm dělaly nějaké kryptoprojekty (Tezos) a nějaké finanční systémy, ale co je na něm tak super?
-
A na soukromé programování mám Haskell, OCaml, a Luu.
OCaml rulez! :)
Můžu se zeptat, proč? Koukal jsem, že se v něm dělaly nějaké kryptoprojekty (Tezos) a nějaké finanční systémy, ale co je na něm tak super?
To byla trochu nadsázka, nicméně OCaml je zajímavý z akademického pohledu, má HKT, je přiměřeně funkcionální...
-
A na soukromé programování mám Haskell, OCaml, a Luu.
OCaml rulez! :)
Můžu se zeptat, proč? Koukal jsem, že se v něm dělaly nějaké kryptoprojekty (Tezos) a nějaké finanční systémy, ale co je na něm tak super?
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í.
-
A na soukromé programování mám Haskell, OCaml, a Luu.
OCaml rulez! :)
Můžu se zeptat, proč? Koukal jsem, že se v něm dělaly nějaké kryptoprojekty (Tezos) a nějaké finanční systémy, ale co je na něm tak super?
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í.
Ale to není úplně Ocaml, ne?
-
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é.
-
A na soukromé programování mám Haskell, OCaml, a Luu.
OCaml rulez! :)
Můžu se zeptat, proč? Koukal jsem, že se v něm dělaly nějaké kryptoprojekty (Tezos) a nějaké finanční systémy, ale co je na něm tak super?
P.S. Zrovna kryptoprojekty bych v tom asi nepsal. Ty "finanční systémy" jsou nejspíš Jane Street? Ti se topí v penězích, takže si mohli přepsat překladač a standardní knihovnu, aby byly modernější a rychlejší, jinak firmy spíše přecházejí z OCamlu na jiné jazyky (kvůli malé podpoře, nedostatečným knihovnám apod.). Jak je uvedeno výše, je to převážně akademická záležitost, a to ještě jen ve Francii nebo v zahraničních týmech, kde mají Francouzi vliv.
-
A na soukromé programování mám Haskell, OCaml, a Luu.
OCaml rulez! :)
Můžu se zeptat, proč? Koukal jsem, že se v něm dělaly nějaké kryptoprojekty (Tezos) a nějaké finanční systémy, ale co je na něm tak super?
P.S. Zrovna kryptoprojekty bych v tom asi nepsal. Ty "finanční systémy" jsou nejspíš Jane Street? Ti se topí v penězích, takže si mohli přepsat překladač a standardní knihovnu, aby byly modernější a rychlejší, jinak firmy spíše přecházejí z OCamlu na jiné jazyky (kvůli malé podpoře, nedostatečným knihovnám apod.). Jak je uvedeno výše, je to převážně akademická záležitost, a to ještě jen ve Francii nebo v zahraničních týmech, kde mají Francouzi vliv.
Ano, Jane Street. Na to si pamatuju ještě z doby, kdy mi Ocaml přišel jako zajímavá cesta - každopádně jsme si nesedli, chvíli jsem pak zkoušel koketovat s Haskellem, něco málo napsal ve Scale. A pak jsem si to "všechno" spojil v Rustu. Každopádně, k tomu Tezosu mám někde odkaz na YT video, kde autoři vysvětlují, proč šli do Ocaml. Crypto je zajímavé i z toho hlediska, jaké jazyky se pro ta řešení používají od C++ a C (klasický bitcoin core), přes Javu, Go, Rust, až třeba po Haskell.
-
A na soukromé programování mám Haskell, OCaml, a Luu.
OCaml rulez! :)
Můžu se zeptat, proč? Koukal jsem, že se v něm dělaly nějaké kryptoprojekty (Tezos) a nějaké finanční systémy, ale co je na něm tak super?
P.S. Zrovna kryptoprojekty bych v tom asi nepsal. Ty "finanční systémy" jsou nejspíš Jane Street? Ti se topí v penězích, takže si mohli přepsat překladač a standardní knihovnu, aby byly modernější a rychlejší, jinak firmy spíše přecházejí z OCamlu na jiné jazyky (kvůli malé podpoře, nedostatečným knihovnám apod.). Jak je uvedeno výše, je to převážně akademická záležitost, a to ještě jen ve Francii nebo v zahraničních týmech, kde mají Francouzi vliv.
Ano, Jane Street. Na to si pamatuju ještě z doby, kdy mi Ocaml přišel jako zajímavá cesta - každopádně jsme si nesedli, chvíli jsem pak zkoušel koketovat s Haskellem, něco málo napsal ve Scale. A pak jsem si to "všechno" spojil v Rustu. Každopádně, k tomu Tezosu mám někde odkaz na YT video, kde autoři vysvětlují, proč šli do Ocaml. Crypto je zajímavé i z toho hlediska, jaké jazyky se pro ta řešení používají od C++ a C (klasický bitcoin core), přes Javu, Go, Rust, až třeba po Haskell.
Haskell je asi lepší volbou než OCaml, z mnoha důvodů. Rust je někdy příliš nízkoúrovňový, ale klidně bych ho používal víc, kdyby měl lepší podporu v "cloudu".
-
Haskell je asi lepší volbou než OCaml, z mnoha důvodů. Rust je někdy příliš nízkoúrovňový, ale klidně bych ho používal víc, kdyby měl lepší podporu v "cloudu".
Máš na mysli konkrétně Google?
-
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?
Ale to není úplně Ocaml, ne?
Ne? Já bych řekl že jo. Ale i kdybych se mýlil, tak co? :)
-
Haskell je asi lepší volbou než OCaml, z mnoha důvodů. Rust je někdy příliš nízkoúrovňový, ale klidně bych ho používal víc, kdyby měl lepší podporu v "cloudu".
Máš na mysli konkrétně Google?
Taky, konkrétně třeba App Engine. Zrovna Google má svoje Go, tak ho to asi moc nepálí.
-
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.
-
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.
No jo, OCaml má zrovna skoro všechno, co se někde používá v jiných jazycích, od OO po HKT. Je to taková všehochuť, v postatě trošku hezčí Swift, to je taky pejskokočičí dort :)
-
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.
-
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.
To je zajímavý pohled. Mně přijde jako super nápad pro "skriptování" aplikace použít WebAssembly (asi via Wasmer). Do něj se dá zkompilovat lecjaký jazyk a bude jich určitě přibývat.
-
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.
-
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í.
-
Jo WASM je super, do něj se dá zkompilovat třeba to C++, takže jeho životnost bude zase o něco delší :)
-
Jo WASM je super, do něj se dá zkompilovat třeba to C++, takže jeho životnost bude zase o něco delší :)
Tak to každopádně. Mohl bys to přidat do toho IDE.
-
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í.
-
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.
To dela i typescript. Take mi transpilace ze statickeho do dynamickeho jazyka prijde hloupa.
-
To dela i typescript. Take mi transpilace ze statickeho do dynamickeho jazyka prijde hloupa.
Tak typescript a spol jsou trošku jiný případ. U webu je na výběr jen javascript nebo webassembly + záložní javascript. Jestli je něco hloupé má cenu řešit jen pokud existuje alternativa.
-
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.
-
To dela i typescript. Take mi transpilace ze statickeho do dynamickeho jazyka prijde hloupa.
Tak typescript a spol jsou trošku jiný případ. U webu je na výběr jen javascript nebo webassembly + záložní javascript. Jestli je něco hloupé má cenu řešit jen pokud existuje alternativa.
Pokud ty typy maji slouzit jen jako hinty pro linter, stacilo by je psat do komentaru. Transpilacni krok je naprosto zbytecny.
-
Idealni reseni v JS by bylo zavezt nejake zkratky pro Reflect.metadata("design:type" ... dekoratory, kterym by rozumel i typescriptovy linter. Jednalo by se o validni javascript a informace o typech by se zachovaly i v runtime. Byli bychom tam kde Python.
-
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/ ,
-
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.
-
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/ ,
Pri interpretri je runtime samotny interpreter nie kod ktory sa interpretuje.
Validovat podla deklarovaneho typu premennej v kode je na facku. Aj v pripade tak typovo silneho a bohateho jazyka ako napr ada. Vstupne hodnoty sa maju validovat podla zadania.
-
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.
Nech to bejt.
Netykejte mi. Nezname se.
-
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íš.
-
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/ ,
Pri interpretri je runtime samotny interpreter nie kod ktory sa interpretuje.
Validovat podla deklarovaneho typu premennej v kode je na facku. Aj v pripade tak typovo silneho a bohateho jazyka ako napr ada. Vstupne hodnoty sa maju validovat podla zadania.
potom musite v kodu udavat typy na dvou mistech, coz neni DRY.
-
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íš.
nemyslim, vim. V Pythonu se stejne typove anotace bezne pouzivaji jak ke staticke analyze, tak v runtime. Nektere typescriptove knihovny (typeORM), take pouzivaji anotace v runtime (s pomoci reflect-metadata).
a netykejte mi prosim.
-
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/ ,
Pri interpretri je runtime samotny interpreter nie kod ktory sa interpretuje.
Validovat podla deklarovaneho typu premennej v kode je na facku. Aj v pripade tak typovo silneho a bohateho jazyka ako napr ada. Vstupne hodnoty sa maju validovat podla zadania.
potom musite v kodu udavat typy na dvou mistech, coz neni DRY.
Je to DRY, mam deklarovanu premennu napr smallint, do ktorej ocakavam zo vstupu prercenta (0-100). Mozem sice pouzit subtype Percenta is Smallint range 0..100; a napisat si super parser ktory mi deklaracie bude konvertovat napr. na regular ktory potom v runtime bude validovat hodnoty. Alebo budem odchytavat exceptions...
Pripadne to urobim tak ze deklarujem triedu request ktora bude mat metodu getPercenta a vrati priamo ten typ Percenta, pripadne hodi vynimku ak vstup nebude validny. Takto v jednej triede popisem vstup podla kontraktu a v zbytku kodu uz budem pouzivat priamo percenta, bez zbytocnej typovej kontroly (tu urobi prekladac uz pri preklade) a bez zbytocnej kontroly pretecenia (implicitne priradenia ada nedovoli).
Deklaracia triedy request sa dobre anotuje (nie su v nej zalezitosti mimo ramec funkcnosti triedy). Naviac ten vysledny kod je rychly...
-
Mozem sice pouzit subtype Percenta is Smallint range 0..100; a napisat si super parser ktory mi deklaracie bude konvertovat napr. na regular ktory potom v runtime bude validovat hodnoty. Alebo budem odchytavat exceptions...
presne to je cil, ale tohle konkretne v Pythonu pujde validovat pouze v runtime, protoze Mypy (zatim?) neumi rozsahove ciselne typy.
doporucuji se podivat na dokumentaci te knihovny, kterou jsem odkazoval, validace podle typovych anotaci je default, ale muzete ji libovolne customizovat, kdyz nestaci
-
Pripadne to urobim tak ze deklarujem triedu request ktora bude mat metodu getPercenta a vrati priamo ten typ Percenta, pripadne hodi vynimku ak vstup nebude validny. Takto v jednej triede popisem vstup podla kontraktu a v zbytku kodu uz budem pouzivat priamo percenta, bez zbytocnej typovej kontroly (tu urobi prekladac uz pri preklade) a bez zbytocnej kontroly pretecenia (implicitne priradenia ada nedovoli).
Deklaracia triedy request sa dobre anotuje (nie su v nej zalezitosti mimo ramec funkcnosti triedy). Naviac ten vysledny kod je rychly...
to neni DRY, protoze musite nekde definovat ciselnou promenou, do ktere ta procenta ukladate, a na jinem miste napsa kod, ktery overuje, ze vstupni string je cislo.
-
Pripadne to urobim tak ze deklarujem triedu request ktora bude mat metodu getPercenta a vrati priamo ten typ Percenta, pripadne hodi vynimku ak vstup nebude validny. Takto v jednej triede popisem vstup podla kontraktu a v zbytku kodu uz budem pouzivat priamo percenta, bez zbytocnej typovej kontroly (tu urobi prekladac uz pri preklade) a bez zbytocnej kontroly pretecenia (implicitne priradenia ada nedovoli).
Deklaracia triedy request sa dobre anotuje (nie su v nej zalezitosti mimo ramec funkcnosti triedy). Naviac ten vysledny kod je rychly...
to neni DRY, protoze musite nekde definovat ciselnou promenou, do ktere ta procenta ukladate, a na jinem miste napsa kod, ktery overuje, ze vstupni string je cislo.
Njn, staticky typovany jazyk... premenna do ktorej tu navratovu hodnotu ulozim musi byt rovnakeho typu, alebo musi byt definovany operator priradenia, alebo ju musim explicitne pretypovat...
Je to DRY, naviac tym ze oddelim algoritmus pre ziskanie hodnoty od ostanej funkcionality a pred navratom tej hodnoty ju validujem v dalsej metode, tak to nie je ani spagetak...
-
Njn, staticky typovany jazyk...
jde to jen v jazycich, ktere podporuji reflexi typovych anotaci za behu. Zrovna v ADE to asi nejde, ale s tim jste prisel vy, ja uvedl odkaz na konkretni knihovny v Pythonu a Typescriptu
premenna do ktorej tu navratovu hodnotu ulozim musi byt rovnakeho typu, alebo musi byt definovany operator priradenia, alebo ju musim explicitne pretypovat...
v pydanticu staci, kdyz konstruktor ciloveho typu akceptuje zdrojovy typ (vetsinou string). https://pydantic-docs.helpmanual.io/usage/models/#data-conversion
-
v pydanticu staci, kdyz konstruktor ciloveho typu akceptuje zdrojovy typ (vetsinou string). https://pydantic-docs.helpmanual.io/usage/models/#data-conversion
pokud chcete zakazat implicitni konverze, pouzijete strict typy
https://pydantic-docs.helpmanual.io/usage/types/#strict-types
-
No, vy o koze ja o voze.
Validacia vstupu je nieco ine ako typova kontrola.
Typova kontrola je o tom ze do premennej mozete vlozit typ ktory odpoveda deklaracii premennej. Alebo ze funkciu mozete volat len s parametrom rovnakeho typu s akym je deklarovana.
Validacia vstupu je naproti tomu kontrola frormatu ako je ulozena napr. vo vymennom formate, pripadne vstup moze pochadzat s formulara. Takze mame deklarovany typ ako ho pouzivame v kode. Ale format vstupu moze odpovedat /^1?\d{2}%$/ alebo /^(:?0|1)\d{2}$/ alebo /^(:?1\.0{2})|(:?0\.\d{2})$/ a mnoho dalsieho. To ale aky format je na vstupe ide mimo definiciu toto typu. Definicia typu netusi ako ho ukladaju trebars v pakistane, to je nutne deklarovat zvlast. A podla principu DRY, deklarujeme typ zvlast. A jeho validatory a parsery, zvlast. Takze v runtime tak mate ulozeny format pre validaciu s tym ako z neho urobit konkretny typ. Po validacii a parsovani sa vam z neho stane typ ktory predpokladate v kode a nie je ho nutne znova a znova validovat.
-
jde to jen v jazycich, ktere podporuji reflexi typovych anotaci za behu. Zrovna v ADE to asi nejde, ale s tim jste prisel vy, ja uvedl odkaz na konkretni knihovny v Pythonu a Typescript
No vidite, uz ste skoro doma. Este si staci odpovedat ci ma lua reflexiu typovych anotacii za behu... Ani v javacripte nie... Tak ze ak pouzivate nieco ako transpiller a mate to dobre otypovane v zdroji, tak vam ten transpiler predsa neda boolean ako parameter ktory ma byt int...
-
jde to jen v jazycich, ktere podporuji reflexi typovych anotaci za behu. Zrovna v ADE to asi nejde, ale s tim jste prisel vy, ja uvedl odkaz na konkretni knihovny v Pythonu a Typescript
No vidite, uz ste skoro doma. Este si staci odpovedat ci ma lua reflexiu typovych anotacii za behu...
do vysledneho kodu v dynamickem jazyce jdou pridat typove anotace pomoci nejake dodatecne struktury s metadatay, tak jak to dela typescript kdyz kompiluje do es6
-
No, vy o koze ja o voze.
no, ja jsem uvedl priklad, kdy se typove anotace k validacim pouzivaji (prevazne validace JSONu). Vy jste si vymyslel jiny priklad a chcete jim dokazat, ze to neni mozne.
-
jde to jen v jazycich, ktere podporuji reflexi typovych anotaci za behu. Zrovna v ADE to asi nejde, ale s tim jste prisel vy, ja uvedl odkaz na konkretni knihovny v Pythonu a Typescript
No vidite, uz ste skoro doma. Este si staci odpovedat ci ma lua reflexiu typovych anotacii za behu...
do vysledneho kodu v dynamickem jazyce jdou pridat typove anotace pomoci nejake dodatecne struktury s metadatay, tak jak to dela typescript kdyz kompiluje do es6
K comu, aby ten transpilovany javascrip overil ze sa typescript nezmylil. DONT REPEAT YOURSELF! Ak urobis typovu kontrolu v zdrojovom kode, tak je zbytocne ju replikovat v cielovom kode.
-
No, vy o koze ja o voze.
no, ja jsem uvedl priklad, kdy se typove anotace k validacim pouzivaji (prevazne validace JSONu). Vy jste si vymyslel jiny priklad a chcete jim dokazat, ze to neni mozne.
Takze zavedieme pravidlo ze percenta sa budu zapisovat tak ako mate deklarovany typ?
Co ak budete importovat bankove vypisy? Mate predstavu kolko roznych formatov dostanete len v pripade ze budete pracovat s tuzenskymi bankami? Prekopete standarty tak aby vyhovovali anotaci? Alebo poprosite niekoho aby vam napisal servicu ktorej predhodite abo format a ona vam vrati json?
-
jde to jen v jazycich, ktere podporuji reflexi typovych anotaci za behu. Zrovna v ADE to asi nejde, ale s tim jste prisel vy, ja uvedl odkaz na konkretni knihovny v Pythonu a Typescript
No vidite, uz ste skoro doma. Este si staci odpovedat ci ma lua reflexiu typovych anotacii za behu...
do vysledneho kodu v dynamickem jazyce jdou pridat typove anotace pomoci nejake dodatecne struktury s metadatay, tak jak to dela typescript kdyz kompiluje do es6
K comu, aby ten transpilovany javascrip overil ze sa typescript nezmylil. DONT REPEAT YOURSELF! Ak urobis typovu kontrolu v zdrojovom kode, tak je zbytocne ju replikovat v cielovom kode.
nekdy se hodi mit statickou kontrolu v kodu a dynamickou kontrolu v javascriptovem REPLu. uvedl jsem priklad typeORM
jeste jednou naposledy nekdy se to hodi. netvrdim ze vzdy.
-
jde to jen v jazycich, ktere podporuji reflexi typovych anotaci za behu. Zrovna v ADE to asi nejde, ale s tim jste prisel vy, ja uvedl odkaz na konkretni knihovny v Pythonu a Typescript
No vidite, uz ste skoro doma. Este si staci odpovedat ci ma lua reflexiu typovych anotacii za behu...
do vysledneho kodu v dynamickem jazyce jdou pridat typove anotace pomoci nejake dodatecne struktury s metadatay, tak jak to dela typescript kdyz kompiluje do es6
K comu, aby ten transpilovany javascrip overil ze sa typescript nezmylil. DONT REPEAT YOURSELF! Ak urobis typovu kontrolu v zdrojovom kode, tak je zbytocne ju replikovat v cielovom kode.
nekdy se hodi mit statickou kontrolu v kodu a dynamickou kontrolu v javascriptovem REPLu. uvedl jsem priklad typeORM
jeste jednou naposledy nekdy se to hodi. netvrdim ze vzdy.
Takze ak sa zmeni schema pre tu api, tak prepisete naviac este anotacie... to je DRY?
-
jde to jen v jazycich, ktere podporuji reflexi typovych anotaci za behu. Zrovna v ADE to asi nejde, ale s tim jste prisel vy, ja uvedl odkaz na konkretni knihovny v Pythonu a Typescript
No vidite, uz ste skoro doma. Este si staci odpovedat ci ma lua reflexiu typovych anotacii za behu...
do vysledneho kodu v dynamickem jazyce jdou pridat typove anotace pomoci nejake dodatecne struktury s metadatay, tak jak to dela typescript kdyz kompiluje do es6
K comu, aby ten transpilovany javascrip overil ze sa typescript nezmylil. DONT REPEAT YOURSELF! Ak urobis typovu kontrolu v zdrojovom kode, tak je zbytocne ju replikovat v cielovom kode.
nekdy se hodi mit statickou kontrolu v kodu a dynamickou kontrolu v javascriptovem REPLu. uvedl jsem priklad typeORM
jeste jednou naposledy nekdy se to hodi. netvrdim ze vzdy.
Takze ak sa zmeni schema pre tu api, tak prepisete naviac este anotacie... to je DRY?
je to DRY, prepisu POUZE anotace.
-
A je tu teda někdo, kdo skutečně vyvíjí v C++ a nějaká featura mu v současných IDE chybí? Neřeším ani tak Visual Studio (v něm jsem dělal před 20 lety a už tenkrát bylo vcelku na úrovni), ale třeba konkrétně CLion. Někdo na něj nadával, že ten jejich C++ parser byla chyba, ale očekávám, že na Linuxu nic lepšího beztak nebude. Na Macu je Xcode, ale to mi přijde jako peklo na kolečkách, hlavně ty neustálé mnohagigabajtové updaty, ale v zásadě jsem tam jenom kompiloval, třeba to je na vývoj v pohodě.
-
Xcode sa vsade pouziva iba na kompilaciu... Hold licencne podmienky od jablka.
-
Vratim sa k IDE pre C++, to co mi chyba je IDE pre vyvoj na arduino a podobnych platformach. Ale myslim IDE nie to co sa vola "Arduino IDE". Viem, ze sa da vyhodne pouzit Visual Studio (asi najlepsie v com som robil) aj Visual studio Code. Len by som chcel nieco co ma mikroprocesory viac v krvi.
-
A je tu teda někdo, kdo skutečně vyvíjí v C++ a nějaká featura mu v současných IDE chybí? Neřeším ani tak Visual Studio (v něm jsem dělal před 20 lety a už tenkrát bylo vcelku na úrovni), ale třeba konkrétně CLion. Někdo na něj nadával, že ten jejich C++ parser byla chyba, ale očekávám, že na Linuxu nic lepšího beztak nebude. Na Macu je Xcode, ale to mi přijde jako peklo na kolečkách, hlavně ty neustálé mnohagigabajtové updaty, ale v zásadě jsem tam jenom kompiloval, třeba to je na vývoj v pohodě.
Teď už mají diferenciální aktualizace (pro všechny aplikace včetně Xcode).
-
A je tu teda někdo, kdo skutečně vyvíjí v C++ a nějaká featura mu v současných IDE chybí? Neřeším ani tak Visual Studio (v něm jsem dělal před 20 lety a už tenkrát bylo vcelku na úrovni), ale třeba konkrétně CLion. Někdo na něj nadával, že ten jejich C++ parser byla chyba, ale očekávám, že na Linuxu nic lepšího beztak nebude. Na Macu je Xcode, ale to mi přijde jako peklo na kolečkách, hlavně ty neustálé mnohagigabajtové updaty, ale v zásadě jsem tam jenom kompiloval, třeba to je na vývoj v pohodě.
Teď už mají diferenciální aktualizace (pro všechny aplikace včetně Xcode).
To je super posun, jak je to dlouho?
-
jde to jen v jazycich, ktere podporuji reflexi typovych anotaci za behu. Zrovna v ADE to asi nejde, ale s tim jste prisel vy, ja uvedl odkaz na konkretni knihovny v Pythonu a Typescript
No vidite, uz ste skoro doma. Este si staci odpovedat ci ma lua reflexiu typovych anotacii za behu...
do vysledneho kodu v dynamickem jazyce jdou pridat typove anotace pomoci nejake dodatecne struktury s metadatay, tak jak to dela typescript kdyz kompiluje do es6
K comu, aby ten transpilovany javascrip overil ze sa typescript nezmylil. DONT REPEAT YOURSELF! Ak urobis typovu kontrolu v zdrojovom kode, tak je zbytocne ju replikovat v cielovom kode.
nekdy se hodi mit statickou kontrolu v kodu a dynamickou kontrolu v javascriptovem REPLu. uvedl jsem priklad typeORM
jeste jednou naposledy nekdy se to hodi. netvrdim ze vzdy.
Takze ak sa zmeni schema pre tu api, tak prepisete naviac este anotacie... to je DRY?
je to DRY, prepisu POUZE anotace.
Podla schemy ktora to api definuje, takze duplicita.
-
Vratim sa k IDE pre C++, to co mi chyba je IDE pre vyvoj na arduino a podobnych platformach. Ale myslim IDE nie to co sa vola "Arduino IDE". Viem, ze sa da vyhodne pouzit Visual Studio (asi najlepsie v com som robil) aj Visual studio Code. Len by som chcel nieco co ma mikroprocesory viac v krvi.
Da sa aj v clion, https://blog.jetbrains.com/clion/2020/08/arduino-from-hobby-to-prof-p1/ . Myslim ze na to bude stacit community verzia.
Co myslis tym, ma viac procesory v krvi?
-
A je tu teda někdo, kdo skutečně vyvíjí v C++ a nějaká featura mu v současných IDE chybí? Neřeším ani tak Visual Studio (v něm jsem dělal před 20 lety a už tenkrát bylo vcelku na úrovni), ale třeba konkrétně CLion. Někdo na něj nadával, že ten jejich C++ parser byla chyba, ale očekávám, že na Linuxu nic lepšího beztak nebude. Na Macu je Xcode, ale to mi přijde jako peklo na kolečkách, hlavně ty neustálé mnohagigabajtové updaty, ale v zásadě jsem tam jenom kompiloval, třeba to je na vývoj v pohodě.
Teď už mají diferenciální aktualizace (pro všechny aplikace včetně Xcode).
To je super posun, jak je to dlouho?
Už pár let, zavedli to pro iOS a pak i macOS. Mně nová instalace stahuje okolo 11 GB a aktualizace jsou pak jen stovky MB. Nicméně čistě pro kompilaci stačí stáhnout jen Command line tools, tam jsou všechny překladače a SDK pro všechny jejich OS a bez GUI (IDE) to je mnohem menší.
-
Oprava, tak comunnity verzia tam nie je...
-
Nicméně čistě pro kompilaci stačí stáhnout jen Command line tools, tam jsou všechny překladače a SDK pro všechny jejich OS a bez GUI (IDE) to je mnohem menší.
A vie to fungovat aj v kontajneri, koli CI?
-
Nicméně čistě pro kompilaci stačí stáhnout jen Command line tools, tam jsou všechny překladače a SDK pro všechny jejich OS a bez GUI (IDE) to je mnohem menší.
A vie to fungovat aj v kontajneri, koli CI?
To zakazuje licence.
-
To je super posun, jak je to dlouho?
Už pár let, zavedli to pro iOS a pak i macOS. Mně nová instalace stahuje okolo 11 GB a aktualizace jsou pak jen stovky MB. Nicméně čistě pro kompilaci stačí stáhnout jen Command line tools, tam jsou všechny překladače a SDK pro všechny jejich OS a bez GUI (IDE) to je mnohem menší.
Aha, já jsem měl pocit, že mě to v nějaké chvíli nutilo si to GUI stahovat, ale už bych hádal, je to nějaká doba, už tyhle věci osobně nedělám. Tak snad jo, dík za info.
-
Nicméně čistě pro kompilaci stačí stáhnout jen Command line tools, tam jsou všechny překladače a SDK pro všechny jejich OS a bez GUI (IDE) to je mnohem menší.
A vie to fungovat aj v kontajneri, koli CI?
To zakazuje licence.
A ako sa riesi CI pre iOs a macOs?
-
To je super posun, jak je to dlouho?
Už pár let, zavedli to pro iOS a pak i macOS. Mně nová instalace stahuje okolo 11 GB a aktualizace jsou pak jen stovky MB. Nicméně čistě pro kompilaci stačí stáhnout jen Command line tools, tam jsou všechny překladače a SDK pro všechny jejich OS a bez GUI (IDE) to je mnohem menší.
Aha, já jsem měl pocit, že mě to v nějaké chvíli nutilo si to GUI stahovat, ale už bych hádal, je to nějaká doba, už tyhle věci osobně nedělám. Tak snad jo, dík za info.
Není zač.
O těch Command line tools se moc neví, všichni zjevně instalují Xcode. V podstatě to je jako Visual Studio oproti instalaci překladačů a msbuild.
-
Nicméně čistě pro kompilaci stačí stáhnout jen Command line tools, tam jsou všechny překladače a SDK pro všechny jejich OS a bez GUI (IDE) to je mnohem menší.
A vie to fungovat aj v kontajneri, koli CI?
To zakazuje licence.
A ako sa riesi CI pre iOs a macOs?
Jako všude jinde, to s kontejnerama nesouvisí.
-
Nicméně čistě pro kompilaci stačí stáhnout jen Command line tools, tam jsou všechny překladače a SDK pro všechny jejich OS a bez GUI (IDE) to je mnohem menší.
A vie to fungovat aj v kontajneri, koli CI?
To zakazuje licence.
A ako sa riesi CI pre iOs a macOs?
Jako všude jinde, to s kontejnerama nesouvisí.
No, vsude jinde... Tak jinde konkretne u mna sa po tagnuti stable verzie v gitlabe, vytvori kontajner, naklonuje sa do neho repozitar, vybuildi sa, otestuje, vytvori balicek a nazdiela. Obrazov pre tie kontajnery je viacero podla cieloveho systemu (aj widle cez mingw)
Konkretizuj to "jako jinde" pls...
-
jde to jen v jazycich, ktere podporuji reflexi typovych anotaci za behu. Zrovna v ADE to asi nejde, ale s tim jste prisel vy, ja uvedl odkaz na konkretni knihovny v Pythonu a Typescript
No vidite, uz ste skoro doma. Este si staci odpovedat ci ma lua reflexiu typovych anotacii za behu...
do vysledneho kodu v dynamickem jazyce jdou pridat typove anotace pomoci nejake dodatecne struktury s metadatay, tak jak to dela typescript kdyz kompiluje do es6
K comu, aby ten transpilovany javascrip overil ze sa typescript nezmylil. DONT REPEAT YOURSELF! Ak urobis typovu kontrolu v zdrojovom kode, tak je zbytocne ju replikovat v cielovom kode.
nekdy se hodi mit statickou kontrolu v kodu a dynamickou kontrolu v javascriptovem REPLu. uvedl jsem priklad typeORM
jeste jednou naposledy nekdy se to hodi. netvrdim ze vzdy.
Takze ak sa zmeni schema pre tu api, tak prepisete naviac este anotacie... to je DRY?
je to DRY, prepisu POUZE anotace.
Podla schemy ktora to api definuje, takze duplicita.
prave ze ty anotace definuji API. Proste mate nejakou definici entit s typovymi anotacemi a z nich vychazi cela aplikace (datatabazove modely, validace ...)
-
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.
-
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...
-
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.
-
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.
-
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.
-
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?
-
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í ;D
-
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?
Nevim no, ale webovy framework v Pythonu ma k IDE pro C++ pomerne dost daleko.
-
Ta diskusia ale bola o tom ze ak v zdrojakoch vykonas typovu kontrolu tak je zbytocne ju zaniest do vysledku...
-
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í ;D
Kazdy utorok mam benevolentny den...
-
[Ten kdo brojil proti offtopic sám se ho dopouští ;D
Ještě ho naučíme Rust a bude náš. :D
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?
-
Hoši, obdivuji váš smysl pro humor, za chvilku to bude vypadat takhle:
Proužky se prý letos nosí ;D
Jo, to je výživné, miluju to i v mailech. Asi vedeni úzkostí, že se nějaký myšlenkový unikát ze schránky vypaří, citují někteří celé vlákno dál a dál...
-
Jj.
Nesnáším to.
A nejlepší je, když tam někde uvnitř je "a viděl to ten šulin z obchodního?" nebo podobně výživné věci.
-
Jj.
Nesnáším to.
A nejlepší je, když tam někde uvnitř je "a viděl to ten šulin z obchodního?" nebo podobně výživné věci.
Tam je tolik vnoření, že to Safari neotevře, jsem si kvůli tomu musel pustit Windows a koukat na to v Edge...
-
[Ten kdo brojil proti offtopic sám se ho dopouští ;D
Ještě ho naučíme Rust a bude náš. :D
Jo, aby ho pak překládal do něčeho jako Lua... :)
-
[Ten kdo brojil proti offtopic sám se ho dopouští ;D
Ještě ho naučíme Rust a bude náš. :D
Jo, aby ho pak překládal do něčeho jako Lua... :)
Na SMEP PP 06.
-
[Ten kdo brojil proti offtopic sám se ho dopouští ;D
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.
-
VS ok... ale hodně mě vadí lagování.
Na VS je chutňoučký automatický formátování kódu a ideálně vylepšené o doplňování znaků :o
Něco napíšeš a ten kretén to nějak formátuje, přitom nechceš, aby ti na tvůj kód nikdo sahal.
Napíšeš " a přidá ti to ""... >:( ...odebereš "a druhou tam nechá...nebo taky ne, protože je sudé pondělí v lichém měsíci.
Přál bych si chytit toho, kdo tohle vymyslel, svázat ho do kozelce a nechat mu na hlavu kapat vodu.
Tak dá se to vypnout, ale najít ty správný přepínače......kapající voda a elektřina...
Jo a naprosto kulervoucí věc na VS je ta, že občas přidává klávesnici.
Používám QWERTY, jako každý normální heterosexuál, co píše komenty v češtině a používá znaky jako <>-=^%@$...
Ta svině tam už od Windows 7 včetně ...náhodně přidává QWERTZ! Resp. dělá to i Office.
Někdy se to nestane týden a pak během jednoho dne dvakrát se mi objeví klávesnice US, QWERTY a QWERTZ...... >:(
-
Jj.
Nesnáším to.
A nejlepší je, když tam někde uvnitř je "a viděl to ten šulin z obchodního?" nebo podobně výživné věci.
Tam je tolik vnoření, že to Safari neotevře, jsem si kvůli tomu musel pustit Windows a koukat na to v Edge...
Firefox na android telefone to dava v pohode... Nuz, kazdy si je strojcom vlastneho osudu... :D
-
VS ok... ale hodně mě vadí lagování.
Na VS je chutňoučký automatický formátování kódu a ideálně vylepšené o doplňování znaků :o
Něco napíšeš a ten kretén to nějak formátuje, přitom nechceš, aby ti na tvůj kód nikdo sahal.
Napíšeš " a přidá ti to ""... >:( ...odebereš "a druhou tam nechá...nebo taky ne, protože je sudé pondělí v lichém měsíci.
Přál bych si chytit toho, kdo tohle vymyslel, svázat ho do kozelce a nechat mu na hlavu kapat vodu.
Tak dá se to vypnout, ale najít ty správný přepínače......kapající voda a elektřina...
Jo a naprosto kulervoucí věc na VS je ta, že občas přidává klávesnici.
Používám QWERTY, jako každý normální heterosexuál, co píše komenty v češtině a používá znaky jako <>-=^%@$...
Ta svině tam už od Windows 7 včetně ...náhodně přidává QWERTZ! Resp. dělá to i Office.
Někdy se to nestane týden a pak během jednoho dne dvakrát se mi objeví klávesnice US, QWERTY a QWERTZ...... >:(
Jo, tohle oboje se mi stává - i lagování i "nevyžádané doplňování" (v CLionu), jenže to samé mi dělají i editory. Jakmile tam je nějaký chytrý plugin, začne občas škodit. Pořád jsem ale pro IDE (v Rustu), zatímco v Pythonu jsem se na PyCharm ani nic dalšího nedokázal naladit a zůstávám u Vimu. C++, Java, Scala apod., tam bych vždycky šel po IDE.
-
[Ten kdo brojil proti offtopic sám se ho dopouští ;D
Ještě ho naučíme Rust a bude náš. :D
Jo, aby ho pak překládal do něčeho jako Lua... :)
Na SMEP PP 06.
Neviem o tom ze by som pisal ze pouzivam nejaky transpiller. I ked sem tam pouzijem, NIM preklada cez C. Ale ten tu spominam prvy krat.
SMEP PP 06? :D V casoch ked kamosi slintali v skole nad PP06, tak som mal doma turbo xt na 10Mhz s 80 Mb HD.
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.
-
VS ok... ale hodně mě vadí lagování.
Na VS je chutňoučký automatický formátování kódu a ideálně vylepšené o doplňování znaků :o
Něco napíšeš a ten kretén to nějak formátuje, přitom nechceš, aby ti na tvůj kód nikdo sahal.
Napíšeš " a přidá ti to ""... >:( ...odebereš "a druhou tam nechá...nebo taky ne, protože je sudé pondělí v lichém měsíci.
Přál bych si chytit toho, kdo tohle vymyslel, svázat ho do kozelce a nechat mu na hlavu kapat vodu.
Tak dá se to vypnout, ale najít ty správný přepínače......kapající voda a elektřina...
Jo a naprosto kulervoucí věc na VS je ta, že občas přidává klávesnici.
Používám QWERTY, jako každý normální heterosexuál, co píše komenty v češtině a používá znaky jako <>-=^%@$...
Ta svině tam už od Windows 7 včetně ...náhodně přidává QWERTZ! Resp. dělá to i Office.
Někdy se to nestane týden a pak během jednoho dne dvakrát se mi objeví klávesnice US, QWERTY a QWERTZ...... >:(
Jo, tohle oboje se mi stává - i lagování i "nevyžádané doplňování" (v CLionu), jenže to samé mi dělají i editory. Jakmile tam je nějaký chytrý plugin, začne občas škodit. Pořád jsem ale pro IDE (v Rustu), zatímco v Pythonu jsem se na PyCharm ani nic dalšího nedokázal naladit a zůstávám u Vimu. C++, Java, Scala apod., tam bych vždycky šel po IDE.
Jj, laguje, on totiz pri vacsich projektoch zacina swapovat. Da sa to riesit tym ze mu obmedzim pamat. Ale ak pre nim bude raz nejake normalne IDE, tak a VS rad vzdam...
-
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.
-
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.
Tak preto ta binarka vyzera ako by to vyplul turbo basic... Njn, to ze rust nie je pre mna som uz pisal, ked uz "otravny" prekladac tak mam radsej gnat :D
-
VS ok... ale hodně mě vadí lagování.
Na VS je chutňoučký automatický formátování kódu a ideálně vylepšené o doplňování znaků :o
Něco napíšeš a ten kretén to nějak formátuje, přitom nechceš, aby ti na tvůj kód nikdo sahal.
Napíšeš " a přidá ti to ""... >:( ...odebereš "a druhou tam nechá...nebo taky ne, protože je sudé pondělí v lichém měsíci.
Přál bych si chytit toho, kdo tohle vymyslel, svázat ho do kozelce a nechat mu na hlavu kapat vodu.
Tak dá se to vypnout, ale najít ty správný přepínače......kapající voda a elektřina...
Jo a naprosto kulervoucí věc na VS je ta, že občas přidává klávesnici.
Používám QWERTY, jako každý normální heterosexuál, co píše komenty v češtině a používá znaky jako <>-=^%@$...
Ta svině tam už od Windows 7 včetně ...náhodně přidává QWERTZ! Resp. dělá to i Office.
Někdy se to nestane týden a pak během jednoho dne dvakrát se mi objeví klávesnice US, QWERTY a QWERTZ...... >:(
Jo, tohle oboje se mi stává - i lagování i "nevyžádané doplňování" (v CLionu), jenže to samé mi dělají i editory. Jakmile tam je nějaký chytrý plugin, začne občas škodit. Pořád jsem ale pro IDE (v Rustu), zatímco v Pythonu jsem se na PyCharm ani nic dalšího nedokázal naladit a zůstávám u Vimu. C++, Java, Scala apod., tam bych vždycky šel po IDE.
To je fakt, Vim tímto neřádstvem netrpí. Jedinou nevýhodou je, že Vim vyžaduje, aby programátor uměl programovat. Jenže to se dnes moc nenosí...
-
To je fakt, Vim tímto neřádstvem netrpí. Jedinou nevýhodou je, že Vim vyžaduje, aby programátor uměl programovat. Jenže to se dnes moc nenosí...
Njn, len vim funguje inak ako vacsina editorov/ide. Dump z db ma 10giga a treba ho upravit na servri s pol giga ram? Pre vim ziadny problem. Kdezto VS zacne swapovat aj na stroji s 32 giga ram.
-
To je fakt, Vim tímto neřádstvem netrpí. Jedinou nevýhodou je, že Vim vyžaduje, aby programátor uměl programovat. Jenže to se dnes moc nenosí...
Njn, len vim funguje inak ako vacsina editorov/ide. Dump z db ma 10giga a treba ho upravit na servri s pol giga ram? Pre vim ziadny problem. Kdezto VS zacne swapovat aj na stroji s 32 giga ram.
Vim není IDE a proto nemá jejich nectnosti.
-
Vim není IDE a proto nemá jejich nectnosti.
Hlavne nenatahuje do pamate cely subor ktory edituje.
-
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.
-
To je fakt, Vim tímto neřádstvem netrpí. Jedinou nevýhodou je, že Vim vyžaduje, aby programátor uměl programovat. Jenže to se dnes moc nenosí...
Njn, len vim funguje inak ako vacsina editorov/ide. Dump z db ma 10giga a treba ho upravit na servri s pol giga ram? Pre vim ziadny problem. Kdezto VS zacne swapovat aj na stroji s 32 giga ram.
Vim není IDE a proto nemá jejich nectnosti.
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?
-
To je fakt, Vim tímto neřádstvem netrpí. Jedinou nevýhodou je, že Vim vyžaduje, aby programátor uměl programovat. Jenže to se dnes moc nenosí...
Njn, len vim funguje inak ako vacsina editorov/ide. Dump z db ma 10giga a treba ho upravit na servri s pol giga ram? Pre vim ziadny problem. Kdezto VS zacne swapovat aj na stroji s 32 giga ram.
Vim není IDE a proto nemá jejich nectnosti.
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?
IDE jsou nástroje, které umožňují psát obtížně čitelné aplikace. Bez IDE by mě například ani nenapadlo psát nesouvisející dědičnosti do čtvrtého kolena, s IDE to jde velmi snadno.
-
To je fakt, Vim tímto neřádstvem netrpí. Jedinou nevýhodou je, že Vim vyžaduje, aby programátor uměl programovat. Jenže to se dnes moc nenosí...
Njn, len vim funguje inak ako vacsina editorov/ide. Dump z db ma 10giga a treba ho upravit na servri s pol giga ram? Pre vim ziadny problem. Kdezto VS zacne swapovat aj na stroji s 32 giga ram.
Vim není IDE a proto nemá jejich nectnosti.
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?
IDE jsou nástroje, které umožňují psát obtížně čitelné aplikace. Bez IDE by mě například ani nenapadlo psát nesouvisející dědičnosti do čtvrtého kolena, s IDE to jde velmi snadno.
Na to by sel pro Vim urcite napsat plugin ;-).
-
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.
-
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.
Tohle Vim umí (editor se zvýrazněním kódu, správa projektu, spuštění a překlad projektu, debug, jednotkové testy, správa závislostí, verzování,...) aniž bych ho opouštěl, ale přesto to není IDE.
-
Vim umí (editor se zvýrazněním kódu, správa projektu, spuštění a překlad projektu, debug, jednotkové testy, správa závislostí, verzování,...) aniž bych ho opouštěl, ale přesto to není IDE.
IMHO: Pokud do něj tohle všechno narveš, tak už to fakticky IDE je...
-
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....
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.
-
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í.
-
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....
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.
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.
-
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í.
OK. To je mozna ono... Kdyby se tomu rikalo IDA kde A = aplikace tak bych chapal.
-
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....
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.
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.
Chapu...
Jen dodam, ze moje osobni preference je nastavovat komponenty pomoci konzistentniho a srozumitelneho jazyka (lisp) a ne prez nejaky obskurni klikatka.
-
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.
-
Jen dodam, ze moje osobni preference je nastavovat komponenty pomoci konzistentniho a srozumitelneho jazyka (lisp) a ne prez nejaky obskurni klikatka.
Tohle mi došlo, když jsem si zvykl ve Vimu používat režim ex. Udělá, co mu řeknu a třeba i ve více souborech současně.
-
IDE jsou nástroje, které umožňují psát obtížně čitelné aplikace. Bez IDE by mě například ani nenapadlo psát nesouvisející dědičnosti do čtvrtého kolena, s IDE to jde velmi snadno.
To ale nerobi ide. To je problem medzi klavesnicou a sedatkom. Ohladne suvisloti v zavislostiach su to autorove analyticke schopnosti. Ohladne dekompozicie algoritmu do hierarchie zavislosti autorove abstraktne myslenie. Ani jedno s toho sa neda naucit, maximalne sa to moze naucit imitovat. Potom vznikaju nesuvisiace zavislosti, kruhove zavislosti, diamantove zavislosti. Trendom sa stava viacnasobna dedicnost, traity, tovarnicky a dalsie vylomeniny. A odserie to vzdy ten co programovat vie a preto dostane po takychto lopatach kod na refaktorizaciu. Poznate tu vetu "ono nam to vlastne funguje, len to treba opravit".
Naviach pri IDE aspom mozem "umelcovi" zakazat sshfs, nech to nepatla priamo na servri dovtedy az sa mu zadari. Kdezto ak ma na servri vim...
-
Naviach pri IDE aspom mozem "umelcovi" zakazat sshfs, nech to nepatla priamo na servri dovtedy az sa mu zadari. Kdezto ak ma na servri vim...
Vim na serveru používám zcela běžně. Ovšem v adresáři pro vývoj, kde mám i testy. Do produkce to jde standardně přes deploy.
-
Vim na serveru používám zcela běžně. Ovšem v adresáři pro vývoj, kde mám i testy. Do produkce to jde standardně přes deploy.
Jj, ak clovek vie co s tym ma robit, tak je to bezpecne. Ako, nezalezi na editore, jazyku, to je stale len nastroj.
To ci je ten nastroj bezpecny zavisi len od toho kto a ako ho pouziva.
Cize C je nebezpecne? Nie, nebezpecny je patlal ktori pri tom sedel a skutocnost ze mu nahradite C rustom na tom nic nezmeni.
Typek paltla kod v IDE. Budte si isty ze rovnako to bude patlat aj v notepade alebo vo vime.
Veta "Nastroj (jazyk, ide, etc) nepouzivam, pretoze nie je bezpecny." vlastne vzdy znamena, ze ten clovek bude nebezpecny nech mu date k dispozicii akykolvek nastroj.
-
Naviach pri IDE aspom mozem "umelcovi" zakazat sshfs, nech to nepatla priamo na servri dovtedy az sa mu zadari. Kdezto ak ma na servri vim...
Vim na serveru používám zcela běžně. Ovšem v adresáři pro vývoj, kde mám i testy. Do produkce to jde standardně přes deploy.
Btw, ja tiez casto vyvijam na servri, akurat ze ten server mam u seba na stroji vo virtuale. Nie som tak zavisly na tom ci mi nepada net...
-
Vim na serveru používám zcela běžně. Ovšem v adresáři pro vývoj, kde mám i testy. Do produkce to jde standardně přes deploy.
Btw, ja tiez casto vyvijam na servri, akurat ze ten server mam u seba na stroji vo virtuale. Nie som tak zavisly na tom ci mi nepada net...
Ten svůj server mám několik set km daleko a také to není žádná hrůza. Když spadne net, tak po nahození plynule pokračuji tam, kde jsem přestal - nepřijdu ani o jeden znak.
-
Vim na serveru používám zcela běžně. Ovšem v adresáři pro vývoj, kde mám i testy. Do produkce to jde standardně přes deploy.
Btw, ja tiez casto vyvijam na servri, akurat ze ten server mam u seba na stroji vo virtuale. Nie som tak zavisly na tom ci mi nepada net...
Ten svůj server mám několik set km daleko a také to není žádná hrůza. Když spadne net, tak po nahození plynule pokračuji tam, kde jsem přestal - nepřijdu ani o jeden znak.
O tom nepochybujem(staci vediet pouzivat screen alebo tmux), mne ide skor o prestoje ktore sposobi nedostupnost spojenia (optika k chalupe by ma vysla majlant :)
-
Ten svůj server mám několik set km daleko a také to není žádná hrůza. Když spadne net, tak po nahození plynule pokračuji tam, kde jsem přestal - nepřijdu ani o jeden znak.
O tom nepochybujem(staci vediet pouzivat screen alebo tmux), mne ide skor o prestoje ktore sposobi nedostupnost spojenia (optika k chalupe by ma vysla majlant :)
Mám dvě nezávislá připojení, takže výpadky nemívám.
-
Mám dvě nezávislá připojení, takže výpadky nemívám.
Podstata nie je v tom ci mas ten dev server vzdialene alebo lokalne. To je uplne jedno. Dev server je skor vyhoda. Nemusis vsetky zavislosti prostredia instalovat na lokalny disk.
Problem je skor to ze su ludia, ktori si mountnu adresar zo servra v ostrej prevadzke do lokalneho adresara a idu metodou pokus-omyl. To ze taky ludia su, je realita, mal som tu cest omnoho castejsie nez by mi bolo mile.
-
Cize C je nebezpecne? Nie, nebezpecny je patlal ktori pri tom sedel a skutocnost ze mu nahradite C rustom na tom nic nezmeni.
A ty sedáváš při čem? Kromě ohně na salaši teda...
-
Cize C je nebezpecne? Nie, nebezpecny je patlal ktori pri tom sedel a skutocnost ze mu nahradite C rustom na tom nic nezmeni.
A ty sedáváš při čem? Kromě ohně na salaši teda...
Zase dalsi debilenko, co ho drzi iluzia o tom ze ma urazi narazkou na moju narodnost :D Keby si aspom bol originalny, ale to by si potreboval byt chytrejsi aby si vymyslel nieco ine ako si uz nescitane krat cital... Ale keby si bol chytrejsi, tak by si vedel v C pisat bezpecny soft. Pripadne v Ade, alebo spark...
Btw, v com pisem som do tejto diskusie uz pisal. Teda mensiu cast. Aj tvoje programovanie vyzera tak ako tvoje komentare? Ci aspom tam si v kontexte?
-
Ale keby si bol chytrejsi, tak by si vedel v C pisat bezpecny soft. Pripadne v Ade, alebo spark...
Existence Ady dokazuje, že C fakt není až tak bezpečný jazyk. Existence Rustu dokazuje, že Ada fakt není až tak suprově navržený jazyk. Existence Johna Carmacka dokazuje, že Tvoje bludy o bezpečném C jsou silácké řeči bez sebereflexe.
-
Cize C je nebezpecne? Nie, nebezpecny je patlal ktori pri tom sedel a skutocnost ze mu nahradite C rustom na tom nic nezmeni.
A ty sedáváš při čem? Kromě ohně na salaši teda...
Zase dalsi debilenko, co ho drzi iluzia o tom ze ma urazi narazkou na moju narodnost :D Keby si aspom bol originalny, ale to by si potreboval byt chytrejsi aby si vymyslel nieco ine ako si uz nescitane krat cital... Ale keby si bol chytrejsi, tak by si vedel v C pisat bezpecny soft. Pripadne v Ade, alebo spark...
Cha... a ja tu hlasku se salasi vubec nepochopil :-).
Ale dojit mi to mohlo. Mel jsem kdysi jednoho kolegu co nesnasel slovaky a hledal kazdou moznost jak je urazit.
Po case sem se dozvedel, ze to bylo proto ze mu slovak prebral kluka.
Nicmene zpet k bezpecnosti jazyku.
Nevidim nadeji ze by se poptavka po programatorech mela v nejblizsi dobe snizit. Takze musime pocitat s tim, ze bude v oboru cim dal tim vic nezkusenych a nekvalifikovanych lidi.
Tudiz potreba jazyku, ktery bude chranit programatory a hlavne uzivatele jejich SW pred nebezpecim je realna.
A zrovna C nema snahu nejak nekoho chranit. A je to tak dobre, protoze C nema v rukou obycejnych smrtelniku co delat.
A studovanym odbornikum by ty "pomucky a chranice" stejne jen prekazeli....
Takze rozdily tam jsou.
-
Nicmene zpet k bezpecnosti jazyku.
Nevidim nadeji ze by se poptavka po programatorech mela v nejblizsi dobe snizit. Takze musime pocitat s tim, ze bude v oboru cim dal tim vic nezkusenych a nekvalifikovanych lidi.
Tudiz potreba jazyku, ktery bude chranit programatory a hlavne uzivatele jejich SW pred nebezpecim je realna.
A zrovna C nema snahu nejak nekoho chranit. A je to tak dobre, protoze C nema v rukou obycejnych smrtelniku co delat.
A studovanym odbornikum by ty "pomucky a chranice" stejne jen prekazeli....
Takze rozdily tam jsou.
Chceš teď říct třeba to, že OpenSSL programovali nějací podřadní programátoři, když se v něm objevilo tolik chyb?
-
Nicmene zpet k bezpecnosti jazyku.
Nevidim nadeji ze by se poptavka po programatorech mela v nejblizsi dobe snizit. Takze musime pocitat s tim, ze bude v oboru cim dal tim vic nezkusenych a nekvalifikovanych lidi.
Tudiz potreba jazyku, ktery bude chranit programatory a hlavne uzivatele jejich SW pred nebezpecim je realna.
A zrovna C nema snahu nejak nekoho chranit. A je to tak dobre, protoze C nema v rukou obycejnych smrtelniku co delat.
A studovanym odbornikum by ty "pomucky a chranice" stejne jen prekazeli....
Takze rozdily tam jsou.
Chceš teď říct třeba to, že OpenSSL programovali nějací podřadní programátoři, když se v něm objevilo tolik chyb?
Nechci.
-
Ale keby si bol chytrejsi, tak by si vedel v C pisat bezpecny soft. Pripadne v Ade, alebo spark...
Existence Ady dokazuje, že C fakt není až tak bezpečný jazyk. Existence Rustu dokazuje, že Ada fakt není až tak suprově navržený jazyk. Existence Johna Carmacka dokazuje, že Tvoje bludy o bezpečném C jsou silácké řeči bez sebereflexe.
Na trolla by se nemělo reagovat, i kdyby náhodou nějakou sebereflexi ukázal ;) Zvlášť když nechápe rozdíl mezi C a Rustem...
Ono to je celé o tom mít hodně muziky za málo peněz, Rust, Go, Swift atd. oproti C prostě přináší hlavně komfort. Ale na tom se asi shodneme.
-
Chceš teď říct třeba to, že OpenSSL programovali nějací podřadní programátoři, když se v něm objevilo tolik chyb?
Zrovna kryptografie je IMHO trochu specifická, tady má slovo "bezpečnost" jiný (resp. širší) význam. Navíc jim tam NSA schválně zanášela chyby...
-
Ale keby si bol chytrejsi, tak by si vedel v C pisat bezpecny soft. Pripadne v Ade, alebo spark...
Existence Ady dokazuje, že C fakt není až tak bezpečný jazyk. Existence Rustu dokazuje, že Ada fakt není až tak suprově navržený jazyk. Existence Johna Carmacka dokazuje, že Tvoje bludy o bezpečném C jsou silácké řeči bez sebereflexe.
Na trolla by se nemělo reagovat, i kdyby náhodou nějakou sebereflexi ukázal ;) Zvlášť když nechápe rozdíl mezi C a Rustem...
Ano, nereagovat by bylo v mnoha případech nejlepší. Nepříjemné je, že pak podobné bludy někdo méně znalý vezme vážně.
Ono to je celé o tom mít hodně muziky za málo peněz, Rust, Go, Swift atd. oproti C prostě přináší hlavně komfort. Ale na tom se asi shodneme.
Určitě. Byl bych ale ostřejší - psát programy v nízkoúrovňovém jazyku je ve většině případů nesmyslně drahé. ;)
-
Ale keby si bol chytrejsi, tak by si vedel v C pisat bezpecny soft. Pripadne v Ade, alebo spark...
Existence Ady dokazuje, že C fakt není až tak bezpečný jazyk. Existence Rustu dokazuje, že Ada fakt není až tak suprově navržený jazyk. Existence Johna Carmacka dokazuje, že Tvoje bludy o bezpečném C jsou silácké řeči bez sebereflexe.
Existencia Ady spociva, v tom ze us ministerstvo obrany, potrebovalo jazyk ktory bude natolko univerzalny, ze nebudu musiet riesit kod v niecom inom. Ten isty jazyk pre unix, linux, widle, rtos... Skompilujem v tom program pre x86, rovnako pre ARM a naviac aj pre mc pic. Je dobre citatelny aj pre neprogramatora. To ze ma vysoke naroky na programatora, to by som tiez bral ako vyhodu i ked to nie je zamerom.
Pcham ti tu ze by si sa mal zacat ucit v Ade? Nie. Preco ty pchas Rust inym ludom. To si fakt myslis ze je tak zazracny. Vecsina ludi ti aj tak odporuci ze by si si ho mal pchat medzi polky.
Ecistencia Rustu spociva v tom ze programatori v C su drahy ak su schopny. Kdezto najat lopatu, ktorej vynada prekladac, miesto draheho seniora, to je snom kazdeho investora do IT projektu... Co myslis preco sa C zmrvilo na C++, alebo pascal na delphi?
-
Ano, nereagovat by bylo v mnoha případech nejlepší. Nepříjemné je, že pak podobné bludy někdo méně znalý vezme vážně.
Takových bludů je plný internet, to nejde "bojovat" proti všem kravinám, co kdo někde vyplodí...
-
Ono to je celé o tom mít hodně muziky za málo peněz, Rust, Go, Swift atd. oproti C prostě přináší hlavně komfort. Ale na tom se asi shodneme.
Určitě. Byl bych ale ostřejší - psát programy v nízkoúrovňovém jazyku je ve většině případů nesmyslně drahé. ;)
Ano. To ani není ostřejší, jen jiný úhel pohledu :)
Stěžejní je to "ve většině případů".
-
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í.
-
Vecsina ludi ti aj tak odporuci ze by si si ho mal pchat medzi polky.
Oslňující úroveň intelektuální a jazyková. Nauč se aspoň vlastní rodný jazyk, kašpare.
-
Pcham ti tu ze by si sa mal zacat ucit v Ade? Nie. Preco ty pchas Rust inym ludom. To si fakt myslis ze je tak zazracny.
Nikomu ho "nepchám", normálně píšu, že ho používám a jaké má podle mě silné stránky. V tomto konkrétním tématu se na to navíc někdo ptal. Pokud máš něco o Adě a bude to mít hlavu a patu, rád si to přečtu a nebudu psát, že někomu něco "pcháš".
Ecistencia Rustu spociva v tom ze programatori v C su drahy ak su schopny. Kdezto najat lopatu, ktorej vynada prekladac, miesto draheho seniora, to je snom kazdeho investora do IT projektu... Co myslis preco sa C zmrvilo na C++, alebo pascal na delphi?
Pascal není moje parketa. C++ je velice silný jazyk a pokud nechápeš, v čem je lepší, je to smutné.
-
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í.
Su chyby z nepozornosti, su chyby sposobene moznostami programatora.
Jeden priklad za vsetky, senior by mal chapat ze ak ma pri dedicnosti byt dodrzane pravidlo zamenitelnosti, tak metoda potomka MUSI mat rovnake parametre, ako metoda predka. Lenze ten senior(k tomu sa dopatlal casom, nie znalostami) nechape ako tam ten parameter moze dostat. Clovek mu to vysvetli a hadaj co najde pri najblizsom code review.
Obdobnych pripadov chyb ktore nevznikly z nepozornosti ale tym ze programatora dnes hocikto, mam vcelku dost...
-
Pcham ti tu ze by si sa mal zacat ucit v Ade? Nie. Preco ty pchas Rust inym ludom. To si fakt myslis ze je tak zazracny.
Nikomu ho "nepchám", normálně píšu, že ho používám a jaké má podle mě silné stránky. V tomto konkrétním tématu se na to navíc někdo ptal. Pokud máš něco o Adě a bude to mít hlavu a patu, rád si to přečtu a nebudu psát, že někomu něco "pcháš".
Ecistencia Rustu spociva v tom ze programatori v C su drahy ak su schopny. Kdezto najat lopatu, ktorej vynada prekladac, miesto draheho seniora, to je snom kazdeho investora do IT projektu... Co myslis preco sa C zmrvilo na C++, alebo pascal na delphi?
Pascal není moje parketa. C++ je velice silný jazyk a pokud nechápeš, v čem je lepší, je to smutné.
C++ je velice silny jazyk... tak neviem ci mam dat na teba, alebo na ludi co prispievaju do jadra. Alebo tych co prispievaju do postgres... asi to nechapu rovnako ako ja. Ja som spokojny ze funkcie do postgresu nemusim pisat v C++ ak mi uz na poziadavky nepasuje plsql...
-
C++ je velice silny jazyk... tak neviem ci mam dat na teba, alebo na ludi co prispievaju do jadra. Alebo tych co prispievaju do postgres... asi to nechapu rovnako ako ja. Ja som spokojny ze funkcie do postgresu nemusim pisat v C++ ak mi uz na poziadavky nepasuje plsql...
LOL a to, že se ten jazyk nepoužívá v jednom nebo druhém konkrétním produktu, má být důkaz čeho?
-
Vecsina ludi ti aj tak odporuci ze by si si ho mal pchat medzi polky.
Oslňující úroveň intelektuální a jazyková. Nauč se aspoň vlastní rodný jazyk, kašpare.
Co narobim, me sa uci lahko matika, fyzika, chemia a dalsie veci ktore treba hlavne pochopit. Nedokazem sprtat, bez toho aby to bolo mozno pochopit. Ale tebe to evidentne ide...
-
C++ je velice silny jazyk... tak neviem ci mam dat na teba, alebo na ludi co prispievaju do jadra. Alebo tych co prispievaju do postgres... asi to nechapu rovnako ako ja. Ja som spokojny ze funkcie do postgresu nemusim pisat v C++ ak mi uz na poziadavky nepasuje plsql...
LOL a to, že se ten jazyk nepoužívá v jednom nebo druhém konkrétním produktu, má být důkaz čeho?
Ze projekty ktore za nieco stoja, maju schopnych programatorov dostatok. Nemusia brat odpad...
-
C++ je velice silny jazyk... tak neviem ci mam dat na teba, alebo na ludi co prispievaju do jadra. Alebo tych co prispievaju do postgres... asi to nechapu rovnako ako ja. Ja som spokojny ze funkcie do postgresu nemusim pisat v C++ ak mi uz na poziadavky nepasuje plsql...
LOL a to, že se ten jazyk nepoužívá v jednom nebo druhém konkrétním produktu, má být důkaz čeho?
Ze projekty ktore za nieco stoja, maju schopnych programatorov dostatok. Nemusia brat odpad...
Ty jsi fakt marný. Já si ani nemyslím, že jsi troll...
-
Nikomu ho "nepchám", normálně píšu, že ho používám a jaké má podle mě silné stránky. V tomto konkrétním tématu se na to navíc někdo ptal. Pokud máš něco o Adě a bude to mít hlavu a patu, rád si to přečtu a nebudu psát, že někomu něco "pcháš".
To sa potom nemusis bat ze link na tento tvoj vyrok prilepim vsade kde nechapes preco autor clanku nepouzil rust ale radsej C...
-
C++ je velice silný jazyk a pokud nechápeš, v čem je lepší, je to smutné.
Možná až příliš silný, ne? IMHO je v něm tolik WTF věcí, že zlatý Rust. Ale to je jen můj osobní názor (resp. dojem). Možná C++47 nebo něco takového bude už lepší, ale zatím máme s bídou C++20...
-
Ty jsi fakt marný. Já si ani nemyslím, že jsi troll...
Sam si marny, ako series ma uz dlhsiu dobu. Tych diskusii, ktore trolis rustom jak agent s teplou vodou, je fakt moc. Pritom by stacilo si uvedomit, ze ak musis ludi presviedcat aky je rust skvely, tak o to zrejme nestoja. Ak by stali tak by boli tvoje intervencie zbytocne.
-
C++ je velice silný jazyk a pokud nechápeš, v čem je lepší, je to smutné.
Možná až příliš silný, ne? IMHO je v něm tolik WTF věcí, že zlatý Rust. Ale to je jen můj osobní názor (resp. dojem). Možná C++47 nebo něco takového bude už lepší, ale zatím máme s bídou C++20...
Já nejsem milovníkem C++. Ale kdybych si mohl vybrat, jestli můžu psát one-man projekt v C nebo C++, skoro vždycky bych šel do C++. Vybral bych si, samozřejmě, podmnožinu jazyka, která by mi vyhovovala. Kdybych si měl vybrat mezi C++ a Rustem, vybral bych si samozřejmě Rust, pokud bych nenarazil na problém s nedostatkem knihoven, který by se nedal rozumně vyřešit ani s FFI.
-
C++ je velice silny jazyk... tak neviem ci mam dat na teba, alebo na ludi co prispievaju do jadra. Alebo tych co prispievaju do postgres... asi to nechapu rovnako ako ja. Ja som spokojny ze funkcie do postgresu nemusim pisat v C++ ak mi uz na poziadavky nepasuje plsql...
LOL a to, že se ten jazyk nepoužívá v jednom nebo druhém konkrétním produktu, má být důkaz čeho?
Ze projekty ktore za nieco stoja, maju schopnych programatorov dostatok. Nemusia brat odpad...
Ty jsi fakt marný. Já si ani nemyslím, že jsi troll...
Je to javaman blahé paměti, jen teď píše pseudoslovensky... :D
-
Ty jsi fakt marný. Já si ani nemyslím, že jsi troll...
Sam si marny, ako series ma uz dlhsiu dobu. Tych diskusii, ktore trolis rustom jak agent s teplou vodou, je fakt moc. Pritom by stacilo si uvedomit, ze ak musis ludi presviedcat aky je rust skvely, tak o to zrejme nestoja. Ak by stali tak by boli tvoje intervencie zbytocne.
Už jsi to psal, mohl bys to zhudebnit, refrén máš. Drumbľa, fujara, ideš! ;D ;D ;D
-
C++ je velice silný jazyk a pokud nechápeš, v čem je lepší, je to smutné.
Možná až příliš silný, ne? IMHO je v něm tolik WTF věcí, že zlatý Rust. Ale to je jen můj osobní názor (resp. dojem). Možná C++47 nebo něco takového bude už lepší, ale zatím máme s bídou C++20...
Já nejsem milovníkem C++. Ale kdybych si mohl vybrat, jestli můžu psát one-man projekt v C nebo C++, skoro vždycky bych šel do C++. Vybral bych si, samozřejmě, podmnožinu jazyka, která by mi vyhovovala. Kdybych si měl vybrat mezi C++ a Rustem, vybral bych si samozřejmě Rust, pokud bych nenarazil na problém s nedostatkem knihoven, který by se nedal rozumně vyřešit ani s FFI.
Tohle mě štve na Go, jakmile tam není nějaká knihovna, tak FFI (cgo) tam je dost na houby.
-
Ty jsi fakt marný. Já si ani nemyslím, že jsi troll...
Sam si marny, ako series ma uz dlhsiu dobu. Tych diskusii, ktore trolis rustom jak agent s teplou vodou, je fakt moc. Pritom by stacilo si uvedomit, ze ak musis ludi presviedcat aky je rust skvely, tak o to zrejme nestoja. Ak by stali tak by boli tvoje intervencie zbytocne.
Už jsi to psal, mohl bys to zhudebnit, refrén máš. Drumbľa, fujara, ideš! ;D ;D ;D
A cimbál! :D
-
Argumentum ad hominem.
To je vsetko na co sa zmozete?
Sa divite ze tu mate tolko programatorov z vychodu, pri tej prudkej inteligencii? To ze ich budete urazat vas z biedy nevytrhne ;)
-
Argumentum ad hominem.
To je vsetko na co sa zmozete?
Sa divite ze tu mate tolko programatorov z vychodu, pri tej prudkej inteligencii? To ze ich budete urazat vas z biedy nevytrhne ;)
Fajn, první sloka je taky na světě:
Éj, dolina, dolina, prišli sme vás Čehúňov zachrániť od životného minima... Naučili sme sa Céčko, ja, moj brat aj náš oťécko.
Ref: A vy stále s hen tým Rustom, s*riete ma s bratom Gustom.
---
A od teď už zase budu řešit jenom IDE a C++.
-
Nastudujte si $355 vaseho zakonnika.
Hanobenie naroda, verejna internetova diskusia a vzhladom na to ze ste dvaja, tak minimum su 3 roky ;)
Myslite na to, az narazite na niekohoho so slabsimy nervami a tomu vas nebude luto koli vasej frustracii z C
-
Argumentum ad hominem.
To je vsetko na co sa zmozete?
Sa divite ze tu mate tolko programatorov z vychodu, pri tej prudkej inteligencii? To ze ich budete urazat vas z biedy nevytrhne ;)
Fajn, první sloka je taky na světě:
Éj, dolina, dolina, prišli sme vás Čehúňov zachrániť od životného minima... Naučili sme sa Céčko, ja, moj brat aj náš oťécko.
Ref: A vy stále s hen tým Rustom, s*riete ma s bratom Gustom.
---
A od teď už zase budu řešit jenom IDE a C++.
Už ho nech, nebo se zase pociká ;) Vždyť ani nezná rozdíl mezi dolarem a paragrafem. Nebo to byl jeho roční plat, těžko říct.
-
Argumentum ad hominem.
To je vsetko na co sa zmozete?
Sa divite ze tu mate tolko programatorov z vychodu, pri tej prudkej inteligencii? To ze ich budete urazat vas z biedy nevytrhne ;)
Fajn, první sloka je taky na světě:
Éj, dolina, dolina, prišli sme vás Čehúňov zachrániť od životného minima... Naučili sme sa Céčko, ja, moj brat aj náš oťécko.
Ref: A vy stále s hen tým Rustom, s*riete ma s bratom Gustom.
---
A od teď už zase budu řešit jenom IDE a C++.
Už ho nech, nebo se zase pociká ;) Vždyť ani nezná rozdíl mezi dolarem a paragrafem. Nebo to byl jeho roční plat, těžko říct.
To bol proste preklep.
Ako, nenahlasim to. Ale to ze mate potrebu kopat do niekoho na koho nestacite, len pre to ze do vas kopali vasi kolegovia za vase vytvory v C, to by ste mali riesit s terapeutom. Zmena jazyka vam to nevyriesi.
-
Nastudujte si $355 vaseho zakonnika.
Znam jeno direktivy vesmirneho sboru...
Myslim ze #355 je
"Prvořadou povinností posádky je kontaktovat jiné formy života, vyměňovat si různé informace a pokud je to možné, přivést si je domů. "
-
Nastudujte si $355 vaseho zakonnika.
Znam jeno direktivy vesmirneho sboru...
Myslim ze #355 je
"Prvořadou povinností posádky je kontaktovat jiné formy života, vyměňovat si různé informace a pokud je to možné, přivést si je domů. "
A já myslel, že to je "Bude-li důstojník přistižen, jak očichává sedlo rotopedu v dámské tělocvičně, bude propuštěn bez soudu."
-
Nastudujte si $355 vaseho zakonnika.
Znam jeno direktivy vesmirneho sboru...
Myslim ze #355 je
"Prvořadou povinností posádky je kontaktovat jiné formy života, vyměňovat si různé informace a pokud je to možné, přivést si je domů. "
A já myslel, že to je "Bude-li důstojník přistižen, jak očichává sedlo rotopedu v dámské tělocvičně, bude propuštěn bez soudu."
to je #196156
-
Nastudujte si $355 vaseho zakonnika.
Znam jeno direktivy vesmirneho sboru...
Myslim ze #355 je
"Prvořadou povinností posádky je kontaktovat jiné formy života, vyměňovat si různé informace a pokud je to možné, přivést si je domů. "
Formu života “Braindead walker” jsme úspěšně kontaktovali, ale domů ji nikdo nechce.
-
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.
-
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.
Čím víc typové kontroly (záv. typy) a statické analýzy (například borrow checker), tím lépe. Rust už má generické asociované (přidružené) typy, od toho je k silnému typovému systému jen kousek.
-
Nastudujte si $355 vaseho zakonnika.
Znam jeno direktivy vesmirneho sboru...
Myslim ze #355 je
"Prvořadou povinností posádky je kontaktovat jiné formy života, vyměňovat si různé informace a pokud je to možné, přivést si je domů. "
Formu života “Braindead walker” jsme úspěšně kontaktovali, ale domů ji nikdo nechce.
Myslis ze zaberie pristup, "Ked uz neviem argumentovat, tak budem hejtit ako male dieta"?
Nie je v ktorej pracujes, jedna z tych ktora nemoze najst kvalitnych programatorov? Ak je takych ako ty vo firme viac, tak takymto jednanim spolahlivo zastropujete kvalitu programatorov.
-
Čím víc typové kontroly (záv. typy) a statické analýzy (například borrow checker), tím lépe. Rust už má generické asociované (přidružené) typy, od toho je k silnému typovému systému jen kousek.
Jenže těch jazyků, které skutečně umí dělat typové kontroly, je jen velmi málo. Proto se raději spoléhám na testy, které nejsou tak omezené.
-
Čím víc typové kontroly (záv. typy) a statické analýzy (například borrow checker), tím lépe. Rust už má generické asociované (přidružené) typy, od toho je k silnému typovému systému jen kousek.
Ak v jazyku nie je silny typovy system implementovany uz od zaciatku, tak casom sa tam nevyvinie. To by ludia ziastovai ze novou verziou im uz nejde prelozit stavajuci kod, vedsina ludi pise jazyk tak aby prilakala novych ludi, nie aby odradila povodnych.
-
Jenže těch jazyků, které skutečně umí dělat typové kontroly, je jen velmi málo.
Výběr je dostatečný, i slabší typová kontrola je lepší než žádná.
-
Jenže těch jazyků, které skutečně umí dělat typové kontroly, je jen velmi málo.
Výběr je dostatečný, i slabší typová kontrola je lepší než žádná.
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.
-
Jenže těch jazyků, které skutečně umí dělat typové kontroly, je jen velmi málo.
Výběr je dostatečný, i slabší typová kontrola je lepší než žádná.
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.
Ad PHP, typova kontrola v PHP je obmedzena len na volanie funkcii(metod), v bloku to uz zase mozes spatlat ako chces...
Napriklad <?php
$a = 10 + "15abcd";
echo $a;
vypise 25... aj pri zapnutom strict mode.
-
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.
-
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í?
-
... 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.
Ad PHP, typova kontrola v PHP je obmedzena len na volanie funkcii(metod), v bloku to uz zase mozes spatlat ako chces...
Nikoho nezajímá, co se děje uvnitř metod. Podstatné je, že je splněn kontrakt rozhraní.
-
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? #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?
-
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? #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
-
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? #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?
-
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? #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
-
v dynamickem jazyku ten kod spadne, pokud ho spustis
Vazne? Toto bola ale poziadavka na C++
Vies dat ukazku v dynamickom jazyku, kde deklarujes typ jablcka a typ hrusky a spadne to pri pokuse scitat premenne typu jablcko a typu hruska.
-
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? #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?
Hlavně jen blb řekne, že jabko nebo hruška jsou int. Typový alias v C++ je ekvivalence. Takhle to vypadá, když někdo nezná jazyk, vymyslí si nějaký přiblblý pseudoproblém a pak jej vysvětluje na retardovaném kódu. Oh boy...
-
myslis nieco taketo? #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?
Hlavně jen blb řekne, že jabko nebo hruška jsou int. Typový alias v C++ je ekvivalence. Takhle to vypadá, když někdo nezná jazyk, vymyslí si nějaký přiblblý pseudoproblém a pak jej vysvětluje na retardovaném kódu. Oh boy...
Super, tak teď konečně možná zjistíme, co je typ a co ne. A možná si sem tam někdo uvědomí, jaký je rozdíl mezi "nedostatkem jazyka" a nedostatečným vlastním pochopením. Třikrát sláva!
-
myslis nieco taketo? #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?
Hlavně jen blb řekne, že jabko nebo hruška jsou int. Typový alias v C++ je ekvivalence. Takhle to vypadá, když někdo nezná jazyk, vymyslí si nějaký přiblblý pseudoproblém a pak jej vysvětluje na retardovaném kódu. Oh boy...
Super, tak teď konečně možná zjistíme, co je typ a co ne. A možná si sem tam někdo uvědomí, jaký je rozdíl mezi "nedostatkem jazyka" a nedostatečným vlastním pochopením. Třikrát sláva!
Sémantika typů závisí na konkrétním jazyce, Go má taky něco jako typedef, ale ekvivalence to není.
BTW souhlasím s tím, že Braindead walker není troll. Je jen extrémně tupý lopatoid.
-
Sémantika typů závisí na konkrétním jazyce, Go má taky něco jako typedef, ale ekvivalence to není.
BTW souhlasím s tím, že Braindead walker není troll. Je jen extrémně tupý lopatoid.
Jsem rád, že jsme dosáhli shody. ;) Ten rozdíl v Go je každopádně zajímavý.
-
Sémantika typů závisí na konkrétním jazyce, Go má taky něco jako typedef, ale ekvivalence to není.
BTW souhlasím s tím, že Braindead walker není troll. Je jen extrémně tupý lopatoid.
Jsem rád, že jsme dosáhli shody. ;) Ten rozdíl v Go je každopádně zajímavý.
Jo, je, umožní jim to přidávat metody k existujícím typům. Ty sice umělo dávno třeba ObjC bez aliasů, nicméně Go má trochu jinou filosofii (a nemá klasický enum, takže tímto se to obchází).
P.S. Z mainstreamových jazyků má stejně nejsilnější typový systém Rust :) A reifikované lifetimy k tomu.
-
Sémantika typů závisí na konkrétním jazyce, Go má taky něco jako typedef, ale ekvivalence to není.
BTW souhlasím s tím, že Braindead walker není troll. Je jen extrémně tupý lopatoid.
Jsem rád, že jsme dosáhli shody. ;) Ten rozdíl v Go je každopádně zajímavý.
Jo, je, umožní jim to přidávat metody k existujícím typům. Ty sice umělo dávno třeba ObjC bez aliasů, nicméně Go má trochu jinou filosofii (a nemá klasický enum, takže tímto se to obchází).
P.S. Z mainstreamových jazyků má stejně nejsilnější typový systém Rust :) A reifikované lifetimy k tomu.
A dve detinske lopaty nepoznaju rozdiel medzi typedf a using...
-
nepoznaju rozdiel medzi typedf a using...
Nauč se anglicky a pak si přečti standard, čeká tě překvápko, somárik.
-
nepoznaju rozdiel medzi typedf a using...
Nauč se anglicky a pak si přečti standard, čeká tě překvápko, somárik.
Co sa tam dozviem, ze keyword pre deklaraciu typu, pri niektorych typoch v skutocnosti nedeklaruje typ, ale vytvara alias? Proste je to nedostatok, ktory sa prejavuje tym ze C++, je typovo silne s velmi velkou rezervou.
-
nepoznaju rozdiel medzi typedf a using...
Nauč se anglicky a pak si přečti standard, čeká tě překvápko, somárik.
Cože, on že by měl něco šprtat? Vždyť stačí znát úplné základy angličtiny a vědět, že C++ je zkažené C.
-
nepoznaju rozdiel medzi typedf a using...
Nauč se anglicky a pak si přečti standard, čeká tě překvápko, somárik.
Co sa tam dozviem, ze keyword pre deklaraciu typu, pri niektorych typoch v skutocnosti nedeklaruje typ, ale vytvara alias? Proste je to nedostatok, ktory sa prejavuje tym ze C++, je typovo silne s velmi velkou rezervou.
Ano. Rozhodl ses zatlouct hřebík vidličkou a divíš se, že to kladivo moc nefunguje.
-
nepoznaju rozdiel medzi typedf a using...
Nauč se anglicky a pak si přečti standard, čeká tě překvápko, somárik.
Cože, on že by měl něco šprtat? Vždyť stačí znát úplné základy angličtiny a vědět, že C++ je zkažené C.
Jo, on zná standard určitě nazpaměť, I kid you not :)
-
nepoznaju rozdiel medzi typedf a using...
Nauč se anglicky a pak si přečti standard, čeká tě překvápko, somárik.
Co sa tam dozviem, ze keyword pre deklaraciu typu, pri niektorych typoch v skutocnosti nedeklaruje typ, ale vytvara alias? Proste je to nedostatok, ktory sa prejavuje tym ze C++, je typovo silne s velmi velkou rezervou.
Ano. Rozhodl ses zatlouct hřebík vidličkou a divíš se, že to kladivo moc nefunguje.
Alebo skor kladivo, ktore v niektorych pripadoch funguje ako vydlicka, podla tvaru klinca. To je typedef.
-
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? #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?
-
nepoznaju rozdiel medzi typedf a using...
Nauč se anglicky a pak si přečti standard, čeká tě překvápko, somárik.
Co sa tam dozviem, ze keyword pre deklaraciu typu, pri niektorych typoch v skutocnosti nedeklaruje typ, ale vytvara alias? Proste je to nedostatok, ktory sa prejavuje tym ze C++, je typovo silne s velmi velkou rezervou.
Ano. Rozhodl ses zatlouct hřebík vidličkou a divíš se, že to kladivo moc nefunguje.
Alebo skor kladivo, ktore v niektorych pripadoch funguje ako vydlicka, podla tvaru klinca. To je typedef.
Teď se mi zatajil dech, bojím se, co se dozvím nového. Že když použiju typedef u struktury proto, že autoři C by mě jinak nutili furt dokola psát "struct", bude struct A něco jiného než struct B a tudíž i ty aliasy ukazují každý jinam? To fakt není zásluha typedefu.
-
Ale ty testy musím napsat, že? A musím je napsat správně, že?
Tak pisat testy je velmi dobry zvyk...
Ale nie koli tomu na co nie su urcene. Napr. na typovu kontrolu. Napises kniznicu/balicek ktory exportuje/publikuje metodu. Ako napises test pre ten balik, ktory by kontroloval typy s ktorymi zavola tu metodu niekto, co tu kniznicu pouzije? Vazne by som ten kod rad videl...
-
Ale ty testy musím napsat, že? A musím je napsat správně, že?
Ale vy jste se ptal, jak pomohou testy. Na tuhle chybu prijde kazdy linter, k tomu nejsou treba testy. Ale staci i uplne trivialni test, ktery pokryje ten kod.
-
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? #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?
To nevadí, prostě potřebuješ testy na testy. Stačí spočetně mnoho úrovní testů a metatestů ;)
-
Teď se mi zatajil dech, bojím se, co se dozvím nového.
Není nad to se dovzdělat :)
-
Ale ty testy musím napsat, že? A musím je napsat správně, že?
Ale vy jste se ptal, jak pomohou testy. Na tuhle chybu prijde kazdy linter, k tomu nejsou treba testy. Ale staci i uplne trivialni test, ktery pokryje ten kod.
Tak to prr! Na nic takového jsem neptal. Já se jen opatrně ptal, co skutečnost, že to spadne dokazuje. Ty říkáš, že na to přijdu při testu. OK, tak ten test teda musím napsat. Nebo musím spustit linter, což je takovej podivnej kříženec mezi statickými typy a automatickými testy - ok.
Každopádně mi furt nedochází, v čem by to testování mělo být výhodnější, nebo co jako. (Bez ohledu na to, že už tu jedno vlákno na toto téma bylo, kde to bylo do mrti rozebráno. Ale někdo si chce tu slepou uličku asi prolézt znova. No, buduž mu přáno.)
-
Teď se mi zatajil dech, bojím se, co se dozvím nového.
Není nad to se dovzdělat :)
Proste v niketorych jazykoch nedokazete na urovni typovej kontroly zabezpecit aby nebolo mozne scitat CenuSDph a CenuBezDhp, co je proti kontraktu(ktoremu to predpisuje legislativa). V pohode umozni urobit trivialny omyl, tym, ze omylom scitate to co scitat nesmiete, a to vam neodhalia ani testy.
To ze si myslite ze c++ alebo rust su typovo silne jazyky, a uz nic silnejsie byt nemoze, je len dogma, ktorej sa drzite, len pre to ze vase myslenie ma obmedzene hranice, ktore vas dalej nepustia. A ako kazdy uboziak zatazeny dogmou, sa za nu budete donekonecne bit, hoci aj podrazmi.
-
To ze si myslite ze c++ alebo rust su typovo silne jazyky, a uz nic silnejsie byt nemoze, je len dogma, ktorej sa drzite, len pre to ze vase myslenie ma obmedzene hranice, ktore vas dalej nepustia. A ako kazdy uboziak zatazeny dogmou, sa za nu budete donekonecne bit, hoci aj podrazmi.
Fajn. A teď si vygoogli, na co odkazuje přezdívka Idris.
-
To ze si myslite ze c++ alebo rust su typovo silne jazyky, a uz nic silnejsie byt nemoze, je len dogma, ktorej sa drzite, len pre to ze vase myslenie ma obmedzene hranice, ktore vas dalej nepustia. A ako kazdy uboziak zatazeny dogmou, sa za nu budete donekonecne bit, hoci aj podrazmi.
Fajn. A teď si vygoogli, na co odkazuje přezdívka Idris.
Na tazku poruchu sebareflexie? :D
-
To ze si myslite ze c++ alebo rust su typovo silne jazyky, a uz nic silnejsie byt nemoze, je len dogma, ktorej sa drzite, len pre to ze vase myslenie ma obmedzene hranice, ktore vas dalej nepustia. A ako kazdy uboziak zatazeny dogmou, sa za nu budete donekonecne bit, hoci aj podrazmi.
Fajn. A teď si vygoogli, na co odkazuje přezdívka Idris.
Btw, vzhladom na tuto poznamku a to ako si vas dvoch priebezne analyzujem. Idris je tvoj imaginarny kamarat? Meliete rovnake hovna a teraz naviac poukazujes na to ze idris znamena prorok...
-
naviac poukazujes na to ze idris znamena prorok...
[facepalm]
-
naviac poukazujes na to ze idris znamena prorok...
[facepalm]
Fackuj sa kolko chces, k tejto poznamke si vystrihol iba vetu s dogmou...
-
naviac poukazujes na to ze idris znamena prorok...
[facepalm]
Ještě větší retard, než jsme se obávali, hejže? ::)
-
naviac poukazujes na to ze idris znamena prorok...
[facepalm]
Ještě větší retard, než jsme se obávali, hejže? ::)
Hele já nevím. Mě přijde, že je to dobou. Já takovýho kluka měl doma (na návštěvě). On je hodnej, což o to. Ale jako nějaká rozvaha, logické uvažování, přehled ale třeba i pud sebezáchovy jako vůbec. Přece nepudu do sporu, kde tuším, že mohu prohrát?! A ještě s takovým křikem. A oni tito lidé snad opravdu věří, že když budou hodně, ale fakt hodně křičet, tak že si tu pravdu vykřičí. Moc netuším v co doufají, že dosáhnou.
-
naviac poukazujes na to ze idris znamena prorok...
[facepalm]
Ještě větší retard, než jsme se obávali, hejže? ::)
Hele já nevím. Mě přijde, že je to dobou. Já takovýho kluka měl doma (na návštěvě). On je hodnej, což o to. Ale jako nějaká rozvaha, logické uvažování, přehled ale třeba i pud sebezáchovy jako vůbec. Přece nepudu do sporu, kde tuším, že mohu prohrát?! A ještě s takovým křikem. A oni tito lidé snad opravdu věří, že když budou hodně, ale fakt hodně křičet, tak že si tu pravdu vykřičí. Moc netuším v co doufají, že dosáhnou.
Hmm. Jestli to tak opravdu je, tak je to dost smutné.
-
naviac poukazujes na to ze idris znamena prorok...
[facepalm]
Ještě větší retard, než jsme se obávali, hejže? ::)
Tak si zadaj do google Idris, co ti najde. Na kolkej strane vysledkov by ta uzastna info mala byt? 10k a nejake drobne?
-
naviac poukazujes na to ze idris znamena prorok...
[facepalm]
Ještě větší retard, než jsme se obávali, hejže? ::)
Tak si zadaj do google Idris, co ti najde. Na kolkej strane vysledkov by ta uzastna info mala byt? 10k a nejake drobne?
https://www.root.cz/zpravicky/vysla-nova-verze-jazyka-idris-2/
-
Hele já nevím. Mě přijde, že je to dobou. Já takovýho kluka měl doma (na návštěvě). On je hodnej, což o to. Ale jako nějaká rozvaha, logické uvažování, přehled ale třeba i pud sebezáchovy jako vůbec. Přece nepudu do sporu, kde tuším, že mohu prohrát?! A ještě s takovým křikem. A oni tito lidé snad opravdu věří, že když budou hodně, ale fakt hodně křičet, tak že si tu pravdu vykřičí. Moc netuším v co doufají, že dosáhnou.
Hmm. Jestli to tak opravdu je, tak je to dost smutné.
Usilovně makám na tom, abych to moje děti nechytli :)
Ale to už jsme fakt daleko od tématu "Investor pro C++ IDE" :)
-
naviac poukazujes na to ze idris znamena prorok...
[facepalm]
Ještě větší retard, než jsme se obávali, hejže? ::)
Hele já nevím. Mě přijde, že je to dobou. Já takovýho kluka měl doma (na návštěvě). On je hodnej, což o to. Ale jako nějaká rozvaha, logické uvažování, přehled ale třeba i pud sebezáchovy jako vůbec. Přece nepudu do sporu, kde tuším, že mohu prohrát?! A ještě s takovým křikem. A oni tito lidé snad opravdu věří, že když budou hodně, ale fakt hodně křičet, tak že si tu pravdu vykřičí. Moc netuším v co doufají, že dosáhnou.
Krikom, urazkami, vytrhavanim z kontextu a tak podobne... Njn, s tym sa da uhrat iba iluzia vyhry :D
-
Hele já nevím. Mě přijde, že je to dobou. Já takovýho kluka měl doma (na návštěvě). On je hodnej, což o to. Ale jako nějaká rozvaha, logické uvažování, přehled ale třeba i pud sebezáchovy jako vůbec. Přece nepudu do sporu, kde tuším, že mohu prohrát?! A ještě s takovým křikem. A oni tito lidé snad opravdu věří, že když budou hodně, ale fakt hodně křičet, tak že si tu pravdu vykřičí. Moc netuším v co doufají, že dosáhnou.
Hmm. Jestli to tak opravdu je, tak je to dost smutné.
Usilovně makám na tom, abych to moje děti nechytli :)
Nápodobně. Tak ať se daří (nám oběma).
-
naviac poukazujes na to ze idris znamena prorok...
[facepalm]
Ještě větší retard, než jsme se obávali, hejže? ::)
Tak si zadaj do google Idris, co ti najde. Na kolkej strane vysledkov by ta uzastna info mala byt? 10k a nejake drobne?
https://www.root.cz/zpravicky/vysla-nova-verze-jazyka-idris-2/
Dřív si ta tupá část společnosti všechno googlila. Teď už máme ještě nižší “kastu”, která neumí ani googlit.
-
naviac poukazujes na to ze idris znamena prorok...
[facepalm]
Ještě větší retard, než jsme se obávali, hejže? ::)
Tak si zadaj do google Idris, co ti najde. Na kolkej strane vysledkov by ta uzastna info mala byt? 10k a nejake drobne?
https://www.root.cz/zpravicky/vysla-nova-verze-jazyka-idris-2/
Co by to malo dokazat? Ze dotycny je uplny blb, kedze tu rozporuje to co som povodne tvrdil. A sice to, ze je dolezita typova kontrola pri preklade, nie pri behu programu.
-
Každopádně mi furt nedochází, v čem by to testování mělo být výhodnější, nebo co jako.
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. Proto po každé kompilaci spouštím testy, abych viděl, že jednotka dělá to, co má i pro hraníční hodnoty.
-
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ů).
-
Každopádně mi furt nedochází, v čem by to testování mělo být výhodnější, nebo co jako.
Testy dělají to, co typy nesvedou.
Ano, to je pravda. Ano, není to odpověď na otázku.
Typy obvykle nezabrání abych do proměnné měsíc nevložil hodnotu 14, aby se do indexu nedostala hodnota mimo rozsah pole. Proto po každé kompilaci spouštím testy, abych viděl, že jednotka dělá to, co má i pro hraníční hodnoty.
Ani s jedním příkladem jsi se netrefil. A přitom by se dali najít příklady, kdy testy krásně sekundují typům, a tedy mají svůj smysl.
-
Každopádně mi furt nedochází, v čem by to testování mělo být výhodnější, nebo co jako.
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. Proto po každé kompilaci spouštím testy, abych viděl, že jednotka dělá to, co má i pro hraníční hodnoty.
Takze vlastne dany jazyk nema dostatocnu typovu kontrolu, kedze ju musim suplovat testami. Pritom by stacilo type Month is range 1 .. 12;
-
Ale ty testy musím napsat, že? A musím je napsat správně, že?
Ale vy jste se ptal, jak pomohou testy. Na tuhle chybu prijde kazdy linter, k tomu nejsou treba testy. Ale staci i uplne trivialni test, ktery pokryje ten kod.
Tak to prr! Na nic takového jsem neptal. Já se jen opatrně ptal, co skutečnost, že to spadne dokazuje. Ty říkáš, že na to přijdu při testu. OK, tak ten test teda musím napsat. Nebo musím spustit linter, což je takovej podivnej kříženec mezi statickými typy a automatickými testy - ok.
Každopádně mi furt nedochází, v čem by to testování mělo být výhodnější, nebo co jako. (Bez ohledu na to, že už tu jedno vlákno na toto téma bylo, kde to bylo do mrti rozebráno. Ale někdo si chce tu slepou uličku asi prolézt znova. No, buduž mu přáno.)
Linter odhali stejny typ chyb jako kompiler. Testovani odhali jiny typ chyb.
-
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
-
Linter odhali stejny typ chyb jako kompiler.
Odvážné tvrzení. Ale budiž, nebudem se o tom přít.
-
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?
-
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.
-
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.
-
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?
-
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):
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é.
-
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.)
-
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.
-
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.
-
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.
-
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.
-
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 :)
-
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):
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.
-
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.
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.
-
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.
-
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
Pointery jsou taky typované, "hvězdička" v C je v podstatě jen typový operátor a v překladači se s ním dá krásně pracovat (zdraví Hindney a Miler). Zbytek je sice v podstatě pravda, ale nijak nesouvisí s typovým systémem.
-
Pointery jsou taky typované, "hvězdička" v C je v podstatě jen typový operátor a v překladači se s ním dá krásně pracovat (zdraví Hindney a Miler). Zbytek je sice v podstatě pravda, ale nijak nesouvisí s typovým systémem.
Co je to platné, když pak vznikají věci jako
void qsort(void *base, size_t nitems, size_t size, int (*compar)(const void *, const void*))
-
Co je to platné, když pak vznikají věci jako
void qsort(void *base, size_t nitems, size_t size, int (*compar)(const void *, const void*))
Tohle je zrovna nešťastné použití void. Holt bez typových parametrů to jinak nejde a v době vzniku C byly typové systémy primitivní. IMHO je lepší brát C jako "přenositelný asembler", z dnešního pohledu je jeho typový systém směšný (ovšem z dnešního pohledu je směšné kde co z historie IT).
-
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.
Pořád lepší než assembler, který se ani uhlídat nedal.
-
IMHO je lepší brát C jako "přenositelný asembler"...
Jako přenositelný assembler je ho třeba brát s hodně velkou rezervou. Obzvlášť standardní C, ne různé nadstandardní dialekty. :)
V assembleru je třeba brnkačka napsat vnitřnosti :
bool add_overflow (int a, int b, int *res)
{
}
Ve standardním C je to past i pro profíky.
-
IMHO je lepší brát C jako "přenositelný asembler"...
Jako přenositelný assembler je ho třeba brát s hodně velkou rezervou. Obzvlášť standardní C, ne různé nadstandardní dialekty. :)
Které dialekty například?
-
IMHO je lepší brát C jako "přenositelný asembler"...
Jako přenositelný assembler je ho třeba brát s hodně velkou rezervou. Obzvlášť standardní C, ne různé nadstandardní dialekty. :)
Které dialekty například?
Třeba gcc dialekt ve kterém je psaný linux.
-
IMHO je lepší brát C jako "přenositelný asembler"...
Jako přenositelný assembler je ho třeba brát s hodně velkou rezervou. Obzvlášť standardní C, ne různé nadstandardní dialekty. :)
Které dialekty například?
Třeba gcc dialekt ve kterém je psaný linux.
To nevím, jestli je nadstandardní. Možná nadstandardní guláš :)
Mně se z rozšíření C líbí akorát bloky, ale to je čistě osobní preference a navíc víceméně irelevantní, protože na naprostou většinu projektů se hodí jiné jazyky vyšší úrovně.
-
IMHO je lepší brát C jako "přenositelný asembler"...
Jako přenositelný assembler je ho třeba brát s hodně velkou rezervou. Obzvlášť standardní C, ne různé nadstandardní dialekty. :)
Které dialekty například?
Třeba gcc dialekt ve kterém je psaný linux.
To nevím, jestli je nadstandardní. Možná nadstandardní guláš :)
Mně se z rozšíření C líbí akorát bloky, ale to je čistě osobní preference a navíc víceméně irelevantní, protože na naprostou většinu projektů se hodí jiné jazyky vyšší úrovně.
Tím nadstandardem jsem myslel čistě nad rámec standardu :) Prostě jeden každý překladač C, co jsem měl kdy v rukou poskytoval věci, co standardní C neposkytuje nebo nezaručuje, jinak by se v tom snad nedalo ani pracovat.
C je jazyk co člověka buď střílí do nohy, nebo jebe do zadeke násadou od krumpáče. :)
-
IMHO je lepší brát C jako "přenositelný asembler"...
Jako přenositelný assembler je ho třeba brát s hodně velkou rezervou. Obzvlášť standardní C, ne různé nadstandardní dialekty. :)
Které dialekty například?
Třeba gcc dialekt ve kterém je psaný linux.
To nevím, jestli je nadstandardní. Možná nadstandardní guláš :)
Mně se z rozšíření C líbí akorát bloky, ale to je čistě osobní preference a navíc víceméně irelevantní, protože na naprostou většinu projektů se hodí jiné jazyky vyšší úrovně.
Tím nadstandardem jsem myslel čistě nad rámec standardu :)
Aha, tak to pak jo.
-
C je jazyk co člověka buď střílí do nohy, nebo jebe do zadeke násadou od krumpáče. :)
Někdy se hodí, kromě jádra OS třeba nějaké to embedded, ne?
-
C je jazyk co člověka buď střílí do nohy, nebo jebe do zadeke násadou od krumpáče. :)
Někdy se hodí, kromě jádra OS třeba nějaké to embedded, ne?
Jasně že se hodí. Akorát je to pěstní klín z kompilátorového pravěku a podle toho to pak vypadá. Ten jazyk je krásně jednoduchý pro autory překladačů (pokud nechtějí i pořádný optimalizátor), takže má překladač skoro pro všechno. Akorát pro programátory se ten jazyk jednoduše jen tváří.
-
Jasně že se hodí. Akorát je to pěstní klín z kompilátorového pravěku
Hezká analogie :)
-
C je jazyk co člověka buď střílí do nohy, nebo jebe do zadeke násadou od krumpáče. :)
Někdy se hodí, kromě jádra OS třeba nějaké to embedded, ne?
Jasně že se hodí. Akorát je to pěstní klín z kompilátorového pravěku a podle toho to pak vypadá. Ten jazyk je krásně jednoduchý pro autory překladačů (pokud nechtějí i pořádný optimalizátor), takže má překladač skoro pro všechno. Akorát pro programátory se ten jazyk jednoduše jen tváří.
len si treba uvedomiot dve veci: vykon tehdajsich pocitacov, dostupne programovacie jazyky a to, ze kompilator C trebalo napisat v podstate assembleri.
Takze, bolo by fajn vytvorit jazyk s generikami, ale je mozne, ze preklad tehdajsich programov by sa nezmestil do RAM-ky. A tiez to, ze C-sko pokryvalo tehdajsie pozidavky a jeho vlastnosti su adkevatne jeho urceniu.
-
Takze, bolo by fajn vytvorit jazyk s generikami, ale je mozne, ze preklad tehdajsich programov by sa nezmestil do RAM-ky. A tiez to, ze C-sko pokryvalo tehdajsie pozidavky a jeho vlastnosti su adkevatne jeho urceniu.
Však jo, historickou užitečnost mu asi nikdo nebere. Když jsem v devadesátkách porovnával Turbo Pascal s Turbo C, byl jsem nadšený tím, jak má C vymakanou základní knihovnu, úspornou syntaxi a (po přečtení Učebnice od P. Herouta) všechno do sebe smysluplně zapadá (z mého pohledu trochu na rozdíl od Pascalu - ten měl zase výhodu v rychlé kompilaci apod.).
Pak už to všechno začalo být poněkud složitější - přišlo C++ a problémy s kompatibilitou, nástup Javy, která měla všechno vyřešit apod...
-
Takze, bolo by fajn vytvorit jazyk s generikami, ale je mozne, ze preklad tehdajsich programov by sa nezmestil do RAM-ky. A tiez to, ze C-sko pokryvalo tehdajsie pozidavky a jeho vlastnosti su adkevatne jeho urceniu.
Však jo, historickou užitečnost mu asi nikdo nebere. Když jsem v devadesátkách porovnával Turbo Pascal s Turbo C, byl jsem nadšený tím, jak má C vymakanou základní knihovnu, úspornou syntaxi a (po přečtení Učebnice od P. Herouta) všechno do sebe smysluplně zapadá (z mého pohledu trochu na rozdíl od Pascalu - ten měl zase výhodu v rychlé kompilaci apod.).
Pak už to všechno začalo být poněkud složitější - přišlo C++ a problémy s kompatibilitou, nástup Javy, která měla všechno vyřešit apod...
Java ve své době taky řešila akutní požadavky :) Stejně jako Cobol svého času :) Nebo Objective-C...
Jsem zvědav, jak se budeme za nějakých dvacet let dívat na dnešní Rust, Go apod. Možná už taky bude něco kvantového a všechny tyhle jazyky budou něco jako pazourek.
-
Takze, bolo by fajn vytvorit jazyk s generikami, ale je mozne, ze preklad tehdajsich programov by sa nezmestil do RAM-ky. A tiez to, ze C-sko pokryvalo tehdajsie pozidavky a jeho vlastnosti su adkevatne jeho urceniu.
Však jo, historickou užitečnost mu asi nikdo nebere. Když jsem v devadesátkách porovnával Turbo Pascal s Turbo C, byl jsem nadšený tím, jak má C vymakanou základní knihovnu, úspornou syntaxi a (po přečtení Učebnice od P. Herouta) všechno do sebe smysluplně zapadá (z mého pohledu trochu na rozdíl od Pascalu - ten měl zase výhodu v rychlé kompilaci apod.).
Pak už to všechno začalo být poněkud složitější - přišlo C++ a problémy s kompatibilitou, nástup Javy, která měla všechno vyřešit apod...
Java ve své době taky řešila akutní požadavky :) Stejně jako Cobol svého času :) Nebo Objective-C...
No já jsem ani nechtěl hejtovat Javu (teda mám k ní milion výhrad), spíš ten pocit, že "tohle je ono". No a pak jsem poznal Python apod. jazyky, jasně, znal jsem základy Lispu a Prologu, zkoušel nějaký Smalltalk, ML, Haskell, Julii... Ten Rust a Go - taky to je součást cesty, v pohodě, když přijde něco lepšího, zase super.
-
Takze, bolo by fajn vytvorit jazyk s generikami, ale je mozne, ze preklad tehdajsich programov by sa nezmestil do RAM-ky. A tiez to, ze C-sko pokryvalo tehdajsie pozidavky a jeho vlastnosti su adkevatne jeho urceniu.
Však jo, historickou užitečnost mu asi nikdo nebere. Když jsem v devadesátkách porovnával Turbo Pascal s Turbo C, byl jsem nadšený tím, jak má C vymakanou základní knihovnu, úspornou syntaxi a (po přečtení Učebnice od P. Herouta) všechno do sebe smysluplně zapadá (z mého pohledu trochu na rozdíl od Pascalu - ten měl zase výhodu v rychlé kompilaci apod.).
Pak už to všechno začalo být poněkud složitější - přišlo C++ a problémy s kompatibilitou, nástup Javy, která měla všechno vyřešit apod...
Java ve své době taky řešila akutní požadavky :) Stejně jako Cobol svého času :) Nebo Objective-C...
No já jsem ani nechtěl hejtovat Javu (teda mám k ní milion výhrad), spíš ten pocit, že "tohle je ono". No a pak jsem poznal Python apod. jazyky, jasně, znal jsem základy Lispu a Prologu, zkoušel nějaký Smalltalk, ML, Haskell, Julii... Ten Rust a Go - taky to je součást cesty, v pohodě, když přijde něco lepšího, zase super.
Přesně, je to cesta, vždy přijde hype, ten si pak sedne, nakonec se z jazyka stane legacy a mezitím vznikne něco, o čem se člověku ani nesnilo. Jen to C++ furt straší a reinkarnuje :)
-
Unicorn je shit, Kovar si nevazi lidi.
-
Unicorn je shit, Kovar si nevazi lidi.
Jak to souvisí se zdejším off-topicem?
-
Unicorn je shit, Kovar si nevazi lidi.
Jak to souvisí se zdejším off-topicem?
Tak trochu netrafil... https://forum.root.cz/index.php?topic=25264.msg358636;topicseen#new