» »

Tipi v programskih jezikih

Tipi v programskih jezikih

Gandalfar ::

  • polepsal: Mavrik ()

jype ::

Da Python ne pozna tipov je podla laž. Tudi če bi nize primerjal v kateremkoli drugem jeziku, bi dobil enak rezultat.

Zgodovina sprememb…

AndrejO ::

jype je izjavil:

Da Python ne pozna tipov je podla laž. Tudi če bi nize primerjal v kateremkoli drugem jeziku, bi dobil enak rezultat.

Tudi newtonovi zakoni so navadna laž, pa so še vedno dovolj dober približek resnice, da se jih lahko predstavi začetnikom v fiziki.

Zgodovina sprememb…

jype ::

Ni res (niti približno), da python "ne pozna tipov".

Zgodovina sprememb…

alexa-lol ::

npr. primer tega fenomena v JS
http://jsfiddle.net/GLtqV/

Vneseš 6 in 7, vrne ti 67 ker 6 in 7 obravnava kot string.

Zgodovina sprememb…

AndrejO ::

jype je izjavil:

Ni res (niti približno), da python "ne pozna tipov".

Ja, resnična resnica je, da nima eksplicitne tipizacije spremenljivk. Kar je za začetnika nekako tako, kot bi napisal 科技大.

Če želiš zblojen primer, kjer implicitna pravila ugotovijo, da je niz "55" manjši od niza "500", pa si poglej PHP. Torej se tudi ti rad zlažeš. ;)

Zgodovina sprememb…

techfreak :) ::

Pri "55" > "500" se vidi da gre dejansko za niza, ce pa recimo od uporabnika sprejmes spremenljivko preko GET/POST metode pa tako pricakujes string, ki ga dodatno pretvoris v npr. int, tako pri kaksnem PHP ($_GET['num']) kot pri kaksnem C#/ASP.net (Request.QueryString["num"]).

Sicer je PHP precej poseben ker spremenljivke implicitno pretvarja, med tem ko pa Python dejansko ohrani string kot string, vendar primerja po naslednjih pravilih: https://docs.python.org/2/tutorial/data...

Zgodovina sprememb…

AndrejO ::

techfreak :) je izjavil:

Pri "55" > "500" se vidi da gre dejansko za niza, ce pa recimo od uporabnika ...

Zadeve se začno komplicirati pri procedurah/funkcijah/metodah/..., kjer moraš pri jezikih, ki ne uprabljajo eksplicitnih tipov, uporabljati komentarje v katerih dokumentiraš dovoljene ali pričakovane tipe argumentov.

Te stvari pa se pojavijo že takoj, ko imaš pred seboj karkoli več od učnega primera.

jype ::

AndrejO> kjer moraš pri jezikih, ki ne uprabljajo eksplicitnih tipov, uporabljati komentarje v katerih dokumentiraš dovoljene ali pričakovane tipe argumentov.

Neverjetno, ane, da moraš človeku, ki uporablja tvojo funkcijo povedat, kakšnega tipa argumente pričakuješ.

Da moraš to povedat računalniku, je pa popoln nesmisel, ker računalnik to že ve.

techfreak :) ::

Image generateThumbnail(Image image, Size size);
vs.
generateThumbnail($image, $size);

Pri prvem takoj ves da pricakuje sliko tipa Image ter velikost tipa Size, prav tako ti pa vrne objekt tipa Image.
Pri drugi nimas pojma kaj $image je, lahko je pot do slike, lahko je string ki vsebuje sliko prebrano iz fajla, lahko pa da mu podas nek cisto svoj tip. Prav tako neves kaj je size, ali je to custom tip, ali array ki vsebuje width in height, ali nekaj cisto tretjega.

Sicer lahko to enostavno resis da je koda pravilno komentirana, urejevalnik/IDE pa zna prebrati komentarje in ti jih pravilno prikazati ko pises klic metode. Se vseeno je pa problem ker si se lahko ti zmotil in uporabil napacno spremenljivko oz. nekje nevede shranil drug tip v to spremenljivko.

