Hva er poenget med dynamiske datatyper?

[GeirGrusom]

Java er verbost ja. C# synes jeg ikke er det. Eneste er ekslisitt deklerasjon av variabler (yay) og statiske datatyper (yay igjen)

 

Kan noen si meg en god grunn til å ha dynamiske datatyper? Hvorfor kalles dette en "feature" og ikke en "issue"?

[Terrasque]

Java er verbost ja. C# synes jeg ikke er det. Eneste er ekslisitt deklerasjon av variabler (yay) og statiske datatyper (yay igjen)

 

Kan noen si meg en god grunn til å ha dynamiske datatyper? Hvorfor kalles dette en "feature" og ikke en "issue"?

 

For meg har det veldig lite å si i praksis. Jeg pleier ikke å mikse datatyper i samme variabel (Vel, bortsett fra å sette None / False istedet for tom liste / dict / string / blargh innimellom. For meg er det bare en mindre ting å være fustrert over. (Hva het den datatypen i dette språket da?)

 

Hvis jeg vil være litt flamish, kan jeg snu det rundt og si "Er du virkelig så rotete at du må få datamaskinen til å holde styr på hva du skal ha hvor?"

[GeirGrusom]

Hvis jeg vil være litt flamish, kan jeg snu det rundt og si "Er du virkelig så rotete at du må få datamaskinen til å holde styr på hva du skal ha hvor?"

Du KAN bruke forskjellige datatyper med samme navn i C språk også, bare å utnytte scope det. Men det betyr ikke at du burde.

Fordelen er først og fremst at det er mye, mye enklere å skrive en effektiv implementasjon av et språk som har statiske datatyper. .NET CLR (dynamic language runtime) er typisk 10 ganger raskere enn .NET CLR (Common language runtime).

.NET CLR og JRE er typisk 10 ganger raskere enn CPython.

 

Ved siden av det, kan det hindre feil som dukker opp fordi en funksjon får feil verdier inn e.l. ettersom et statisk typet språk ikke vil la deg kompilere et program som prøver å dytte feil datatyper inn i en funksjon.

 

Så hva er egentlig fordelene?

[Terrasque]

Hvis jeg vil være litt flamish, kan jeg snu det rundt og si "Er du virkelig så rotete at du må få datamaskinen til å holde styr på hva du skal ha hvor?"

.NET CLR og JRE er typisk 10 ganger raskere enn CPython.

 

 

Så hva er egentlig fordelene?

 

Fordelene er at hvis du ikke trenger det, så trenger du det ikke. En mindre ting å tenke på.

 

Og når det gjelder hastighet, så er CPython en implentasjon av python.

 

Men, når det gjelder implentasjoner.. Har du sett på PyPy? Hvis ikke, så tror jeg du vil finne det interessant. Spesielt detaljene bak.

 

The PyPy project aims at producing a flexible and fast Python implementation. The guiding idea is to translate a Python-level description of the Python language itself to lower level languages. Rumors have it that the secret goal is being faster-than-C which is nonsense, isn’t it?

[GeirGrusom]

Hvis jeg vil være litt flamish, kan jeg snu det rundt og si "Er du virkelig så rotete at du må få datamaskinen til å holde styr på hva du skal ha hvor?"

.NET CLR og JRE er typisk 10 ganger raskere enn CPython.

 

 

Så hva er egentlig fordelene?

 

Fordelene er at hvis du ikke trenger det, så trenger du det ikke. En mindre ting å tenke på.

 

Og når det gjelder hastighet, så er CPython en implentasjon av python.

 

Men, når det gjelder implentasjoner.. Har du sett på PyPy? Hvis ikke, så tror jeg du vil finne det interessant. Spesielt detaljene bak.

 

The PyPy project aims at producing a flexible and fast Python implementation. The guiding idea is to translate a Python-level description of the Python language itself to lower level languages. Rumors have it that the secret goal is being faster-than-C which is nonsense, isn’t it?

Vet CPython er en implementasjon (referanseimplementasjonen faktisk). Derfor jeg skrev CPython. Men dynamiske datatyper gjør at programmet UANSETT må gjøre noe run-time typesjekking: medlemmer i klasser kan endres run-time. Dette kan ordnes nogenlunde med JIT-kompilator, men det er uansett mye mer jobb å få til en slik implementasjon. Derfor akkurat nå så er samtlige implementasjoner av språk med dynamiske datatyper vesentlig tregere enn de med statiske datatyper.

 

Men det er ikke eneste grunnen til å hevde at dynamiske datatyper er noe tull: dynamiske datatyper fører ofte med seg noe annet jeg synes er tullete: implisitt konvertering av datatyper.

 

Men blås i implementasjoner: hvorfor skal et språk ha det? Hva er nytten?

[x871kx6167ss7]

Men det er ikke eneste grunnen til å hevde at dynamiske datatyper er noe tull: dynamiske datatyper fører ofte med seg noe annet jeg synes er tullete: implisitt konvertering av datatyper.

Dynamisk typede språk som python/lisp/scheme er strekt typete. Eksempel på et svakt og statisk typed språk er C. Og noen andre statisk typede språk som har casting, har jo tendenser til svak typing. Men du tenker kanskje på PHP o.l (spesielt med tanke på at du nevner implisitt)? Poenget mitt er uansett: kan du utbrodere?

 

Men blås i implementasjoner: hvorfor skal et språk ha det? Hva er nytten?

Vel, du nevner det til dels selv. Du kan gjøre noen ting mer konsist i dynamisk typede språk, som et statisk typesystem ikke godtar*. Det betyr selvfølgelig ikke at man ikke kan få til det samme i et statisk typet språk, men du må gjerne gjennom noen sermonier for få gjort det samme. Og i språk som java så må man kanskje til og med benytte casting, og da er man vel like langt? Poenget er vel at det blir en avveining mellom uttrykkskraft og integritet.

 

* Typesystemene i Java/C regnes vel ikke som særlig gode blandt de som holder på med type-teori, uten at jeg har særlig å backe opp det med selv. Merker forsåvidt tendensene selv når jeg har prøvd å løse noen "dynamiske" problemere i henholdsvis Java og Maude.

[GeirGrusom]

Jeg har aldri kommet over "Oi! Nå hadde det vært kjekt med dynamiske datatyper". Ikke en eneste gang. Der hvor det hadde vært kjekt, tar generics og templates over på en mer elegant måte.

Men generics er ganske dustete i Java (type erasure), så vi ser bortifra det.

 

Casting er en bra ting. Det gjør at uttrykket er fullstendig klart. Selv om jeg synes castingen i C språk er litt tullete. Hvorfor ikke mer som i GLSL? Constructoren til alle datatyper burde vært casting for den datatypen.

 

var value = float(verdi)
istedet for
var value = (float)verdi;

 

Forøvrig: PyPy bruker RPython og er statisk typet.

 

The interpreter [PyPy] implements the full Python language in a restricted subset, called RPython (Restricted Python). Unlike standard Python, RPython is statically typed, to allow efficient compilation.

 

Unladen Swallow var for vanlig Python og siktet på 5x bedre ytelse, uten at det målet ble nådd.

[Terrasque]

Forøvrig: PyPy bruker RPython og er statisk typet.

 

The interpreter [PyPy] implements the full Python language in a restricted subset, called RPython (Restricted Python). Unlike standard Python, RPython is statically typed, to allow efficient compilation.

 

PyPy er skrevet i RPython, men den kjører vanlig python (2.5) kode, og som oftest mye raskere enn CPython.

 

What PyPy contains is, on the one hand, an non-soft static type inferencer for RPython, which is a sublanguage that we defined just so that it’s possible and not too hard to do that; and on the other hand, for the full Python language, we have an interpreter, and a JIT generator which can produce a Just-In-Time Compiler from the interpreter. The resulting JIT works for the full Python language in a way that doesn’t need type inference at all.

 

Vi har også http://speed.pypy.org/ som kjører benchmarks som sammenligner CPython og PyPy ytelse.

 

Edit : Poenget var, at man bør ikke nødvendigvis bruke CPython (implentasjonen) som referanse på hvor rask python kode kan kjøres, siden det er andre implentasjoner som er en del raskere.

Endret 13. april 2011 av Terrasque

[GeirGrusom]

Det finnes raskere ja, men ingen ser ut til å ligge så veldig nærme typiske språk med statiske datatyper.

 

Can PyPy compile normal Python programs?

Endret 13. april 2011 av GeirGrusom

[Terrasque]

http://morepypy.blogspot.com/2009/10/pypys-jit-now-supports-floats.html

 

Og jeg skjønner ikke hva poenget var med den linken din... PyPy er skrevet i RPython. PyPy kjører vanlig python kode. Akkurat som CPython gjør. CPython kan heller ikke compile vanlig python kode.

 

Edit : http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html (ye, ye, specially craftet. Fremdeles, moro)

Endret 13. april 2011 av Terrasque

[GeirGrusom]

http://morepypy.blogspot.com/2009/10/pypys-jit-now-supports-floats.html

 

Og jeg skjønner ikke hva poenget var med den linken din... PyPy er skrevet i RPython. PyPy kjører vanlig python kode. Akkurat som CPython gjør. CPython kan heller ikke compile vanlig python kode.

 

Edit : http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html (ye, ye, specially craftet. Fremdeles, moro)

Høh? Det står at PyPy ikke kompilerer Python kode... Men CPython kompilerer da Python kode (til Python Bytecode) og PyPy måtte kunnet kompilere Python til JIT som den bruker? Istedet står det at PyPy ikke kompilerer Python, men RPython.

[Terrasque]

Nei, nei nei nei. CPython er en Python Interpreter, ikke compiler. PyPy er også en Python Interpreter, en med JIT støtte. PyPy er skrevet i RPython (som blir compilet, via C hvis jeg husker riktig), akkurat som CPython er skrevet i C..

 

PyPy interpreter helt vanlig python kode, og er (forutsatt at du ikke bruker C extensions, support der er fremdeles alpha) en drop-in replacement av CPython 2.5

Endret 13. april 2011 av Terrasque

[GeirGrusom]

JIT-runtimes er kompilatorer av natur, det er hele poenget med dem.

 

Men kanskje de her mener kompilering til native code, uten at det er det kompilering nødvendigvis betyr. Mulig jeg tar feil her, men da begår isåfall Wikipedia samme feilen.

Endret 13. april 2011 av GeirGrusom

[MailMan13]

Edit : http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html (ye, ye, specially craftet. Fremdeles, moro)

Jau, godt eksempel på at JIT > statisk compile under riktige omstendigheter. Blir enda morsommere hvis du gjør det samme i et statisk typet, JIT compilet språk:

 

Svært uformellt på treg laptop (Python-koden er cut&paste fra linken din):

 

PyPy 1.4.1: 1260 ms

Java 1.6.20: 1117 ms

C# 4.0: 391 ms

 

Samme programmet med ett unntak: Måtte legge til en variabel og putte resultatet av add(), og skrive det ut til slutt i Java-versjonen, hvis ikke vil DCE-algoritmen i javac optimalisere bort hele loopen og rapporterte ingen tid brukt .

 

Forøvrig dårlig eksempel på noe som helst, små detaljer i DCE implementasjonene i ulike kompilatorer vil gjøre kanonforskjell på resultatet i en sånn test.

Endret 13. april 2011 av MailMan13

[Terrasque]

pypy kjører iallefall vanlig python kode, og ofte raskere enn CPython

 

 

 

terra@ubuntu:~/Programs/pypy-1.4.1-linux64$ cat test.py

class Person(object):
   def __init__(self,count):
       self.count = count;
       self.prev = None

       self.next = None
   def shout(self,shout,deadif):
       if (shout < deadif): return (shout + 1)
       self.prev.next = self.next
       self.next.prev = self.prev
       return 1

class Chain(object):
   def __init__(self,size):
       self.first = None
       last = None
       for i in range(size):
           current = Person(i)
           if self.first == None : self.first = current
           if last != None :
               last.next = current
               current.prev = last
           last = current
       self.first.prev = last
       last.next = self.first
   def kill(self,nth):
       current = self.first
       shout = 1
       while current.next != current:
           shout = current.shout(shout,nth)
           current = current.next
       self.first = current
       return current

import time
ITER = 100000
start = time.time()
for i in range(ITER):
   chain = Chain(40)
   chain.kill(3)
end = time.time()
print 'Time per iteration = %s microseconds ' % ((end - start) * 1000000 / ITER)

 

terra@ubuntu:~/Programs/pypy-1.4.1-linux64$ time python test.py

Time per iteration = 121.735169888 microseconds

 

real 0m12.194s

user 0m12.060s

sys 0m0.020s

 

terra@ubuntu:~/Programs/pypy-1.4.1-linux64$ time ./bin/pypy test.py

Time per iteration = 20.6659698486 microseconds

 

real 0m2.091s

user 0m2.010s

sys 0m0.030s

 

terra@ubuntu:~/Programs/pypy-1.4.1-linux64$

 

terra@ubuntu:~/Programs/pypy-1.4.1-linux64$ python --version

Python 2.6.6

terra@ubuntu:~/Programs/pypy-1.4.1-linux64$ ./bin/pypy --version

Python 2.5.2 (e503e483e9ac, Dec 21 2010, 12:02:48)

[PyPy 1.4.1]

 

 

 

[GeirGrusom]

Kan være fordi den driver med type inferring eller noe.

 

JIT har absolutt noe for seg.

[Terrasque]

JIT har absolutt noe for seg.

 

Absolutt, og PyPy er meget interessant på mange måter. Det er skrevet i en python dialekt som kan kompileres, og JIT'en er (eller, er iallefall målet) uavhengig av språket (faktisk er språk, optimalisering og backend uavhengig av hverandre).

 

 

 

http://codespeak.net/pypy/dist/pypy/doc/architecture.html#pypy-the-translation-framework

Our goal is to provide a possible solution to the problem of language implementers: having to write l * o * p interpreters for l dynamic languages and p platforms with o crucial design decisions. PyPy aims at having any one of these parameters changeable independently from each other:

 

* l: the language that we analyze can be evolved or entirely replaced;

* o: we can tweak and optimize the translation process to produce platform specific code based on different models and trade-offs;

* p: we can write new translator back-ends to target different physical and virtual platforms.

 

By contrast, a standardized target environment - say .NET - enforces p=1 as far as it’s concerned. This helps making o a bit smaller by providing a higher-level base to build upon. Still, we believe that enforcing the use of one common environment is not necessary. PyPy’s goal is to give weight to this claim - at least as far as language implementation is concerned - showing an approach to the l * o * p problem that does not rely on standardization.

 

The most ambitious part of this goal is to generate Just-In-Time Compilers in a language-independent way, instead of only translating the source interpreter into an interpreter for the target platform. This is an area of language implementation that is commonly considered very challenging because of the involved complexity.

 

 

http://codespeak.net/pypy/dist/pypy/doc/faq.html#can-pypy-support-interpreters-for-other-languages-beyond-python

The toolsuite that translates the PyPy interpreter is quite general and can be used to create optimized versions of interpreters for any language, not just Python. Of course, these interpreters can make use of the same features that PyPy brings to Python: translation to various languages, stackless features, garbage collection, implementation of various things like arbitrarily long integers, etc.

 

Currently, we have preliminary versions of a JavaScript interpreter (Leonardo Santagada as his Summer of PyPy project), a Prolog interpreter (Carl Friedrich Bolz as his Bachelor thesis), and a SmallTalk interpreter (produced during a sprint). All of them are unfinished at the moment.

 

 

[progn]

Casting er en bra ting. Det gjør at uttrykket er fullstendig klart.

Hvorfor må ting være fullstendig klart helt ned på laveste nivå? En del av poenget med programmering er å kunne tenke i forskjellige abstraksjonsnivå. F.eks: jeg bryr meg egentlig ikke om number er et flyttall eller en BigInt så lenge resultatet eller korrektheten av programmet avhenger av det.

 

Dess mer unødvendig syntaks man legger til, dess tyngre blir det å lese koden.

 

Selv om jeg synes castingen i C språk er litt tullete. Hvorfor ikke mer som i GLSL? Constructoren til alle datatyper burde vært casting for den datatypen.

 

var value = float(verdi)
istedet for
var value = (float)verdi;

C++, som jeg mener er mer et "C språk" [sic] enn C#, støtter denne syntaksen for typecasting.

 

float value = verdi;

gir forøvrig samme mengde syntaktisk informasjon om typen.

[x871kx6167ss7]

Casting er en bra ting. Det gjør at uttrykket er fullstendig klart. Selv om jeg synes castingen i C språk er litt tullete. Hvorfor ikke mer som i GLSL? Constructoren til alle datatyper burde vært casting for den datatypen.

 

Tenker ikke på "casting" fra f.eks. int til float (det er vel strengt tatt en konvertering + cast), men på casting til en subklasse. Dersom et språk har casting til en subklasse, så betyr det i praksis at de innrømmer at typesystemet ikke har nok uttrykkskraft for de problemene de ønsker å løse.

[GeirGrusom]

Casting er en bra ting. Det gjør at uttrykket er fullstendig klart.

Hvorfor må ting være fullstendig klart helt ned på laveste nivå? En del av poenget med programmering er å kunne tenke i forskjellige abstraksjonsnivå. F.eks: jeg bryr meg egentlig ikke om number er et flyttall eller en BigInt så lenge resultatet eller korrektheten av programmet avhenger av det.

 

Dess mer unødvendig syntaks man legger til, dess tyngre blir det å lese koden.

En implementasjon av et dynamisk språk kan UMULIG vite hva slags datatype som egner seg, og må typisk gjøre type-sjekking run-time. Ulempen kan du regne ut, for det går sterkt utover ytelsen å gjøre type-sjekking run-time. Se .NET DLR vs .NET CLR for eksempel. Min test med Vector double vs. dynamisk vector ga en 10x bedre ytelse på CLR.

 

Selv om jeg synes castingen i C språk er litt tullete. Hvorfor ikke mer som i GLSL? Constructoren til alle datatyper burde vært casting for den datatypen.

 

var value = float(verdi)
istedet for
var value = (float)verdi;

C++, som jeg mener er mer et "C språk" [sic] enn C#, støtter denne syntaksen for typecasting.

 

float value = verdi;

gir forøvrig samme mengde syntaktisk informasjon om typen.

 

float value = verdi gir samme syntaktisk informasjon ja, men det var heller ikke poenget.