Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Daryl 22. 01. 2014, 19:23:15
-
Ahoj. Chci se zeptat na Váš názor - s čím mám začít?
S Pythonem jsem ještě nikdy nepracoval. Se C# jsem došel jen k objektovému programování, ale tam jsem celkem tvrdě narazil. A o Pythonu se říká, že je to jazyk vhodný pro začátečníky, tak mě napadlo, že bych se tím mohl zlepšit.
Ještě dodám, že hodlám C# v budoucnosti používat, teď jde jen o to, zda s tím "začít" už teď nebo až po Pythonu.
Díky moc :)
-
Pro začátečníky je rozhodně lepší C#. Později se jím i můžeš živit. Python je tak na hraní a je lepší v něm dělat až později, protože je náročnější udržet v něm kvalitu, kterou potřebuje.
-
Proč myslíte, že je Python nahraní? Tím to nechci obhajovat, zajímá mě názor proč v současnosti nejpoužívanější skriptovací jazyk je pouze na "hraní"?
-
msr: blbost
Daryl: zacni s Pythonem, nauc se v nem, jak funguje OOP a pak prejdi na c# (hlavne nezapomenout na "beztypovost" pythonu)
-
Sám jsi to řekl. Skriptovací. Skripty do pár tisíc řádků se ještě dají, ale více stojí moc úsilí a nevyplatí se to. Určitě to ale půjde, jen proč to dělat. Python má svoje využití, ale pro začátečníky má zbytečně moc zajímavých věcí a hlavně je dynamicky typovaný, což je pro začátek také k ničemu.
-
C# aj pyton maju podobny objektovy model, ani v Pythone sa objektom nevyhnes. takze ked uz si zacal s C#kom tak v tom pokracuj. Python ma nevyhodu v tom ze momentalne vedla seba funguju 2 navzajom nekompatibilne verzie 2.x a 3.x a ani jedna z nich neni uplne idealna volba (2ka je neperspektivna a 3ka je nedokoncena).
-
Hlavně začínat s jazykem, který nemá rozhraní a všichni kolem tvrdí, že ho nepotřebuje, mi nepřijde úplně dobrá volba. Samozřejmě lze využít třeba ZCA a nebo rovnou pořádný jazyk :D
-
Pro C# je víc pracovních míst (hned po Javě nejvíc). Ale oproti Pythonu je to dost ukecaný jazyk. Dělával jsem v C, potom C# a teď zkouším Python. Pokud nedělá problém anglická literatura doporučil bych spíš Python.
C# aj pyton maju podobny objektovy model, ani v Pythone sa objektom nevyhnes. takze ked uz si zacal s C#kom tak v tom pokracuj. Python ma nevyhodu v tom ze momentalne vedla seba funguju 2 navzajom nekompatibilne verzie 2.x a 3.x a ani jedna z nich neni uplne idealna volba (2ka je neperspektivna a 3ka je nedokoncena).
Proč by měla být verze 2 neperspektivní??
-
Co tak koukam na komentare doba, kdy se dalo rict ze uroven rootu za neco stoji je pryc. Jinak receno, dle tve otazky doporucuji spis najit jiny obor nez programovani. Ne opravdu nechcu byt zly. Ale pokud si s C# narazil, tak si nemyslim ze ma smysl pokracovat. Teda otazkou je kolik ti je let. Pokud je ti okolo 12 let, tak potom samozrejme je to v pohode. Jinak python je urcite fajn jazyk at uz verze 2 nebo nova verze 3. Pokud by si se pro nej rozhodl tak doporucuji pouzivat nejnovejsi verzi.
-
Kozzi: Taky nechci být zlý, ale jen narazit na překážku a hned to vzdát? To je celkem blbost. Nevím, toto mi nedává smysl :)
-
Proč myslíte, že je Python nahraní? Tím to nechci obhajovat, zajímá mě názor proč v současnosti nejpoužívanější skriptovací jazyk je pouze na "hraní"?
Protože je tzv. dynamicky typovaný - přesněji jeho typový systém má pouze jeden typ.
-
Kozzi: Taky nechci být zlý, ale jen narazit na překážku a hned to vzdát? To je celkem blbost. Nevím, toto mi nedává smysl :)
A proč to teda vzdáváš?! ??? :o Když si narazil u objektů tak je otázka jestli změna jazyka něco vyřeší. Radši se snaž pochopit OOP ;)
-
Daryle, myslim, ze daleko dulezitejsi, nez v jakem jazyce se naucis programovat, je co a s jakym nadsenim budes programovat. Nadchazejici flame zdejsich kolegu te nikam neposune.
Ucit se programovat jen tak zbuhdarma mi prijde jako velice bolestiva cesta s nejistym koncem. Zaklady algoritmizace a OOP si muzes osvojit leckde (ja treba vysel z "Thinking in C++" od Bruce Eckela (http://mindview.net/Books/TICPP/ThinkingInCPP2e.html)), co je ale hrozne dulezite je, ze to musi mit nejaky cil. Programovaci jazyk (jakykoliv!) je pouhym prostredkem k dosazeni cile.
Tva otazka je proste mimo, ty chces jet nekam na vejlet, a ptas se, jakym autem tam chces jet, ale vubec nerikas, kam (popr, kudy) to bude? Az to budes vedet, tak Ti tady urcite lidi radi poradi, cim tam (radsi) jet.
Kazdy jazyk ma sve silne stranky v urcite domene a v jine je zas uplne na draka, neexistuje zadny uber-jazyk pro vsechny. Musis vedet, co chces (aspon zkusit) delat, volba nastroje je pak uz mnohem snazsi.
-
C#. Vies to omnoho lepsie pracovne vyuzit a ak ta bude zaujimat Python, nauc sa ho popri tom.
-
skus tie objekty v PHPcku....budes potom velmi rad za c#, ktory je po stranke cistoty a prehladnosti kodu o niekolko tried pred cimkolvek inym
-
s čím mám začít?
můžete zvolit kompromis - IronPython
jeho typový systém má pouze jeden typ.
jak jste na takovou blbost přišel?
-
python je i na hrani. jako kterykoliv jiny programovaci jazyk. stejne tak se v nem da programovat poradne. jen je potreba umet ho spravne pouzit podle toho co ma byt vysledkem.
Ale kdyz uz tazatel zacal s C# tak spis doporucim drzet se toho C# a dotahnout to v nem dal. Pro zacatek treba: http://en.wikipedia.org/wiki/List_of_object-oriented_programming_terms jen je potreba si rict na rovinu, ze ruzne jazyky mivaji drobne odchylky v implementacnich detailech, tak pak zavadi jeste sve specializovane nazvoslovi. Takze obcas je potreba popremyslet, co je skoro synonymem a v cem se to pripadne nepatrne lisi. Lepsi je pak asi primo literatura k C#, kde se rovnou budes pohybovat v C# terminologii.
-
Pouzij Python 3. Python 2 je zastaraly a nebude se dal vyvijet, ma smysl jen v projektech, ktere uz existuji.
Na OOP se zatim vykasli, dokud nenapises aspon 1000 radkovy program, nema to smysl. Nauc se programovat pomoci kratkych funkci, ktere delaji jen jednu vec (pokud mozno). Schopnost rozdelit takto problem (a obecne algoritmizovat) je na programovani to nejtezsi, pokud dokazes tohle, OOP uz prijde samo.
-
Kozzi: Taky nechci být zlý, ale jen narazit na překážku a hned to vzdát? To je celkem blbost. Nevím, toto mi nedává smysl :)
Heh ted koukam co jsme psal a rikam si ze to je nejake podezrele a ze si to ani nepamatuji, pak koukam na cas a je to jasne, to uz jsme mel aspon trojku v krvi, takze vse co jsem napsal beru zpet, a omlouvam se za spam.
-
V pohode :D:)
No, krome tohoto fora jsem se ptal jeste na jednom foru a znameho-programatora. A jsou 3 moznosti: bud pokracovat v C# nebo jit do Pythonu nebo dokonce moznost zkusit VB :) Vsem diky za nazory, vsechny je vezmu v potaz:) A samozrejme, klidne muzete psat dal :D:)
-
kdo ti poradil VB, at si naliska.
-
kdo ti poradil VB, at si naliska.
Rek bych, ze na tom se tu shodnem vsichni :D
-
Ten kto poradil VB ma pravdu. Visual Basic je len C# s inou syntaxou a par kozmetickymi odlisnostami http://www.dotnetportal.cz/blogy/9/Ondrej-Linhart/920/Proc-je-Visual-Basic-lepsi-nez-C-
-
Ahoj Daryl.
V podstate si myslim, ze je to jedno. Z hladiska OOP a praxe, mal by vacsi zmysel asi C#. Z hladiska rychlosti, Python by mohol byt fajn volba. Ak sa chces ucit, najme potrebujes nejaky projekt, nejaky ciel, na ktorom zacnes pracovat a vsimaj si pri nom sameho seba. Budes robit chyby, to nevadi a su dobre. Dolezite si je uvedomit si ich a poucit sa z nich. Su to programtorske navyky, ktore maju zmysel a k vacsine z nich dojdes sam. Zrazu si uvedomis, ze ten isty kod pises aj tu, aj tam aj hentam a budes premyslat a hladat, ako mat iba jeden kod. Zacnes sam premyslat, ake su vztahy medzi entitami.
Naozaj si myslim, ze mat nejaky ciel, nejaky projekt je daleko dolezitejsie ako jazyk, ak sa chce clovek ucit. Lebo ak ked jazyk vyberies blbo, tak to zistis a budes vediet, na co sa hodi a na co sa hodi menej. A preco. Lebo si to zazijes. Ako tu niekto poznamenal, jazyk je iba nastroj na vyjadrenie myslienok.
Neviem, kolko mas rokov a rob, co si mysils, ze je vhodne. Ak to nebude vhodne, ok nevadi, pojdes dalej alebo to zmenis. Ale inac nezistis, co je pre Teba vhodne a co nie. Aj knihy.. kazdemu sadne nieco ine. Napriklad pre mna je Mistrovstvi v C++ kniha, ktora je iba velmi roztahany uvod do C++ a s mistrovstvim nema spolocne nic. Poznam aj ludi, pre ktorych je ta kniha super..
Najdi ciel a chod za nim. Skor ci neskor, najdes svoju cestu.
-
Jestli vám jde o pochopení OPRAVDOVÉHO objektového modelování a programování, tak Smalltalk, který je minimalistický a přitom mocný, nekompromisně objektový a bez balastu. V praxi se moc nepoužívá, ale na pochopení asi nic lepšího nenajdete. Pak můžete klidně to C# a uvidíte, co je to za nakynutý bastl a co všechno to neumí. (Python neznám, tak o něm mluvit nebudu, ale co si pamatuju, tak mi přišel jako takový splácaný eintopf).
-
Jestli vám jde o pochopení OPRAVDOVÉHO objektového modelování a programování, tak Smalltalk, který je minimalistický a přitom mocný, nekompromisně objektový a bez balastu. V praxi se moc nepoužívá, ale na pochopení asi nic lepšího nenajdete.
A co Objective-C? Ten byl ovlivněn Smalltalkem a v praxi se používá.
-
A co takhle porovnat pouzitelnost tech jazyku ? C# neni multiplatformni (v pravem smyslu) => z toho pohledu uz je lepsi ten Python nebo Java a kdyz uz HC tak C++ / QT
Osobne si ale myslim ze na to jdes spatne, poradnym zakladem a hnacim motorem v uceni se programovat je "vysnena cilova aplikace" jakmile mas vymyslenou aplikaci kterou chces opravdu moc naprogramovat (tak ze se ti o tom i pomalu zda) v tu chvili je cas polozit si otazku "V cem to budu programovat", pak se meni uceni na zabavu...
Samozrejme timto pristupem budou prvni verze te aplikace (i kdyz funkcni) zabugovane, neoptimalizovane, s tunami zbytecneho kodu.
Dulezite je v te situaci si uvedomit ze "to co jsem prave naprogramoval je totalni sracka" -> smazat a zacit znovu a lepe (Clovek proste za dobu tvorby dane app pochytil skill ktery je jiz nad urovni dane aplikace)
Jakmile se dostanes do situace ze na dane aplikaci uz neni co vylepsit tak: "Nejsi dobry programator" nebo "Jsi se konecne naucil poradne programovat v danem jazyce" kazdopadne je to cas vydat zdrojaky pod svobodnou licenci a nechat OSS komunitu ohodnotit tvuj kod...
-
jeho typový systém má pouze jeden typ.
jak jste na takovou blbost přišel?
Doporučuji třeba zápisek Dynamic languages are static languages (http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/) nebo knihu Types and Programming Languages (http://www.amazon.com/Types-Programming-Languages-Benjamin-Pierce/dp/0262162091) (poslední 3 odstavce na straně 2 - je to zdarma přístupné přes Amazon).
-
...
pre mna je Mistrovstvi v C++ kniha, ktora je iba velmi roztahany uvod do C++ a s mistrovstvim nema spolocne nic
...
Samozrejme Mistrovstvi v C++ je len nazov vymysleny pre cesky preklad. V originali sa to vola C++ Primer
-
Skus IronPython (http://ironpython.net/):
(http://ironpython.net/images/ironpython-vstools-fade.png)
- su ktomu aj PythonTools (http://ironpython.net/tools/) pre VisualStudio
- a mozes to kombinovat aj s ostatnymi .NET jazykmi takze aj s C#ckom
- podporuje to Framework Django
- a daju sa v tom pisat aj Appky pre Windows.
Ja som v tom za par sekund vyplodil toto:
import wpf
from System.Windows import *
from System.Windows.Controls import *
class MyWindow(Window):
def __init__(self):
btn = Button(Content = "Pozdrav")
btn.Click += lambda sender, e:MessageBox.Show("Hello world!")
self.AddChild(btn)
if __name__ == '__main__':
Application().Run(MyWindow())
a to nie som ziadny pythonista...
Ale pozor v python je dynamicky jazyk a v dynamickom jazyku na vacsinu chyb prides az po spusteni aplikacie, IDE ta nebude upozornovat na syntakticke chyby na tvojom mieste by som pre zaciatok ostal pri C#.
-
Jestli vám jde o pochopení OPRAVDOVÉHO objektového modelování a programování, tak Smalltalk, který je minimalistický a přitom mocný, nekompromisně objektový a bez balastu. V praxi se moc nepoužívá, ale na pochopení asi nic lepšího nenajdete.
A co Objective-C? Ten byl ovlivněn Smalltalkem a v praxi se používá.
Tak to neznám, takže nemůžu hodnotit, proto doporučuju ST. Každopádně na pochopení OM/OP je C# nevhodné, protože už je docela přikurvené a překombinované (co od MS není).
-
Doporučuji třeba zápisek Dynamic languages are static languages (http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/) nebo knihu Types and Programming Languages (http://www.amazon.com/Types-Programming-Languages-Benjamin-Pierce/dp/0262162091) (poslední 3 odstavce na straně 2 - je to zdarma přístupné přes Amazon).
Je to hodne hodne offtopic, ale - myslim, ze ty zapisky maji pravdu, jenze je to silene zuzeny pohled na svet.
Premyslim ted nad dynamicky (a adhoc) typovanym, striktne funkcionalnim jazyce s linym vyhodnocovanim. Dynamicnost typu neni v tom kontextu nic jineho, nez lina typova kontrola (tedy ceka se, kdy se srazime s typove nekompatibilnim literalem nebo kusem vstupnich dat), a je tedy prirozenym rozsirenim lineho vyhodnocovani jako takoveho. Lze tam take elegantne resit pretezovani funkci (a eventualne OOP) pomoci backtracku..
-
Doporučuji třeba zápisek Dynamic languages are static languages (http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/) nebo knihu Types and Programming Languages (http://www.amazon.com/Types-Programming-Languages-Benjamin-Pierce/dp/0262162091) (poslední 3 odstavce na straně 2 - je to zdarma přístupné přes Amazon).
zápisek je velmi emocionálně laděný a tvrdí, že dynamické jazyky jsou marketingový tah, vlastně neexistují a neuvádí žádný příklad (např. PHP by popisu odpovídalo, Python o poznání méně), kniha připouští, že existují, ale vhodné označení je "jazyky s dynamickou typovou kontrolou", nic o jediném datovém typu jsem ve vámi zmíněné části nenašel
-
Ten kto poradil VB ma pravdu. Visual Basic je len C# s inou syntaxou a par kozmetickymi odlisnostami http://www.dotnetportal.cz/blogy/9/Ondrej-Linhart/920/Proc-je-Visual-Basic-lepsi-nez-C-
Nevsim jsem si, ze by v dnesni dobe doporucoval treba Fortran. Proto asi to prekvapeni, ze nekdo jeste dnes muze doporucit VB nekomu, kdo uz ma C# za zaklady za sebou
-
Jestli vám jde o pochopení OPRAVDOVÉHO objektového modelování a programování, tak Smalltalk, který je minimalistický a přitom mocný, nekompromisně objektový a bez balastu. V praxi se moc nepoužívá, ale na pochopení asi nic lepšího nenajdete.
A co Objective-C? Ten byl ovlivněn Smalltalkem a v praxi se používá.
Tak to neznám, takže nemůžu hodnotit, proto doporučuju ST. Každopádně na pochopení OM/OP je C# nevhodné, protože už je docela přikurvené a překombinované (co od MS není).
Stepen Leacock napsal geniální povídku. Ve zkratce:
Chlap se chce oženit a v kostele. Ale na to musí být pobožný. Ale tam narazí na problém, že nezná Bibli. Tak ji začne studovat. Ale nejde mu to, protože v překladu se ztrácejí souvislosti. Tak se učí latinsky. Ale pořád mu to nejde, protože to chce Bibli studovat v origiinále - řecky a hebrejsky. A tyhle jazyky nejsou dobře zvládnout a pochopit bez znalosti aramejštiny. A ta bez znalosti...
Jeho holka si mezitím vzala nějakého pologramota.
A z toho plyne poučení:
I když tazatel narazil na nějaké problémy s objekty, tak nebude nejlepší pokoušet začít učit čistší (ač třeba nejčistší) objektový jazyk. Tuplem tím, že se v praxi vůbec nepoužívá, neexistuje na něj hromada tutoriálů a málokdo (reálně nikdo) mu s tím pomůže.
C# i Python jsou dobré jazyky pro výuku i objektového programování. Daryl prostě potřebuje lepší tutoriály/knížku. Nebo někoho, kdo mu to vysvětlí - protože samostudium komplikovaných věcí je prostě těžké.
-
Ten kto poradil VB ma pravdu. Visual Basic je len C# s inou syntaxou a par kozmetickymi odlisnostami http://www.dotnetportal.cz/blogy/9/Ondrej-Linhart/920/Proc-je-Visual-Basic-lepsi-nez-C-
Jelikoz se v praci setkavam s lidmi, kteri znaji v podstate jen VB, ty "kosmeticke odlisnosti" bohuzel velmi negativne ovlivnuji jejich zpusob mysleni. Napr. takove zvrhlosti jako u volani funkce neni treba psat zavorky, stejna syntax pristupu k poli jako u volani funkce, on error goto, nektere veci se automaticky chovaji jako static, zapis retezcu, pretezovani metod atd.
Ano, kod ve VB a C# se da namapovat 1:1. Ale to neznamena, ze zacatecnik ve VB bude pouzivat ty vlastnosti, ktere by spravne mel, a nebude se mu to vselijak plest.
-
...
Napr. takove zvrhlosti jako u volani funkce neni treba psat zavorky
...
Tak zrovna tohle bych nezatracoval, jsou pripady kdy se to muze opravdu hodit, napriklad pri UFCS (Universal Function Call Syntax)
Ano, kod ve VB a C# se da namapovat 1:1. Ale to neznamena, ze zacatecnik ve VB bude pouzivat ty vlastnosti, ktere by spravne mel, a nebude se mu to vselijak plest.
Tak to je obecne problem prechodu z jedne syntaxe na druhou, ale neni to zadny velky problem, vetsinou se clovek preuci velmi rychle.
-
Pro pochopení OOP v jednom jazyce se začít učit další jazyk není moc rozumný nápad, to v tom spíš budeš mít ještě větší guláš než teď. Radši si najdi kvalitnější zdroje, ve kterých je to srozumitelněji vysvětleno. No a s VB má většina lidí problém ten, že jeho syntaxe je prostě odporná, víc v tom nehledej.
-
Tak zrovna tohle bych nezatracoval, jsou pripady kdy se to muze opravdu hodit, napriklad pri UFCS (Universal Function Call Syntax)
Tohle se mozna hodi do cistych jazyku jako Scheme ci Haskell, ale do dortu, ktery varili pejsek s kocickou, aby si udrzeli stavajici bazi uzivatelu opravdu ne..
Tak to je obecne problem prechodu z jedne syntaxe na druhou, ale neni to zadny velky problem, vetsinou se clovek preuci velmi rychle.
Ano, problem to neni, pokud clovek chape konceptualni rozdil mezi funkci a polem, ci mezi funkci a property. Odlisna syntaxe jako takova neni problem. Problem je, ze syntaxe VB primo vede na michani techto pojmu, a je tudiz pro zacatecniky naprosto nevhodna.
-
Ja si stale myslim, ze dolezite je mat nejaky ciel, projekt, na ktorom pracovat, poobzerat sa po rozumnych jazykoch a vybrat kludne nahodne. Reci typu co je a nie je vhodne pre zaciatocnika povazujem sa prazdne obhajovanie svojej pravdy. Jazyk ani nahodou nie je co, co robi programatora programatorom.. A mne sa aj velmi paci cesta, kedy na zaciatku clovek urobi co najviac veci spatne a pouci sa z nich.
Teda, mozno su nejake jazyky viac a menej vhodne ak chce byt clovek priemerny programator, ale ja som nikdy nebol clovek, ktoreho zaujimal priemer.. A pre tych ostatnych, je absolutne jedno, s cim zacnu..
-
to je nejlevnejsi vymluva, proc nezacit vubec.
-
Ja si stale myslim, ze dolezite je mat nejaky ciel, projekt, na ktorom pracovat, poobzerat sa po rozumnych jazykoch a vybrat kludne nahodne. Reci typu co je a nie je vhodne pre zaciatocnika povazujem sa prazdne obhajovanie svojej pravdy. Jazyk ani nahodou nie je co, co robi programatora programatorom.. A mne sa aj velmi paci cesta, kedy na zaciatku clovek urobi co najviac veci spatne a pouci sa z nich.
Teda, mozno su nejake jazyky viac a menej vhodne ak chce byt clovek priemerny programator, ale ja som nikdy nebol clovek, ktoreho zaujimal priemer.. A pre tych ostatnych, je absolutne jedno, s cim zacnu..
Díky itwu, žes nám sdělil, že tebe průměr nikdy nezajímal. To jsme fakt všichni potřebovali vědět.
Že jazyk není to, co dělá programátora programátorem, to je přece banální pravda, kterou nikdo nerozporuje. Jenže když někdo ještě programátor není a žádný jazyk neumí, tak holt nějaký jazyk potřebuje. A pro začátečníky je zásadní rozdíl v jakém jazyce se učí programovat. Jak rychle jim to půjde, jestli je to bude bavit, jestli rychle dosáhnou nějakého zajímavého výsledku, který je potěší a utuží. Anebo jestli se zamotají do problémů a vzdají to. A všechny tohle se umocňuje, když se jedná o samostudium neprogramátora.
Fakt myslíš, že tvůj příspěvek - kromě toho, že asi tobě pomohl upevnit ego - nějak pomůže začátečníkovi? Jo vlastně, ještě je tam rada stanovit si cíl - ale ten on už má - naučit se programovat v C#, ve kterém chce potom něco dělat.
-
prijde mi, ze se tu resi 2 ruzny veci dokopy. uplny zelenac proti rekvalifikace programatora.
-
zápisek je velmi emocionálně laděný a tvrdí, že dynamické jazyky jsou marketingový tah, vlastně neexistují a neuvádí žádný příklad (např. PHP by popisu odpovídalo, Python o poznání méně), kniha připouští, že existují, ale vhodné označení je "jazyky s dynamickou typovou kontrolou", nic o jediném datovém typu jsem ve vámi zmíněné části nenašel
V té knize je velmi důležitá část
Another important element in the above definition is its emphasis on classification of terms - syntactic phrases - according to the properties of the values that they will compute when executed. A type system can be regarded as calculating a kind of static approximation to the run-time behaviors of the terms in a program.
která říká, že typový systém je statická záležitost - tj. typová kontrola se provádí ještě před spuštěním programu. Python před spuštěním programu žádnou typovou kontrolu neprovádí - řečeno slovy knihy Python neklasifikuje termy podle vlastností jejich hodnot. Můžeme tedy říci, že Python nemá typy. Ale to je stejné, jako když řekneme, že má pouze jeden typ a přiřazuje ho každému termu (takovouhle typovou kontrolou projde každý syntakticky správný program, což je stejné chování, jako když typovou kontrolu vynecháme).
Za běhu Python nerozlišuje typy, ale tagy.
Jazyky jako C# mají více typů, ale ani tam nejsou typy za běhu přístupné a máte jen tagy. Uvažte například program
var p = new Pes();
kde proměnná p má typ Pes, ale díky podtypovému polymorfismu má rovněž typy Savec, Zvíře a Object. Můžete dokonce napsat
var q = p as Zvíře;
a q bude mít typy Zvíře a Object. Nicméně za běhu budou mít obě hodnoty uložené v promenných tagy Pes bez ohledu na jejich typ v době kompilace.
Mj. autor blogového zápisku napsal knihu Practical Foundations for Programming Languages (http://www.cs.cmu.edu/~rwh/plbook/book.pdf), kde se tomuto tématu rovněž věnuje v kapitole 17 a 18.
-
...
Napr. takove zvrhlosti jako u volani funkce neni treba psat zavorky
...
Prave nutnost pisat zatvorky pri bezparametrickej funkcii je specialita jazyka C (a jazykov z neho vychadzajucich). Ostatne jazykove rodiny (Pascal, Modula, ML, Lisp, Basic, Ruby, ADA, Eiffel) nic take nevyzaduju. Vo funkcionalnych jazykoch zvykne byt () specialny typ.
-
Hosi hosi,
tuny pradnych kecu o tom, jak je nekdo linej pouzit google. Zabere
vic casu precist vsechny vase prispevky nez "najit spravnou odpoved".
Z pythonem jsem zacinal, a muzu vam rict, jakmile jsem mel
v hlave nacrt aplikace, okamzite jsem na tom zacal delat, a verte,
ze to dlouho netrvalo a byla hotova. Samozrejme jsem ji musel jeste
jednou prepsat, bylo to po roce a bylo tam par zbytecnych radku kodu.
Nic vic, nic min. Co je zaklad uceni ? Nabirat informace o vecech ktere
neznam. Ne nechat si nasbirat informace ktere si pak jen prectu, nepochopim
to, a jsem tam, kde jsem byl na zacatku.
Tod asi vse k te vasi zbytecne diskuzi.
-
Díky itwu, žes nám sdělil, že tebe průměr nikdy nezajímal. To jsme fakt všichni potřebovali vědět.
Že jazyk není to, co dělá programátora programátorem, to je přece banální pravda, kterou nikdo nerozporuje. Jenže když někdo ještě programátor není a žádný jazyk neumí, tak holt nějaký jazyk potřebuje. A pro začátečníky je zásadní rozdíl v jakém jazyce se učí programovat. Jak rychle jim to půjde, jestli je to bude bavit, jestli rychle dosáhnou nějakého zajímavého výsledku, který je potěší a utuží. Anebo jestli se zamotají do problémů a vzdají to. A všechny tohle se umocňuje, když se jedná o samostudium neprogramátora.
Fakt myslíš, že tvůj příspěvek - kromě toho, že asi tobě pomohl upevnit ego - nějak pomůže začátečníkovi? Jo vlastně, ještě je tam rada stanovit si cíl - ale ten on už má - naučit se programovat v C#, ve kterém chce potom něco dělat.
Ak je cielom sa naucit programovat v C#, tak potom je C# logicka volba. Ked je so C# problem, idem za niekym, kde svoj problem popisem a skusim sa pohnut dalej. Ak mi to nepomaha, je nieco spatne. Ale ciel, alebo jazyk, ktory je nahodou sucastou ciela. Alebo nieco, co ma nenapada. Mna kedysi ucili v skole chvilu Delphi s OOP a nechopil som ho ani za boha. Davali tam ukazkove priklady polymorfizmu, ktore avsak nemalo v ziaden ulohe zmysel pouzit, lebo som kazdu ulohu spravil bezproblemom s tym, co som vedel.
Ibaze tu sa riesi jazyk. A zaciatocnikovi je urcite najlepsie vysvetlit rozdiel medzi 20 jazykmi, ktore nema sancu pochopit a samozrejme vecny Lisp, Schceme..
A potom si predstav, ze existuju zaciatocni, pre ktorych je najlepsia volba C. Pre inych assembler. Pre inych PHP. Pre niekoho C#. Ja ak sa tak spatne divam, pre mna bola vhodna volba prveho jazyka C, lebo som sa chcel hrat s pointrami. Aj keby som asi nic nenamietal preti Pythonu. No ja som clovek, ktory si chcel vychodit cestu s rozumnou nizkou abstrakciou, co je C az po C#, C++11. V Pascale som stravil roky, lebo som ani nevedel, ze nejake C existuje.
Teda chlapec, namiesto toho, aby tu ludia mi prikazovali aky jazyk sa ma ucit, ma 2 moznosti.
1. popise aky ma v C# s OOP problem, pokusime ma mu pomoct. Neviem, ako OOP chape on, ja som typ cloveka, ktory to plne pochopi, az ked take nieco vyuzije odrazu sa hodi v praxi.
2. hm, narazil, skusi iny jazyk. Napriklad Python.
3. vykasle sa na to.
4. bude sa stale tocit do kolecka
V OOP je dolezite poznat SOLID princip, navrhove vzory atd.. Ale mne pride kontraproduktivne, zaciatocnika ucit co je SOLID princip a za kazdu cenu ho presvedcit, ze sa mu hodi. Radsej nech nevie, co je SOLID princip naprogramuje nieco vacsie, par krat to zmeni tak sa bude sam zamysliat. Zaciatocnik sa podla mna musi ucit na vlastnych chybach. Ucit ho slepo best practises je ako memorovanie poezie bez jej prezitia.
A z prispevkov tuna mam dojem, ze kazdy mu chce tu ten najlepsi jazyk a best practises..
-
Prave nutnost pisat zatvorky pri bezparametrickej funkcii je specialita jazyka C (a jazykov z neho vychadzajucich). Ostatne jazykove rodiny (Pascal, Modula, ML, Lisp, Basic, Ruby, ADA, Eiffel) nic take nevyzaduju. Vo funkcionalnych jazykoch zvykne byt () specialny typ.
- Závorky u funkce bez argumentů je naprosto logická věc, která umožňuje distinkci mezi funkcí a voláním té funkce.
- Existuje spousta jazyků, co to vyžaduje a není pascal - like, např. Python, Fortran, Go...
- Lisp závorky pro evaluaci funkce bez argumentů vyžaduje (jen u něj je operátor zavolej funkci jiný, nikoli závorky za názvem funkce, ale kolem funkce (jsem si vědom částečného významového rozdílu)).
- Na jedné straně mluvíš o rodině C like jazyků, kde házíš vše do jednoho pytle (i když např. takové C a Javascript jsou naprosto odlišné jazyky), a na druhé straně děláš výčet s Pascalem, Modulou a ADou, přitom druzí dva jsou přímí potomci pascalu.
- Co se týče např. Basicu, tak sám microsoft v dokumentaci tvrdí, že se sice závorky mohou "omitnout", ale že to nedoporučuje dělat kvůli čitelnosti...
- V Ruby zas díky tomu, když chci udělat operátor map, tak místo čistého pole.map(f) musím vytvářet lambda funkci pole.map(|e| f(e)) - vopičárna
- Většina z Tebou uvedených jazyků se v praxi moc nepoužívá.
Když to shrnu - tak ano, existují jazyky, které umožňují závorky nepsat, ale není pravda, že je to jen jedna rodina jazyků, je to naopak většina dnes v praxi používaných jazyků a asi i rodin jazyků, je to většina jazyků vzniklých v poslední době - za good habit se to považuje i v imperativních jazycích které to striktně nepožadují a ty jazyky, které to nepožadují, za to platí nutností speciální konstrukce pro zápis "funkcionálních" operací.
-
...
Za běhu Python nerozlišuje typy, ale tagy.
....
Směšuješ informaci s implementací. To, že má nějaký objekt uloženou informaci o svém typu pomocí tagů je sice hezké, ale nic to nemění na tom, zdali ten objekt má nebo nemá typ a zdali ten typ je nebo není odlišný od typu jiného objektu.
V této oblasti je terminologie poměrně dost dobře ustálená a dá se říci:
Python je typový jazyk, neboť objekty si s sebou nesou informaci o svém typu a můžeš se na jejich typ zeptat (např. fce isinstance, __class__ vlastnost objektu atd...).
To, že python nevyžaduje deklaraci typu proměné (někdy se mluví o slabé typovosti) a že nemá type-checking (ani statický, ani dynamický) na věci nic nemění.
Beztypový jazyk je např. lisp (all is list), asi by se za něj dal považovat i javascript (pokud se budeme bavit o objektech a pomyneme to, že kromě nich tam existuje pár primitivních typů jako číslo atd...)
PS: Ad ten blog (Dynamic languages are static languages) - tak autor toho blogu nerespektuje vžitou terminologii (co je typ, třída atd...) a to, že se ohání Widgensteinem na tom nic nemění. Vymyslel si vlastní definici pojmu typ a pak dokazuje, jak jsou dynamicky typované jazyky omezené, protože v té jeho definici mají pouze jeden typ.
To pak prohlašuje jako nevýhodu, přitom tam má pouze dva argumenty, proč tomu tak je. Z toho jeden z nich je špatně (i v dynamicky typovaném jazyku lze zajistit invariant, že do dané metody vstoupí jen argument daného typu, jen je zpravidla (ale ne nutně!) kontrola vykonávána v runtime, což má své nevýhody ale i výhody, např. v preciznější kontrole) a jeden z nich je napůl nepravda a napůl půpravda (že dynamic typing stojí více procesorového času: zaprve, s JIT kompilerem to nemusí platit, zadruhé, static typing zas zabere víc času při překladu a čas programátora je dnes dost často dražší než čas počítače....)
-
Python je typový jazyk, neboť objekty si s sebou nesou informaci o svém typu
Nikoliv, v drtivé většině jazyků typy za běhu neexistují. Typ termu aproximuje vlastnosti jeho hodnoty. Za běhu tyto aproximace nepotřebujete, tam totiž znáte přesné hodnoty.
Ad ten blog (Dynamic languages are static languages) - tak autor toho blogu nerespektuje vžitou terminologii (co je typ, třída atd...)
Myslím, že autor blogu ví velmi přesně, co to je typ. Bohužel mnoho ostatních lidí význam pokřivilo.
Vymyslel si vlastní definici pojmu typ a pak dokazuje
Ne, typy vymyslel Bertrand Russell. Typy byly původně záležitost logiků, matematiků a filozofů. Harper se tedy naopak drží matematického významu slova typ.
-
Ano, můžete používat slovo "typ" pro pojem, pro který ho používal Russell. Pokud ale odborná veřejnost v oboru informatika toto slovo už používá pro pojem jiný, pak je dobrým zvykem se přizpůsobit. Jinak totiž diskuse nemá smysl, protože jeden o koze a druhý o voze. Pokud už se přizpůsobit nechcete, tak je dobré diskusi uvést tím, že vlastně mluvíte o něčem jiném než ostatní. Ale pak je zas otázka, proč o tom vůbec mluvíte, že? :-)
(Když si vyjasníme mapování slovo - pojem, tak defakto na příspěvek Python má vlastnost A jste odpověděl: nikoli, Python nemá vlastnost B).
PS: Mimochodem dosti pochybuji, že pojem typ vymyslel Russel. Nejsem odborník na Russela, ale dovolil bych si tvrdit, že filosofové už mnohem dříve operovali s tímto pojmem, byť třeba pro jeho označení použili slovo jiné (např. čím se to liší od Platónových ideí?), Russell tento pojem pouze uvedl do vztahu s formální logikou a označil ho jiným slovem.
-
Pokud ale odborná veřejnost v oboru informatika toto slovo už používá pro pojem jiný, pak je dobrým zvykem se přizpůsobit.
Právě že odborná veřejnost v oboru informatika / typové systémy používá význam z knihy Types and Programming Languages (http://www.amazon.com/Types-Programming-Languages-Benjamin-Pierce/dp/0262162091), který se shoduje s Harperovým významem.
Když pak mluvíte o jazycích s více typy jako je C# nebo Scala, tak je poměrně matoucí používat slovo typ ve dvou významech - jak navrhujete vy.
Uvažte třeba prázdný seznam Nil - ten má nekonečně mnoho typů (třeba List[Int], List[String], List[Nothing], Nil), ale za běhu jen jeden tag. Pak navíc mohou existovat jazyky, kde se za běhu používají typové derivace (a tedy i typy) a tagy naráz.
-
Jedna kniha s prominutím nedělá odbornou veřejnost. A ta kniha si prostě evidetně dělá vlastní definice, které jsou v rozporu s obecnou terminologií: už jen z anotace knihy: "A type system is a syntactic method" když mezi běžné termíny z oblasti teorie programovacích jazyků
patří např. dynamic type-checking, které se syntaxí nemá společného nic.
Kde dělám nějaké dva významy slova typ fakt nechápu.
A kde je problém s Listem nechápu také. Buďto mám list, do kterého mohu nacpat cokoli, nebo List, do kterého chci nacpat pouze řetězce. Ty mají dva různé typy a C# to od verze 2.0 umí svým typovým systémem zachytit. Pokud se budem bavit o verzi 1.0, kde generika nebyla, pak to je prostě nedokonalost typového systému C# a nikoli nedokonalostí pojmu typ.
Právě to, že i když List<Int> vypadá stejně jako List<String>, tak stejný typ nemají, je to, čím se typové jazyky liší od duck-typing languages.
-
A kde je problém s Listem nechápu také.
Dobře, jaký typ má v C# null? Jaký typ má v C# výraz "ahoj", jaký typ má v C# výraz "ahoj" as object?
Pokud programujete v Haskellu, jaký typ má v Haskellu výraz Nothing?
-
Jaký je problém v tom, že pro určení typů některých výrazů je třeba znát kontext?
-
Jaký je problém v tom, že pro určení typů některých výrazů je třeba znát kontext?
Neříkám, že tam je problém. Jen se ptám na typy daných výrazů - dělám to proto, abych demonstroval, že slovo typ používáte ve 2 různých významech.
-
Jaký je problém v tom, že pro určení typů některých výrazů je třeba znát kontext?
Neříkám, že tam je problém.
Jak je to s tím kontextem? Třeba v Javě je null typu null type, kontext nekontext.
-
A kde je problém s Listem nechápu také.
Dobře, jaký typ má v C# null? Jaký typ má v C# výraz "ahoj", jaký typ má v C# výraz "ahoj" as object?
Pokud programujete v Haskellu, jaký typ má v Haskellu výraz Nothing?
V C#-podivnosti netuším, ale v Javě je to přesně popsáno v JLS a od Javy šestky máme i:
http://www.enseignement.polytechnique.fr/informatique/Java/1.7/javax/lang/model/type/NullType.html
(v naprosté většině aplikací však můžeme předpokládat, že null je hodnota typu null který není pojmenovaný, tudíž
nelze vytvořit proměnnou, atribut či argument tohoto typu)
(podobně je NULL popsáno, i když z jiným významem, v C89, C99 atd.)
-
fakt si nemyslite, ze debata je uplne mimo konktext povodnej otazky? Vsimnite si to, obcas..
-
Jak je to s tím kontextem? Třeba v Javě je null typu null type, kontext nekontext.
Poslední verze C# nemají žádný typ jenom pro null. Nicméně dříve takový typ ve specifikaci existoval (http://ericlippert.com/2013/07/25/what-is-the-type-of-the-null-literal/).
Pokud by takový typ Null existoval, tak byl mohl být podtypem všech referenčních typů. Pak díky pravidlu subsumce (má-li výraz x typ S a typ S je podtyp typu T, pak výraz x má typ T) a faktu, že relace býti podtyp je předuspořádání, by výraz null měl kromě typu Null i všechny referenční typy. Takhle to funguje například ve Scale.
-
Radek: Furt nechápu kam míříš. Jestli myslíš rozdíl mezi deklarovaným typem a typem hodnoty nebo co (což jsou sice dva pojmy, ale naprosto jasně odlišený a navíc je mezi nima vztah). Co kdybys to "hloupejch otázek" :-) prostě napsal?
--
Galgonek: Jo, Javu zrovna detailně neznam, tak sem si to našel, tam máš pravdu že null jako takové má typ null type + speciální pravidla pro konverzi. Tam to contextově závislé není. V C# tam nic takového není, takže když člověk napíše null, tak není jasné, jakého typu null myslíš, než ho někam přiřadíš.
..
Teď jsem si přečet co píe Radek a je možný, že někde na to "vybudujou formalismus", aby šlo nějak formálně zachytit a tak určit přesný typ každého výrazu, ale zrovna v tomdle je vidět, že C# nepíšou teoretici a místo vymejšlení blbin se prostě spokojili s tim, že tomu samo o sobě typ určit nejde (taky k čemu by to bylo??)
-
fakt si nemyslite, ze debata je uplne mimo konktext povodnej otazky? Vsimnite si to, obcas..
Obavam se, ze puvodni otazka uz byla zodpovezena nekym mimo toto forum: "pouzivej VB" :-(
takze good luck a my ostatni muzeme pokracovat ve flame
-
Furt nechápu kam míříš. Jestli myslíš rozdíl mezi deklarovaným typem a typem hodnoty nebo co (což jsou sice dva pojmy, ale naprosto jasně odlišený a navíc je mezi nima vztah). Co kdybys to "hloupejch otázek" :-) prostě napsal?
Ve většině typových systémů, které nejsou substrukturální, platí vlastnost zvaná zachování typu (http://en.wikipedia.org/wiki/Subject_reduction) (type preservation nebo subject reduction), tudíž deklarovaný typ výrazu je stejný jako typ hodnoty.
Začneme s typy:
Například výraz "ahoj" v C# má typ string a všechny jeho nadtypy. Výraz "ahoj" as object má typ object. V Haskellu má výraz Nothing typy Maybe String, Maybe Int, Maybe (Maybe Int), Maybe z a nekonečně mnoho dalších. Podobně prázdný neměnný jednosměrný spojový seznam reprezentovaný hodnotou Nil má ve Scale nekonečně mnoho typů.
Dále existují tagy:
Některé jazyky - třeba C#, Java, Scala, Python - vybaví hodnoty za běhu tzv. tagy. Tagy mají různou přesnost a občas existuje souvislost s typem původního výrazu. Například u kolekce řetězců bude v C# tag List<string>, což možná přesně odpovídá typu výrazu, jehož vyhodnocením kolekce vznikla, a možná také neodpovídá - typ výrazu mohl být třeba object.
Funkcionální jazyky s algebraickými datovými typy používají tagy za běhu při pattern matchingu. Lze například deklarovat typ jednosměrný spojový seznam čísel data IntList = Nil | Cons Int IntList a tagem za běhu se pak rozlišuje, zda je seznam prázdný nebo ne.
Závěr
Z tohoto pohledu Python nemá typy, ale pouze tagy. A proč oboje nepojmenovávat stejným slovem? Protože to způsobuje zmatky - viz třeba Type Checking: typeof, GetType, or is? (http://stackoverflow.com/questions/983030/type-checking-typeof-gettype-or-is). Jak třeba budete formulovat výroky, že výraz měl typ object, vyhodnotil se na hodnotu typu object s tagem string.
A co když bude jazyk za běhu používat typy i tagy zároveň - jak to pak budete pojmenovávat?
už jen z anotace knihy: "A type system is a syntactic method" když mezi běžné termíny z oblasti teorie programovacích jazyků
patří např. dynamic type-checking, které se syntaxí nemá společného nic.
To je v pořádku - říká to, že se nejedná o sémantickou metodu. Jinak řečeno je to teorie důkazů a nikoliv teorie modelů.
-
Z tohoto pohledu Python nemá typy, ale pouze tagy. A proč oboje nepojmenovávat stejným slovem? Protože to způsobuje zmatky - viz třeba Type Checking: typeof, GetType, or is? (http://stackoverflow.com/questions/983030/type-checking-typeof-gettype-or-is). Jak třeba budete formulovat výroky, že výraz měl typ object, vyhodnotil se na hodnotu typu object s tagem string.
Chapu, jak to myslis, ale prijde mi to trochu zbytecne to rozlisovat mimo matematiku (a i v matematice bych o tom pochyboval, prijde mi, ze pripadna teorie tagu neexistuje proto, ze je ekvivalentni teorii typu). Prijde mi, ze je to snaha dotahnout trochu umele rozdeleni (mezi typy a objekty), ktere vytvari teorie typu proto, aby vubec mohla existovat. Takze to vnimam jako dost uzky pohled na ten problem - skrz tyto teorie.
Co skutecne chceme podchytit v praxi typem, IMHO, je trida operaci, ktere muzeme nad danym objektem provadet. Problem je, ze tady existuje diskrepance mezi matematikou, kde neni mozne aplikovat funkci "mimo" definicni obor, a realnym svetem pocitacu, kdy to celkem dobre mozne je, a tak dostaneme nedefinovany vysledek. Abychom ale mohli tu druhou situaci matematicky modelovat (k cemuz slouzi teorie typu), musime nekde tu hranici postavit; ale bude vzdycky trochu umela, a nikde neni napsano, ze musi stat prave tam, kde se program kompiluje (nebo alternativne tam, kde jsou konstantni data a nekonstantni vstupy).
Ta hranice totiz neni ostra. Treba Haskell nema typ "cisla s kterymi lze delit". Ale fakticky to tak je, protoze pokud budes v programu delit nulou, dostanes undefined, coz je uplne stejne "undefined", jako dostanes, pokud program vubec nezkompilujes.
Takze, z toho vyplyva, ze otazka, kolik typu existuje a ktere, zavisi na tom, kde se stanovi ta hranice. Ale jelikoz ji muzeme posunout (v momente, kdy mapujeme realny svet na matematickou realitu), jsou ty clanky zcela zbytecnou argumentaci, byt formalne teoreticky spravnou.
fakt si nemyslite, ze debata je uplne mimo konktext povodnej otazky? Vsimnite si to, obcas..
Mozna je mimo kontext, ale ma stejny typ.. ;)
-
Začnu od konce:
To je v pořádku - říká to, že se nejedná o sémantickou metodu. Jinak řečeno je to teorie důkazů a nikoliv teorie modelů.
Pokud type-system je syntaktická metoda, tak by ji nějaká sémantika právě neměla zajímat. Takže to rozhodně v pořádku není.
Fór je v tom, že dynamic type- checking by mělo bejt v Tvym názvosloví vlasně (dynamic) tag-checking. A to je přesně to, co chci ukázat, že termín dynamic tag-checking se nepoužívá: když to hodíš do googlu, tak Ti vypadne sto odkazů (a jeden z prvních odkazuje zas pouze na Harpera) - zatímco na dynamic type-checking má asi půl milionu odkazů.
Jak třeba budete formulovat výroky, že výraz měl typ object, vyhodnotil se na hodnotu typu object s tagem string.
Typ výrazu je object a hodnota výsledku je typu String? (Mimochodem IMHO ses sám do toho zapletl, protože jestli zastáváš názor, že typ je čistě syntaktická záležitost, takže se nemá na něco vyhodnocovat, ne?)
Už snad chápu, o jaké dvojakosti mluvíš, ale ta ničemu nevadí, protože zde je striktně oddělená doména: v případě statického typování se pohybujem v oblasti výrazů, zatímco v dynamickém typování se pohybujem v oboru hodnot. Nedochází tedy k žádnému přetížení významů, pouze ten termín znamená něco trochu jiného v syntaxi a něco jiného v sémantice, které ale operují s jinou množinou popisovaných objektů. Pokud je to i tak třeba výslovně odlišit, pak k tomu jsou určeny slova statický a dynamický. Tak furt nerozumím, kde je potřeba měnit evidetně zavedenou terminilogii.
Co až budou programovací jazyky, které používají obojí? A copak nejsou? Ve spoustě scénářů člověk se staticky typovanym jazykem v určitejch scénářích kontroluje typ (podle Tebe tag) za běhu, protože mu z nějakého důvodu (ať už kvůli špatnému návrhu programu, nebo třeba v důsledku absence generik viz starší java) statická kontrola nestačí. Zvládnout tuto distinkci patří k základním dovednostem programátora. Jak jsem pochopil, ta skupina používající slovo tag pochází spíše z oblasti formální logiky a dedukce. Pro klasifikaci jazyků pro účely vybrání vhodného pro praxi je, i kdybych Tvoji terminologie byla standardní v oblasti dedukce, normální užít terminologii z oblasti programování.
Navíc, když stejný termín v oblasti syntaxe a sémantiky má svůj smysl, protože ukazuje na velmi přímý vztah mezi těmito dvěma pojmy:
1) v každém rozumném programu platí, že výraz typu A je vyhodnocen na hodnotu typu A či potomek A
2) velmi často při čtení programu Ti stačí informace, že daný objekt je typu (tagu) A, což může vyplývat jak ze syntaxe, tak u "např. pythonu" sémantiky. A to, že ve skutečnosti tam je objekt tagu potomek A je šumák.
A navíc sám jsi ještě navíc demonstroval to, že i termín tag je přetíženej, protože pokud chceš slovem tag označovat dynamický typ, pak jím nemůžeš postihnout např. (ne)prázdnost seznam při pattern matchingu, jaks psal. Anebo musíš rozvolnit vztah tagu a typu, čímž opět Ti vyvstane potřeba pro termín "tagu zachycujícího typ" a jsme zpátky.
-
Pokud type-system je syntaktická metoda, tak by ji nějaká sémantika právě neměla zajímat.
Tak to je. Zadefinujete co jsou typy, co jsou výrazy a následně pravidla pro typový systém, která výrazům přiřazují typy.
Pak samozřejmě chcete ukázat nějaký vztah typového systému vůči sémantice jazyka - třeba korektnost. Typový systém je deduktivní systém, ale na rozdíl od důkazových systémů není tolik kladen důraz na bezespornost.
Fór je v tom, že dynamic type- checking by mělo bejt v Tvym názvosloví vlasně (dynamic) tag-checking. A to je přesně to, co chci ukázat, že termín dynamic tag-checking se nepoužívá: když to hodíš do googlu, tak Ti vypadne sto odkazů (a jeden z prvních odkazuje zas pouze na Harpera) - zatímco na dynamic type-checking má asi půl milionu odkazů.
Ano, bohužel, taková je situace. Opravil jsem vás proto, aby se to do budoucna zlepšilo.
Lidé, co se zabývají teorií typů, se IMO příliš nezajímají o tzv. dynamicky typované jazyky, neboť to je z hlediska teorie typů trivialita (žádné typy / jeden typ). Proto se termín tag-checking nevyskytuje příliš často. Viz komiks (http://ro-che.info/ccc/17).
Typ výrazu je object a hodnota výsledku je typu String? (Mimochodem IMHO ses sám do toho zapletl, protože jestli zastáváš názor, že typ je čistě syntaktická záležitost, takže se nemá na něco vyhodnocovat, ne?)
Ano, pojmy jako hodnota a vyhodnocení jsou už věcí sémantiky. To však nebrání tomu, aby se mezi typy a relací vyhodnocení vybudoval vztah. To je přeci stejné jako v logice, kde dokazuji úplnost a korektnost. A následně, když pak něco dokáži, tak říkám, že je to pravdivé.
A mj. psal jsem, že hodnota je rovněž typu object - právě proto, že většinou platí zachování typů. Naopak tag může být něco jiného.
v případě statického typování se pohybujem v oblasti výrazů, zatímco v dynamickém typování se pohybujem v oboru hodnot.
Hodnoty jsou speciálním případem výrazů, takže ne. Při definici sémantiky se určí, jaké výrazy budou hodnoty.
Anebo musíš rozvolnit vztah tagu a typu, čímž opět Ti vyvstane potřeba pro termín "tagu zachycujícího typ" a jsme zpátky.
Já na žádném vztahu netrvám viz moje věta: "Tagy mají různou přesnost a občas existuje souvislost s typem původního výrazu".
Co až budou programovací jazyky, které používají obojí? A copak nejsou?
Psal jsem obojí za běhu. Žádný známý mě nenapadá - typy většinou použije kompilátor/JIT (třeba pro vyřešení overloadingu), a pak se už nepoužívají. Viz příklad "ahoj" as object, jenž má typ object, tj. nemůžete ho dát funkci, která chce string. Nicméně za běhu se už k typu nedostanete - kompilátor nikam neuloží, že zde odvodil typ object, k dispozici však máte tag string.
Jazyk, který mám na mysli, by sémantiku definoval např. pomocí typových derivací (tj. odvození typů, která vzniknou při typové kontrole). To se občas dělá u jazyků s průnikovými typy.
-
Proč myslíte, že je Python nahraní? Tím to nechci obhajovat, zajímá mě názor proč v současnosti nejpoužívanější skriptovací jazyk je pouze na "hraní"?
Protože je tzv. dynamicky typovaný - přesněji jeho typový systém má pouze jeden typ.
1. To ze typy staticky nekontroluje neznamena ze tam nejsou.
2. Staticky typovani ma smysl tam kde potrebujes maximalni vykon, protoze tim pomuzes optimalizatoru. Ocekavat od toho cokoli jinyho je hloupost, pripadne sebemrskacstvi...
-
Jestli vám jde o pochopení OPRAVDOVÉHO objektového modelování a programování, tak Smalltalk, který je minimalistický a přitom mocný, nekompromisně objektový a bez balastu. V praxi se moc nepoužívá, ale na pochopení asi nic lepšího nenajdete. Pak můžete klidně to C# a uvidíte, co je to za nakynutý bastl a co všechno to neumí. (Python neznám, tak o něm mluvit nebudu, ale co si pamatuju, tak mi přišel jako takový splácaný eintopf).
No nevim jestli bych jazyk bez multiple-dispatch nazval "opravdovy oop". Spis bych doporucil se podivat na CLOS (common lisp object system)
-
2. Staticky typovani ma smysl tam kde potrebujes maximalni vykon, protoze tim pomuzes optimalizatoru. Ocekavat od toho cokoli jinyho je hloupost, pripadne sebemrskacstvi...
Otazka je naco potom vznikaju silne staticky typovane jazyky s pokrocilou type inference, ked sa da pouzit rovno dynamicky jazyk? C# ma aj dynamicke typovanie a late binding ale malokedy sa tato moznost vyuziva. Preco?
-
2. Staticky typovani ma smysl tam kde potrebujes maximalni vykon, protoze tim pomuzes optimalizatoru. Ocekavat od toho cokoli jinyho je hloupost, pripadne sebemrskacstvi...
Bohatý typový systém má rovněž smysl, když chcete dokázat určité vlastnosti programu (viz třeba CompCert (http://compcert.inria.fr/compcert-C.html)) nebo když chcete prostě jen něco dokázat (ani to nemusí mít nic společného s programem).
-
Radek:
No z tvojí odpovědi mi v podstatě vyplývá todle: Existovali lidi co pragramujou, ty z potřeby nedostatečnosti statickýho typování vyvinuli dynamicky typovaný jazyky. No, jenže to nesedělo některejm lidem vyvíjejícím své typové teorie a tak se ty jazyky do tý teorie snažili nacpat. Ale ono jim to nešlo.
A tak co udělali? Místo aby typovou teorii nějak rozšířili či pozměnili tak, aby pokrývala i dynamicky typované jazyky, vymysleli jinou abstrakci - tagy - a dynamicky typované jazyky se do ní snažej nacpat. A snažej se lidi co používaj dynamický jazyky přesvědčit, ať jejich novou teorii používaj.
Protože ale vymysleli teorii něčeho jinýho, neboť (dynamický) typ narozdíl od tagu JE SVÁZANEJ se statickým typem a tato vlastnost JE CHTĚNÁ a UŽITEČNÁ a hlavně je to KLÍČOVÁ vlastnost dynamickýho typu, a protože vlastně evidentně vůbec nepochopili praktičnost dynamických jazyků, (např. že platit časem běhu za rychlý vývoj je rozumné - viz Harper), tak kupodivu svoji terminologii do širší praxe neprosadili. A tak si zhrzení aspoň z majority dělaj srandu komixama. Budiž jim to přáno... :-)
Jinak:
"Typový systém je deduktivní systém." - Nikoli. Typový systém v oboru dekdukce je deduktivní systém. Co to je v programovacích jazycích nevím, protože to není natolik složité, abych se o to hlouběji zajímal, ale je to popsáno ve specifikaci každého jazyka. Deduktivní typový systém (alespoň takový jak jsi nastínil) ale evidentně nepopisuje typové systémy programovacích jazyků dobře (když neumí popsat správně co je to dynamický typ a jeho vztah k statickému typu) a protože pro praxi nepřináší zatím nic natolik užitečného, aby ospravedlnil tuto redefinici, není zatím důvod proč se užitečných vlastností programovacího typového systému zbavovat ve prospěch deduktivního.
Jazyk, který by používal dynamický i statický typy za běhu? A prosím proč?? Když je k dispozici dynamickej typ, tak statickej typ není potřeba. A pokud by byl jazyk, kterej by kromě (libovolnýho) typu navíc podporoval tagy (tj. anotaci bez vazby na typ). Klidně ať takovej je, pak tam tomu budu tagy klidně říkat - protože to bude něco jinýho než dynamickej typ.
Navíc Vaše teorie vede přesně k tomu, (jak už psal Maze) - že co se nevejde do Vaší teorie, tak není. Je to perfektně vidět např. na Cythonu (což je defakto dialekt Pythonu), kde najednou ty neexistující pythonovské typy jdou explicitně napsat a syntakticky kontrolovat. Ano, přesně ty typy, které v tom pythonovském zdrojáku podle Vás nejsou ;-). Z toho je vidět, že ta deduktivní teorie (díky tomu, jak je odstřižená od sémantiky) nezachycuje vhodně ani to, co je statický typ. Či že spíše vede k tvorbě modelů, které to nezachycují dobře.
-
Zvrhlo sa to tu na OT takze k povodnej otazke.
Se C# jsem došel jen k objektovému programování, ale tam jsem celkem tvrdě narazil. A o Pythonu se říká, že je to jazyk vhodný pro začátečníky, tak mě napadlo, že bych se tím mohl zlepšit.
Ještě dodám, že hodlám C# v budoucnosti používat, teď jde jen o to, zda s tím "začít" už teď nebo až po Pythonu.
Ked ti ide primarne o C# bola by blbost zacinat kvoli tomu s Pythonom (alebo inym jazykom). Hlavne ak sa jedna o OOP tak v oboch jazykoch je to dost rozdielne, napr. Python zrejme (este som to nepouzil) podporuje viacnasobnu dedicnost a preto nema nieco take ako nterface (aspon ja som to este nevidel). V C# (zrejme ako v Jave) je mozne dedit iba z jednej triedy a preto sa tam (takisto ako v Jave) interface asi hodne pouziva. Doporucujem, ak nieco s C# nechapes najdi si k tomu tutorial, alebo sa spytaj na diskusnom fore, ale miesat do toho dalsi jazyk ti asi nepomoze.
Na druhej strane Python sa ti moze vyborne hodit na beznu pracu, ked potrebujes nieco rychlo urobit. Podla mojho nazoru sa v nom vyvija rychlejsie ako v C#. Ale moj nazor ber s rezervou, pretoze ja som C# musel pouzit len raz a myslim si ze je to okopirovana Java kde namiesto main() treba pisat Main() :D
-
a protože vlastně evidentně vůbec nepochopili praktičnost dynamických jazyků, (např. že platit časem běhu za rychlý vývoj je rozumné - viz Harper)
IMO jazyky s bohatšími typovými systémy a dobrou typovou inferencí mi právě umožňují rychlý vývoj a usnadňují úpravy již napsaných programů - viz Haskell, F#, OCaml (, Scala). V tzv. dynamicky typovaných jazycích je problém i obyčejné přejmenování. Navíc se slabým nebo žádným typovým systémem jste omezen pouze na primitivní abstrakce, protože složitější abstrakce je těžké napsat bez dopomoci správně.
pro praxi nepřináší zatím nic natolik užitečného, aby ospravedlnil tuto redefinici, není zatím důvod proč se užitečných vlastností programovacího typového systému zbavovat ve prospěch deduktivního
Můžete garantovat určité vlastnosti programu a programovacího jazyka (třeba onu korektnost), což je užitečné. Používá se to při návrhu programovacích jazyků (podívejte se třeba na programovací jazyk Mezzo (http://gallium.inria.fr/~fpottier/publis/fpottier-core-mezzo.pdf) nebo Ur/Web (http://www.impredicative.com/ur/manual.pdf)).
BTW jak při návrhu programovacího jazyka poznáte, že typový systém je správně?
Jazyk, který by používal dynamický i statický typy za běhu? A prosím proč??
Jak jsem psal, můžete pomocí nich definovat sémantiku. Konkrétně třeba viz Elaborating Intersection and Union Types (http://www.cs.cmu.edu/~joshuad/papers/intcomp/Dunfield12_elaboration.pdf). Stručně řečeno v jazyce povolí smíchat 2 termy do jednoho. Tento jeden term se pak může vyhodnotit na libovolný z oněch dvou termů. To, jak se bude vyhodnocovat může být určeno typovou derivací.
-
Logiku, umíš dobře Haskell? Já jen, že jsem měl podobný názor do té doby, než mě napadlo z dlouhé chvíle v tom napsat dvě ne úplně malé aplikace. Od té doby navzdory tomu, že programuju v pythonu a coffeescriptu, musím říct, že mi haskellový typový systém v těchhle jazycích strašně moc chybí - a to z toho důvodu, že by mi velmi urychlila vývoj. Ono to totiž odchytá neuvěřitelně velké množství chyb, navíc to docela podporuje code reuse a je to velmi přehledné.
Nicméně čistě z praktického pohledu, pokud dneska člověk píše třeba webové aplikace, pak de-fakto každý vstup, ale především každý SQL dotaz je vlastní typ - a bohužel s tím je prakticky trochu problém, protože když pak má člověk 100 typů kvůli 50 funkcím, s SQL dotazem, tak je to docela otrava. Nicméně věřím, že i na tom se pomalu pracuje :)
-
Radek: Možná že pro Tebe silně typové jazyky vhodnější jsou. Ale obecně praxe ukazuje, že jazyky s bohatým typovým systémem - a obzvlášt ty, které jsi vyjmenoval - jsou na vývoj drahé. Jestli je to způsobeno jejich "ukecaností", tím, že je je těžké zvládnout, kvalitě knihoven (což zas ale mluví o praktičnosti navrhovatelů jazyka) nebo prostě postavení hvězd se můžeme dohadovat. Ale přijde mi poněkud (rozuměj dost hodně :-)) namyšlené tvrdit, že ty zástupy programátorů co používá "netypové" jazyky jsou blbci, protože zbytečně programují v křápech, když tady existuje úžasný jazyk, který vyřeší všechny jejich potřeby a budou v něm psát pětkrát rychlejc. Asi to bude trochu jinak.
..pro praxi.... Ano, když budu potřebovat garantovat korektnost jazyka, tak sáhnu po teorii, která mi to umožní verifikovat. Já netvrdím, že Ta deduktivní teorie je nanic. Tvrdím, že se hodí k něčemu, ale k něčemu zas ne a tak není důvod ji cpát tam, kam se nehodí. Tzn. klidně udělám jazyk s programovacím typovým systémem, pak vezmu jí nejbližší deduktivní teorii a jí to ověřím a popř. návrh jazyka upravím... nebo můžu i postupovat opačně, vyjít z deduktivní teorie: ukazuje se ale, že PJ vzniklé "z praxe" jsou v praxi úspěšnější a tedy se dá s velkou jistotou říci, že užitečnější, než ty, které vzejdou z teorie...
...můžeme definovat sémantiku ... intersection and unions... A je to potřeba? Používá to nějaký jazyk, který je masivněji používán v praxi? Proč nahrazovat definici, která nám umožňuje zachycovat a klasifikovat to, co zachytit a klasifikovat potřebujeme, definicí, která nám nezachycuje to, co potřebujeme, ale zato umožní věc, kterou nepotřebujeme?
V pythonu máme typy. V C máme typy. Ty typy se něčím liší a něco mají společné. Úkol teoretika není přijít s teorií, která řekne: v Pythonu typy nejsou. Úkol teoretika je přijít a vymyslet teorii, která nejenže vystihne rozdíly, mezi těmi typy (to se té teorii povedlo dokonale :-)), ale také vystihne to, co mají tyto typy společného. Až přijdete s touto teorií, určitě ji bez problémů prosadíte...
Andy: Haskell umím natolik, že sem měl kdysi z jednosemestrový přednášky jedničku ;-) a od tý doby jsem ho asi neviděl. Takže moc ne :-) Ale jinak souhlasím, typový systém je dobrá věc a čím silnější, tím lepší - taky programuji spíš v "netypových" jazycích a dělám chyby, které by mě silně typový systém odchytil, jen co bych je napsal. Jenže - přesně jak píšeš - se za to něco platí. Někdy je to cena malá (pro velké aplikace se spíše hodí typově silné jazyky), někdy je ta cena příliš velká. A ta dělící čára nejde jen malé/velké aplikace. Ona jde i naskrz programovacíma metodikama: na agilní vývoj se hodí spíše "netypové" jazyky, zatímco silně typové jazyky se hodí spíš na tradiční vývojový cyklus atd... A i každému sedí něco jiného: někdo je roztržitý a tak ocení typovou kontrolu hodně, někdo je schopen psát "z první" a pak je s míň ukecaným jazykem (to jde většinou ruku v ruce) rychlejší.
-
Kefalin a ci tak predstavujete pod "drahe na vyvoj"?
prototypovani, protoze vas k vyvoji a rozvoji aplikace, ktera existuje 10 let jeste nikdo nepustil, protoze mate pro takovou situaci zcela nekompatibilni uvazovani?
-
Proč ty invektivy? Chceš tvrdit, že vývoj většiny dnes psaných komerčních softů bys dokázal zařídit v Haskellu stejně draho, jako i třeba v PHP nebo Pythonu nebo C#? To, že existují i software, u kterého se vyplatí investovat do dlouhodobé udržovatelnosti kódu, verifikovatelnosti atd... je přeci jasné - ale je i jasné, že takových kódů je v komerční praxi menšina.
To, že jsou lépe placené je pravda - ale to je právě proto, že je složitější je zvládnout. Proto je blbina tvrdit, že enterprise jazyky jsou lepší než bastlířské. Nejsou. Jsou na něco dobré na něco ne. Akorát komerční praxe a zájem o programátory ukazuje, že těch věcí, kde se firmám vyplatí je používat je menšina.
-
Tenhle argument mi trochu připadá ve stylu "nemá smysl učit se hrát na housle jako Perlman". To, že byste byl lépe placený je pravda - ale to je právě proto, že je složitější se to naučit. Proto je blbina tvrdit, že hrát virtuózně na housle je lepší než hrát jenom slušně. Není. Je to na něco dobré a na něco ne. Akorát komerční praxe a zájem o houslisty ukazuje, že těch věcí, kde se firmám vyplatí najímat virtuozy je menšina.
Množství řádek kódu v Haskellu se nijak diametrálně neliší od počtu řádek kódu v pythonu. Jenže haskell na tohle není moc enterprise jazyk, protože má sice vynikající typový systém, ale mizernou podporu pro struktury a moduly (a databáze...). Ale těch jazyků je víc a zvažuju, že pro příští projektík zkusím třeba Scalu (nebo možná Haskell s esqueleto...).
-
Ale já přeci nikde netvrdím něco o umění hrát. Já celou dobu hovořím o nástrojích. A tam by opravdu blbost byla: vyrábět pouze housle pro virtuosy, do jejichž pořízení musí člověk investovat několik milionů.
Druhá věc pak je, že to není přesné přirovnání, protože to není tak, že např. python je nástroj pro začínající hráče a haskell pro virtuosy. Každej jazyk má trochu jiný přednosti a tak se dají najít situace, kdy je vhodnější jeden nebo druhej (pomíjím teda PHP, který má nedostatků přehršel, ale výhody aby člověk pohledal, snad jen Ti levní vývojáři a tedy rychlá křivka učení ;-)).
Radkem prezentovaný výhody jazyků typu formální verifikovatelnost atd... jsou prostě vlastnosti, které člověk pro běžný vývoj nepotřebuje. A za to, že tam ty vlastnosti jsou, se nějak platí. Např. tím, že když máš striktní typový systém, tak bývá vhodné na začátku si nějak promyslet jak teda budou ty typy v danym případě vypadat. A to se např. nemusí hodit do agilních metodik, kdy začínáš psát slona a výsledkem je růžovej robotickej vysavač. (To, že to i v agilních metodikách často pomůže a že problém agilních metodik je mj. blivajz, co z nich leze, nepopírám, vše má + a -). Statická kontrola někdy zdržuje při mockování pro účely testů apod...
Další věc je ta, na kterou si přesně narazil s Haskellem. Je krásné být virtuos na liru, ale když pak neseženeš noty a ani se nebudeš mít od koho zdokonalovat, může Ti být houby platné, že na liru zahraješ víc, než na housle. To, že jazyk má rychlou křivku učení zpravidla znamená, že pro něj existuje více zdrojů, více knihoven atd...
O výše uvedené ilustrace se samozřejmě můžem zas dokola hádat, ale není to to podstatné, co tvrdím. A rozhodně tím nechci tvrdit, že je statická typová kontrola špatná. Není, je dobrá a užitečná, jen má jako každý nástroj své limity a nevýhody. To, co tvrdím, je, že to, že v komerční praxi převažují některé jazyky (byť jsou to třeba jazyky dle akademických kritérií méněcené) není blbostí komerčních programátorů, ale že to má své důvody.