Pri staticnem tipiziranju ti prevajalnik vrne napako ce si kaj taksnega hotel narediti, prav tako ti pa lahko IDE ze med pisanjem kode lazje pomaga.

jype ::

techfreak :)> Pri staticnem tipiziranju ti prevajalnik vrne napako ce si kaj taksnega hotel narediti, prav tako ti pa lahko IDE ze med pisanjem kode lazje pomaga.

Hkrati pa ti počneš reči, ki jih lahko (in bi jih torej moral) računalnik in obsceno zakompliciraš programiranje reči, pri katerih so tipi znani šele med poganjanjem programa, ne pa med njegovim prevajanjem in zato o takih rešitvah sploh ne razmišljaš, čeprav so v resnici trivialne in nadvse dobrodošle.

techfreak :)> Pri drugi nimas pojma kaj $image je, lahko je pot do slike, lahko je string ki vsebuje sliko prebrano iz fajla, lahko pa da mu podas nek cisto svoj tip. Prav tako neves kaj je size, ali je to custom tip, ali array ki vsebuje width in height, ali nekaj cisto tretjega.

Tudi pri prvi nimaš pojma, kaj je karkoli:

it tni(it i, s2d s);

Zgodovina sprememb…

  • spremenilo: jype ()

AndrejO ::

jype je izjavil:

AndrejO> kjer moraš pri jezikih, ki ne uprabljajo eksplicitnih tipov, uporabljati komentarje v katerih dokumentiraš dovoljene ali pričakovane tipe argumentov.

Neverjetno, ane, da moraš človeku, ki uporablja tvojo funkcijo povedat, kakšnega tipa argumente pričakuješ.

Da moraš to povedat računalniku, je pa popoln nesmisel, ker računalnik to že ve.

Nekateri temu rečemo "nepotrebno podvajanje" in se raje zanašamo na računalnik, ki bo nepazljivega programerja opzoril na napako, kot pa na končnega uporabnika.

jype je izjavil:

Hkrati pa ti počneš reči, ki jih lahko (in bi jih torej moral) računalnik in obsceno zakompliciraš programiranje reči, pri katerih so tipi znani šele med poganjanjem programa, ne pa med njegovim prevajanjem in zato o takih rešitvah sploh ne razmišljaš, čeprav so v resnici trivialne in nadvse dobrodošle.

Najboljša rešitev ne obstaja, edina objektiva resnica je, da je optimalna rešitev vedno subjektivna.

phyro ::

jype je izjavil:


Tudi pri prvi nimaš pojma, kaj je karkoli:

it tni(it i, s2d s);

seveda veš. To, da ne poznaš kaj je kakšen tip in zarad tega rečeš, da ne veš nima nobenga smisla. V bistvu je isto kot če bi začetniku pokazu f(int a) in mu reku "ja vidš da ne veš" sam zato, ker ne ve še kaj je int.

jype ::

phyro> seveda veš. To, da ne poznaš kaj je kakšen tip in zarad tega rečeš, da ne veš nima nobenga smisla. V bistvu je isto kot če bi začetniku pokazu f(int a) in mu reku "ja vidš da ne veš" sam zato, ker ne ve še kaj je int.

Tako je. Ampak ti ne veš kaj je s2d, čeprav jaz vem, kakšne parametre sprejmejo funkcije knjižnic, ki jih uporabljam.

AndrejO> Nekateri temu rečemo "nepotrebno podvajanje" in se raje zanašamo na računalnik, ki bo nepazljivega programerja opzoril na napako, kot pa na končnega uporabnika.

Nepotrebno podvajanje je navajanje tipov. Računalnik ve, katerega tipa so stvari, nobene potrebe ni, da mu bi programer to eksplicitno razlagal.

AndrejO> Najboljša rešitev ne obstaja, edina objektiva resnica je, da je optimalna rešitev vedno subjektivna.

Nah, metrike, ki ti omogočajo rešitve primerjat med sabo, že dolgo poznamo. Ena pomembnejših je čas, ki ga porabi programer, da od sebe da karkoli uporabnega in pri tem začuda vodijo rešitve, ki ne utrujajo z eksplicitnim navajanjem tipov.

Utk ::

In Python 3.x the behaviour has been changed so that attempting to order an integer and a string will raise an error:

Če so kar sred igre spremenili pravila igre, potem so se vsaj enkrat že morali narobe odločit, najverjetneje pa dvakrat, ker še ena napačna odločitev je že ta, da greš tako pomembno stvar spreminjat.

Ena pomembnejših je čas, ki ga porabi programer, da od sebe da karkoli uporabnega in pri tem začuda vodijo rešitve, ki ne utrujajo z eksplicitnim navajanjem tipov.

Vse do neke meje. Utrujat če primerjaš 1.0 z 1 je res neumno, 1 z "1" pa očitno ne...če bi mu runtime tam crknu, če že kompiler ne, bi točno vedel kje je problem, tako se je pa njegov čas da reši nalogo brezveze povečal.

Zgodovina sprememb…

  • spremenil: Utk ()

jype ::

Utk> Če so kar sred igre spremenili pravila igre, potem so se vsaj enkrat že morali narobe odločit, najverjetneje pa dvakrat, ker še ena napačna odločitev je že ta, da greš tako pomembno stvar spreminjat.

V primeru avtorja teme je primerjal med seboj stringe, ne integerjev in stringov, tako da je zanj to nepomembno.

Python 3 je znatno drugačen od Pythona 2 na ogromno načinov, zato se ju sploh ne smatra za isto platformo, hkrati je pa uspešno primerjanje jabolk in hrušk zagotovo nevarna stvar. Python pozna tipe in ga nič ne stane, da se pritoži ob potencialno nevarnih konstruktih.

Utk> 1 z "1" pa očitno ne...če bi mu runtime tam crknu, če že kompiler ne, bi točno vedel kje je problem, tako se je pa njegov čas da reši nalogo brezveze povečal.

Ker je primerjal "1" z "1" so tvoji pomisleki odveč (ker bi enako napako lahko storil v _vseh_ jezikih).

Zgodovina sprememb…

  • spremenilo: jype ()

AndrejO ::

jype je izjavil:

AndrejO> Nekateri temu rečemo "nepotrebno podvajanje" in se raje zanašamo na računalnik, ki bo nepazljivega programerja opzoril na napako, kot pa na končnega uporabnika.

Nepotrebno podvajanje je navajanje tipov. Računalnik ve, katerega tipa so stvari, nobene potrebe ni, da mu bi programer to eksplicitno razlagal.

def less(a, b):
  """Funkcija deluje pravilno za celoštevilske podatke."""
  return a < b

Nobene potrebe, da bi programer razlagal kakterega tipa smejo ali morajo biti stvari?

jype je izjavil:

Nah, metrike, ki ti omogočajo rešitve primerjat med sabo, že dolgo poznamo. Ena pomembnejših je čas, ki ga porabi programer, da od sebe da karkoli uporabnega in pri tem začuda vodijo rešitve, ki ne utrujajo z eksplicitnim navajanjem tipov.

Če te muči čas do prototipa, potem je podarek ta tej metriki pomemben. Če so cilji drugačni, potem je tudi teža te metrike drugačna. Ocena o teži posamične metrike je vedno subjektivna.

Sam trenutno pišem kodo pod premiso, da je tisti, ki bo vzdrževal ali uporabljal mojo kodo, neuravnovešen psihopatski morilec, ki pozna moj naslov. "Time to prototype" pri temu več nima neke posebne teže.

V okolju startupa, kjer pa bodisi imaš prototip, bodisi te ni, pa je težave seveda nekje čisto drugje.

jype je izjavil:

V primeru avtorja teme je primerjal med seboj stringe, ne integerjev in stringov, tako da je zanj to nepomembno.

Pomembno je, da jih je primerjal nevede. Python je s svojim pristopom dvorezen meč. Začetnika ne obremenjuje s formalizmi, hkrati pa ne spodbuja razmisleka o dejanskih procesih "pod havbo".

Zgodovina sprememb…

  • spremenil: AndrejO ()

Utk ::

Tista naloga ni najboljši primer, ker v resnici nikoli ni rekel, da bi tisto morala bit številka, ampak v katerem drugem jeziku bi largest definiral kot float, raw_input bi vrnil recimo string, in slej ko prej bi tu prišlo do problema. Tako pa lahko narediš 10 tutorialov pa se sploh ne zavedaš kako ga lomiš, ker se ne sekiraš za tipe. Python ta problem skrije, in v 50% primerih je to pravilno, v 50 pa pač ne.

Nepotrebno podvajanje je navajanje tipov. Računalnik ve, katerega tipa so stvari, nobene potrebe ni, da mu bi programer to eksplicitno razlagal.

To je res, ni potrebe da bi programer računalniku razlagal, je pa potreba, da računalnik to razloži programerju. C# (pa še kdo) ima to lepo rešeno z var. Lahko je karkoli, ampak kaj je v resnici, določi že compiler in ti to tudi pokaže takoj v naslednji vrstici, če se zaradi tega kaj sekiraš, prav, če ne, pa tudi prav. Če ti še to ni dovolj imaš pa še dynamic, ampak tu se pa vsaj zavedaš, da moraš pazit.

Zgodovina sprememb…

  • spremenil: Utk ()

AndrejO ::

Utk je izjavil:

To je res, ni potrebe da bi programer računalniku razlagal, je pa potreba, da računalnik to razloži programerju. C# (pa še kdo) ima to lepo rešeno z var.

Ali pa C++1x z "auto". Ampak takoj, ko se začneš zanašati na ta pripomoček, se zabiješ v isto steno v katero se zabiješ s Python.

Zato imaš potem "zanimiva" samoomejevalna pravila. Tako npr. nikoli ne uporabiš "auto" kot tip argumenta ali tip rezultata. Uporabljaš ga zgolj v "kratkih" kontekstih - nekaj vrstične funkcije ali samo notranjost zank, ipd.

Vse so to orodja, ki hkrati pomagajo in škodijo.

jype ::

AndrejO> hkrati pa ne spodbuja razmisleka o dejanskih procesih "pod havbo".

To očitno ni res, glede na to da je moral havbo odpret že pri praktično prvi nalogi.

Utk> Python ta problem skrije, in v 50% primerih je to pravilno, v 50 pa pač ne.

Ničesar ne skrije.

Utk> ampak v katerem drugem jeziku bi largest definiral kot float

Zakaj pa ne string? Če je začetnik ne vidim razloga, da ne bi uporabil stringa. Glede na primere, ki smo jih že videli na tem forumu, bi se mi to zdelo še precej nedolžno.

AndrejO> Vse so to orodja, ki hkrati pomagajo in škodijo.

Tudi statični tipi so orodje, ki hkrati pomaga in škodi.

arjan_t ::

AndrejO je izjavil:

Utk je izjavil:

To je res, ni potrebe da bi programer računalniku razlagal, je pa potreba, da računalnik to razloži programerju. C# (pa še kdo) ima to lepo rešeno z var.

Ali pa C++1x z "auto". Ampak takoj, ko se začneš zanašati na ta pripomoček, se zabiješ v isto steno v katero se zabiješ s Python.


Ali pa mogoce pogledas kaksen jezik keterega type-system ni iz 80. let

phyro ::

arjan_t je izjavil:


Ali pa mogoce pogledas kaksen jezik keterega type-system ni iz 80. let

this.

AndrejO ::

jype je izjavil:

AndrejO> hkrati pa ne spodbuja razmisleka o dejanskih procesih "pod havbo".
To očitno ni res, glede na to da je moral havbo odpret že pri praktično prvi nalogi.

O produktivnosti tega načina odpiranja havbe bi se verjetno dalo debatirati. Moje dosedanje izkušnje z učenjem so takšne, da ta način začetnike bolj mede, kot pa jim pomaga. Seveda pa je to single data point in jaz nisem niti pod razno pedagog.

jype je izjavil:

AndrejO> Vse so to orodja, ki hkrati pomagajo in škodijo.
Tudi statični tipi so orodje, ki hkrati pomaga in škodi.

Seveda. Nikoli nisem trdil česa drugega.

for (std::map<std::string, std::list<std::string>>::const_iterator it = l.begin(); it != l.end(); ++it) {
  ...;
}


To seveda lahko primerjam samo z srednjeveško natezalico, ki bi vsakega, ki ni 100% prepričan, da želi programirati, porinila naravnost v študij psihologije ali literarne zgodovine.

O polimorfizmu, ki ni strogo vezan na tipe (npr. t.i. duck-typing, kot ga zganja Python) se bi dalo tudi veliko povedati, vendar pa menim, da je v teh primerih Python 51% slab, pristop, kot ga uporablja Go pa možen korak v prihodnje izboljšave.

arjan_t je izjavil:


Ali pa mogoce pogledas kaksen jezik keterega type-system ni iz 80. let

Npr.?

Zgodovina sprememb…

  • spremenil: AndrejO ()

jype ::

AndrejO> pristop, kot ga uporablja Go pa možen korak v prihodnje izboljšave.

Joj, Go je v tem pogledu super korak naprej, se strinjam, ampak na nekaterih področjih žal tudi super korak nazaj :(

AndrejO> Npr.?

Upam, da je mislil go, ker sicer je mislil ===.

Zgodovina sprememb…

  • spremenilo: jype ()

AndrejO ::

jype je izjavil:

AndrejO> pristop, kot ga uporablja Go pa možen korak v prihodnje izboljšave.

Joj, Go je v tem pogledu super korak naprej, se strinjam, ampak na nekaterih področjih žal tudi super korak nazaj :(

Uf, ja. Samo in zgolj na to sem mislil. Tudi Go ni odgovor na vse težave tega sveta in nekatere stvari so mi pri njegovi uporabi čisti facepalm.

phyro ::

pomojem je mislil Haskell

arjan_t ::

haskell, rust, pac nekaj kar ima vsaj function local type inference

AndrejO ::

arjan_t je izjavil:

haskell, rust, pac nekaj kar ima vsaj function local type inference

Ah, OK. Zatipkam se pri C++11 (pomešam ga z C++0x) in nenadoma dobim čuden komentar. Torej da, C++11 to ima in po tem tvojem kriteriju očitno ima "moderen sistem".

Še dobro, da si ne bom začel prehitro misliti kakšen fosil sem. :p

arjan_t ::

ne nima, ne mores ti delat tega:
let mut v = Vec::new();
v.push(1i); //aha, hoces Vec<int>


kar ima C++ zdaj je kot go-jev :=, samo vzami type na desni in ga uporabi kot tip spremenljivke na levi

Zgodovina sprememb…

  • spremenil: arjan_t ()

AndrejO ::

arjan_t je izjavil:


kar ima C++ zdaj je kot go-jev :=, samo vzami type na desni in ga uporabi kot tip spremenljivke na levi

Mkay. Prečko si dvignil in sedaj sem fosil. :)

alexa-lol ::

AndrejO je izjavil:

jype je izjavil:

AndrejO> pristop, kot ga uporablja Go pa možen korak v prihodnje izboljšave.

Joj, Go je v tem pogledu super korak naprej, se strinjam, ampak na nekaterih področjih žal tudi super korak nazaj :(

Uf, ja. Samo in zgolj na to sem mislil. Tudi Go ni odgovor na vse težave tega sveta in nekatere stvari so mi pri njegovi uporabi čisti facepalm.


A lahko napišeta en code example ki kaže na očitno prednost in očitno slabost Go v primerjavi s Pythonom + razlaga zakaj je to dobro in zakaj slabo.

hvala lp

AndrejO ::

type VeryComplexContract interface {
  func F1()
  func F2()
  ...
}

func FunctionWithContract(c VeryComplexContract) {
  c.F1()
  c.F2()
  ...
}


Čez pol leta se vrneš in ugotoviš, da potrebuješ še F3(), zaradi česar moraš spremeniti VeryComplexContract. Prevajalnik je tisti, ki bo poskrbel za to, da bodo vsi uporabniki tvoje knjižnice pri naslednjem prevajanju prisiljeni implementirati F3(), kar je dobra stvar.

Kaj so facepalm stvari? Go je v svojem bistvu platforma optimizirana za implementiranje točno določene vrste aplikacij v točno določenem kontekstu. Iz tega sledijo nekateri facepalmi. Npr. statično prevajanje. Povezano s statičnim prevajanjem je tudi nezmožnost povezovanja med izvajanjem. Adijo vtičniki, če bi kdo želel modularno aplikacijo.

arjan_t ::

AndrejO je izjavil:


Čez pol leta se vrneš in ugotoviš, da potrebuješ še F3(), zaradi česar moraš spremeniti VeryComplexContract. Prevajalnik je tisti, ki bo poskrbel za to, da bodo vsi uporabniki tvoje knjižnice pri naslednjem prevajanju prisiljeni implementirati F3(), kar je dobra stvar.


To ni ravno specificno za go. Bolj bi izpostavil interface ki so haskell typeclass-like in interface "duck typing" (ne spomnim se kako recejo oni temu uradno) aka tip mora samo implementirati pravilne metode brez explicitnega navaajanja interfaca (to je lahko dobro in slabo, lahko nek dtug tip Foo po "pomoti" implemetira interface Bar ampak samo delovanje pa ni v skladu s tem interfacom)

AndrejO ::

arjan_t je izjavil:

To ni ravno specificno za go. Bolj bi izpostavil interface ki so haskell typeclass-like in interface "duck typing" (ne spomnim se kako recejo oni temu uradno) aka tip mora samo implementirati pravilne metode brez explicitnega navaajanja interfaca (to je lahko dobro in slabo, lahko nek dtug tip Foo po "pomoti" implemetira interface Bar ampak samo delovanje pa ni v skladu s tem interfacom)

Saj to je to. "Producer" ni tisti, ki bi izrecno implementiral ta ali oni vmesnik, temveč je "Consumer" tisti, ki oglašuje kakšen vmesnik potrebuje za svoje pravilno delovanje. Dokler bo prava metoda s pravim podpisom implementirana, bo vse OK. Če ne bo, bo opozorilo dal že prevajalnik.

Sam sem malo :/, ker mislim, da bi morali pisci Go-ja namesto "interface" uporabiti "contract". Čeprav tehnično pravilen izraz, je bil "interface" prevečkrat uporabljen v kontekstu jamstva na strani "implementorja", ne na strani "porabnika". Potem pa marsikdo ob površnem pogledu eno pomeša z drugim.

Zgodovina sprememb…

  • spremenil: AndrejO ()


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Kako masovno pingat?

Oddelek: Programiranje
448189 (6176) ragezor
»

Delodajalci kaj pričakujete od CV?

Oddelek: Loža
416607 (4148) Tear_DR0P
»

Kje/kako ste se naučili programiranja? (strani: 1 2 3 4 5 )

Oddelek: Programiranje
21655876 (40552) DaMachk
»

programiranje v zbirniku z ukazi ...

Oddelek: Programiranje
203910 (3170) lebdim
»

Mozilla po Eichovem odstopu (strani: 1 2 3 4 5 6 )

Oddelek: Novice / Ostale najave
29554617 (49439) jype

Več podobnih tem