Python vs. Java

[zotbar1234]

Mod. anm.

Denne tråden er splittet ut fra https://www.diskusjon.no/index.php?showtopic=1045678

 

Når det gjelder kompilering, kan alle språk kompileres, men noen språk er designet som scriptspråk i utgangspunktet (som Python eller PHP) som kan gjøre kompilering til en temmelig klønete prosess fremfor språk som har det målet i utgangspunktet.

 

Temmelig klønete? <sarkasme>Det må nok være derfor den mest utbredte Pythonimplementasjonen (CPython) kompilerer Pythonkoden som standard.</sarkasme>

Endret 20. desember 2008 av cyclo

[GeirGrusom]

Når det gjelder kompilering, kan alle språk kompileres, men noen språk er designet som scriptspråk i utgangspunktet (som Python eller PHP) som kan gjøre kompilering til en temmelig klønete prosess fremfor språk som har det målet i utgangspunktet.

 

Temmelig klønete? <sarkasme>Det må nok være derfor den mest utbredte Pythonimplementasjonen (CPython) kompilerer Pythonkoden som standard.</sarkasme>

CPython kompilerer da vitterlig til Python Bytecode? og i motsetning til java sin JIT modell, vil aldri programmet ligge i minne som maskinkode? eller tar jeg feil nå?

Java->Java bytecode->JIT->Maskinkode

Pyton->Python Bytecode

 

edit: ærlig talt har jeg ikke store problemer med python i seg selv, det er sikkert mange problemer sm kan løses veldig elegant der, det er bare idéen om at python er noe mer enn et scriptspråk som får meg til å reagere.

Endret 15. desember 2008 av GeirGrusom

[zotbar1234]

CPython kompilerer da vitterlig til Python Bytecode?

 

Du påstod at kompilering av Python var klønete. Jeg poengterte at det ikke var tilfellet med ett eksempel. Det finnes flere. *Hva* CPython-implementasjonen kompilerer Pythonkoden til sa du ingenting om. Du poengterte kun at kompilering av Python var 'klønete'. (Når jeg tenker meg om, kanskje jeg burde ha spurt hva du legger i "klønete")

 

(...) og i motsetning til java sin JIT modell, vil aldri programmet ligge i minne som maskinkode? eller tar jeg feil nå?

 

Ja, du tar feil nå, siden det også finnes just-in-time kompilatorer til Python.

 

edit: ærlig talt har jeg ikke store problemer med python i seg selv, det er sikkert mange problemer sm kan løses veldig elegant der, det er bare idéen om at python er noe mer enn et scriptspråk som får meg til å reagere.

 

Det er fint at du forteller om dine fordommer.

 

Når det gjelder scriptspråk -- en BSP til MIDAS5000-modul kommer (i noen inkarnasjoner) med en interpreter til C, hvor man kan taste inn C-koden direkte i et miljø som minner veldig om en nedstrippet CPython top-level. Det finnes garantert flere. En implementasjon av C (eller Python) kan gjerne være en interpreter som leser og tolker kildekoden direkte, eller en kompilator som først oversetter kildekoden til et annet mer egnet format. Det er *ingenting* i Python som hindrer den prosessen. På samme måte som i eksempelvis C. Den eneste forskjellen er at C er et *mye* enklere språk enn Python.

[GeirGrusom]

IronPython og Jython er eksempelvis JIT-python implementasjoner.

 

Hvis du har problemer med å se hva som er problemet med å kompilere scriptspråk kan du jo lage en native code compiler for et scriptspråk. Et problem kan være datatyper, fordi det finnes ingen effektiv måte å vite datatypen på en variabel (er det flyttall, heltall eller en peker?) Datatypen kan endres uten at det kan optimaliseres for prosessoren.

 

Språket er ikke laget for å programmere prosessoren, men for å programmere et annet program. Du vil sitte igjen med en hel masse overhead som er helt unødvendig for et språk som er beregnet for å programmere nettopp prosessoren.

 

CPython er heller ikke bare den vanligste implementasjonen av Python, det er de facto standarden og referanseimplementasjonen.

edit: og CPython bruker ikke JIT, den bruker interperated Python Bytecode.

http://en.wikipedia.org/wiki/Python_(progr...nguage)#CPython

 

Når det gjelder scriptspråk -- en BSP til MIDAS5000-modul kommer (i noen inkarnasjoner) med en interpreter til C, hvor man kan taste inn C-koden direkte i et miljø som minner veldig om en nedstrippet CPython top-level. Det finnes garantert flere. En implementasjon av C (eller Python) kan gjerne være en interpreter som leser og tolker kildekoden direkte, eller en kompilator som først oversetter kildekoden til et annet mer egnet format. Det er *ingenting* i Python som hindrer den prosessen. På samme måte som i eksempelvis C. Den eneste forskjellen er at C er et *mye* enklere språk enn Python.

C er et betydelig enklere språk, sant, men det er også først og fremst et systemprogrammeringsspråk, og ikke et scriptspråk. Det at du klarer å lage en interperator for C betyr ingenting.

 

Du kan jo se fort en ting som gjør C svært bedre egnet til native code en Python, evnen til å definere en struktur og la den gjelde på en bestemt minneadresse. Veldig hendig hvis du skriver operativsystem eller drivere.

 

Hvor hendig er dette i et scriptspråk? ikke veldig, siden disse adressene ikke kan brukes utenfor interperatorens avgrensede minneadresser.

Endret 15. desember 2008 av GeirGrusom

[zotbar1234]

Hvis du har problemer med å se hva som er problemet med å kompilere scriptspråk kan du jo lage en native code compiler for et scriptspråk.

 

Det må da finnes en *enklere* måte å forklare på hvorfor å lage native code kompilator er "klønete"?

 

Et problem kan være datatyper, fordi det finnes ingen effektiv måte å vite datatypen på en variabel (er det flyttall, heltall eller en peker?) Datatypen kan endres uten at det kan optimaliseres for prosessoren.

 

Eh, dette er ikke et problem. Ikke verre enn at man ikke alltid kan vite på et gitt punkt i C-koden hva en void* peker på. Hvis du mener at det er lettere å generere *effektiv* native kode for C enn f.eks. for Python, siden C har deklarasjoner, som stadfester typen til variablene, ja, det er tilfellet. Men det er ikke dermed mer "klønete" å lage en native kompilator for Python enn det er for C.

 

edit: og CPython bruker ikke JIT, den bruker interperated Python Bytecode.

 

CPython bruker en kompilator. Så veldig klønete kan det umulig være. At det ikke er en kompilator til native kode er helt uvesentlig.

 

C er et betydelig enklere språk, sant, men det er også først og fremst et systemprogrammeringsspråk, og ikke et scriptspråk. Det at du klarer å lage en interperator for C betyr ingenting.

 

Poenget mitt var å illustrere hvor diffust begrepet "skriptspråk" egentlig var.

Endret 15. desember 2008 av zotbar1234

[GeirGrusom]

Ok, her er min definisjon på et scriptspråk:

Et programmeringsspråk designet for å utfylle instruksjonssettet til et annet program.

systemprogrammeringsspråk:

Et programmeringsspråk utviklet for å utfylle instruksjonssettet til maskinvaren.

 

Men når det gjelder void* i C... hva er vanlig å gjøre da? du caster, en void* kan ikke brukes til noenting før du forteller compileren gjennom koden hva som ligger bak. En void* er ikke det samme som object (Java og C#) eller variant i VB, fordi void* forteller absolutt null om innholdet, og kan overhode ikke brukes til noen ting før du forteller selve compileren hva den skal gjøre med dataene som void* peker til.

I Python så er det selve innholdet som forteller interperatoren hva som skal gjøres, og ikke selve koden som den i C. Dette fører til at det blir en vesentlig overhead for alle verdier da alt må lagres som pekere og objekter og ingenting kan vurderes som en primitiv verdi compileren. Dette kan være svært hendig i scriptspråk, og det er faktisk vanskelig å gjøre det på nooen annen måte, men for et systemprogrammeringsspråk, skaper det en betydelig og helt fullstendig unødvendig overhead for koden.

 

Kompilatoren til CPython lager et intermediate språk (bytecode) fordi det er enklere og mer effektivt å interperate enn det python kode er, men resultatet ligger fortsatt nærmere python enn det ligger maskinkode.

 

I maskinkode er det helt nødvendig at du vet datatypen du skal jobbe med, skal du bruke DIV, IDIV eller FDIV instruksjonen? og hvilken bitoppløsning? 8, 16, 32, 64 eller 80-bit? er det en peker, eller en verdi? an verdien bare ligge på FPU-stacken til neste instruksjon, eller må FPU stacken poppes? returnerer funksjonen en verdi, eller må EAX resettes?

Mange slike problemer kan du møte, og enkleste løsningen vil bli å unngå optimaliseringer du kunne brukt hvis det var et systemprogrammeringsspråk du brukte.

 

Jeg tror du forstår hva jeg mener, og jeg hadde satt pris på om vi ikke henger oss opp i definisjonsspørsmål. Jeg er klar over at kompilering nødvendigvis bare betyr at en gjør om et språk til et annet, men jeg tenker først og fremst på ytelse her, og da er maskinkode den beste løsningen.

 

Og igjen, jeg har ikke så mye imot python i seg selv, men jeg tror du ser hvor jeg vil hen. Språk har forskjellige nytter, og python er først og fremst et scriptspråk som passer definisjonen jeg skrev over. Det har sine nytteområder, men min mening er at å bruke Python til å skrive store omfattende ressurskrevende programmer kan være uheldig for sluttbrukeren.

 

Hvor bra klarer CPython seg i ressurskrevende operasjoner, for eksempel procedural textures? Jeg tipper at både Java og C vil utklasse en CPython implementasjon.

[zotbar1234]

Ok, her er min definisjon på et scriptspråk:

Et programmeringsspråk designet for å utfylle instruksjonssettet til et annet program.

systemprogrammeringsspråk:

Et programmeringsspråk utviklet for å utfylle instruksjonssettet til maskinvaren.

 

Hva betyr "utfylle instruksjonssettet"? Ikke minst hva er "instruksjonssettet til et annet program"?

 

I Python så er det selve innholdet som forteller interperatoren hva som skal gjøres, og ikke selve koden som den i C.

 

Selv etter å ha lest denne setningen flere ganger, er jeg usikker på hva du mener.

 

Dette fører til at det blir en vesentlig overhead for alle verdier da alt må lagres som pekere og objekter og ingenting kan vurderes som en primitiv verdi compileren.

 

For det første er ikke dette sant i alle situasjoner (ingenting hindrer en implementasjon til å analysere en kodeblokk og fastslå at her vil det garantert holde med å bruke typer som støttes av maskinvaren direkte). For det andre -- hva *så* om den genererte koden er mindre effektiv? Det gjør ikke et språk mer klønete når det gjelder kompilatorskriving. Språk der typen er knyttet til verdien (heller enn variabelen) har vært med oss siden 60-tallet og det å skrive kompilatorer for dem er bare så ikke nytt/klønete. At det er mindre effektivt å generere kode der typen til alle variablene/verdiene kan avgjøres vha. statisk analyse er fullstendig ved siden av saken.

 

Dette kan være svært hendig i scriptspråk, og det er faktisk vanskelig å gjøre det på nooen annen måte, men for et systemprogrammeringsspråk, skaper det en betydelig og helt fullstendig unødvendig overhead for koden.

 

Pffft... Unødvendig? Prøv å skrive en heterogen container i C. Gråt krokodilletårer mens du gjør det. Gråt enda mer mens du bruker den.

 

Kompilatoren til CPython lager et intermediate språk (bytecode) fordi det er enklere og mer effektivt å interperate enn det python kode er, men resultatet ligger fortsatt nærmere python enn det ligger maskinkode.

 

Det er fremdeles en kompilator. Hva var klønete med det igjen?

 

I maskinkode er det helt nødvendig at du vet datatypen du skal jobbe med, skal du bruke DIV, IDIV eller FDIV instruksjonen? og hvilken bitoppløsning? 8, 16, 32, 64 eller 80-bit? er det en peker, eller en verdi? an verdien bare ligge på FPU-stacken til neste instruksjon, eller må FPU stacken poppes? returnerer funksjonen en verdi, eller må EAX resettes?

Mange slike problemer kan du møte, og enkleste løsningen vil bli å unngå optimaliseringer du kunne brukt hvis det var et systemprogrammeringsspråk du brukte.

 

Ja, ok, du vil ha deklarasjoner med typen til å følge variablene. Det gjør ikke språket mer klønete å skrive kompilator til. Det gjør det vanskeligere å generere effektiv maskinkode, dog. Er dette din definisjon av "klønete"?

 

Jeg tror du forstår hva jeg mener, og jeg hadde satt pris på om vi ikke henger oss opp i definisjonsspørsmål. Jeg er klar over at kompilering nødvendigvis bare betyr at en gjør om et språk til et annet, men jeg tenker først og fremst på ytelse her, og da er maskinkode den beste løsningen.

 

Så "kompilering" er ekvivalent med oversettelse til maskinkode og kun det?

 

Og igjen, jeg har ikke så mye imot python i seg selv, men jeg tror du ser hvor jeg vil hen. Språk har forskjellige nytter, og python er først og fremst et scriptspråk som passer definisjonen jeg skrev over. Det har sine nytteområder, men min mening er at å bruke Python til å skrive store omfattende ressurskrevende programmer kan være uheldig for sluttbrukeren.

 

Har du noe som helst argumentasjon for hvorfor og hvordan dette vil være uheldig for sluttbrukeren? ("Ytelse" er ikke et argument her).

 

Hvor bra klarer CPython seg i ressurskrevende operasjoner, for eksempel procedural textures? Jeg tipper at både Java og C vil utklasse en CPython implementasjon.

 

La oss begynne med at Java og C ikke vil utklasse noe som helst.

 

En Java- eller C-*implementasjon* vil kunne være raskere til en bestemt oppgave enn CPython. Og det er *helt* uvesentlig for sluttbrukeren. Absolutt uten betydning (fordi at dersom profileringen først viser at beregningen av en procedural texture *er* flaskehalsen, så vil akkurat den operasjonen kunne flyttes til en mellomrepresentasjon (pyrex/cyphon, f.eks.) eller helt og holdent til C, Fortran eller assembly, slik man gjør det omtrent med alle språk som har et litt mer avansert runtime system enn runtimesystemet til C/Fortran/assembly og koden er tidskritisk)

 

Hvordan var dette med klønete og kompilatorer til Python igjen?

[GeirGrusom]

Har du aldri selv skrevet en kompilator eller interperator? for det virker ikke sånn.

 

Du er vrang og du bruker en argumentasjonsteknikk som jeg har lite til overs for. Det kan godt hende du er kunnskapsrik, men du viser det veldig dårlig i denne tråden.

 

Jeg har ikke mer å si dersom du ikke forstår hva jeg mener med instruksjonsett.

[zotbar1234]

Har du aldri selv skrevet en kompilator eller interperator? for det virker ikke sånn.

 

Uansett om jeg har eller ikke har skrevet en kompilator før (must... resist... fist of death), har du problemer med å forklare definisjonene som du selv opererer med? Du brukte et nokså diffust begrep opprinnelig ("klønete"), men uansett hvor mye godvilje jeg legger i tolkningen av den bruken, får jeg ikke det til å stemme med det jeg vet om kompilatorer og Python. Men hey, det virker jo ikke som om jeg skrev en kompilator/interpreter før, og *da* er jo saken klar.

 

Du er vrang og du bruker en argumentasjonsteknikk som jeg har lite til overs for. Det kan godt hende du er kunnskapsrik, men du viser det veldig dårlig i denne tråden.

 

Jeg har ikke mer å si dersom du ikke forstår hva jeg mener med instruksjonsett.

 

Ah, "forstår du ikke hva JEG mener med MIN definisjon, gidder jeg ikke å snakke med deg". Hvem sin argumentasjonsteknikk er problematisk her?

 

Og jeg er fremdeles veldig spent på hva du mener med "instruksjonssettet til et annet program".

Endret 16. desember 2008 av zotbar1234

[Dead_Rabbit]

Slutt å oppføre deg som en liten drittunge zotbar1234. Det er gjennomgående i innleggende dine at du har en arrogant og breial attitude, og du prøver å dra i land diskusjonene ved å bruke dårlig sarkasme og *stjerner*. Skjerpings.

[GeirGrusom]

Ah, "forstår du ikke hva JEG mener med MIN definisjon, gidder jeg ikke å snakke med deg". Hvem sin argumentasjonsteknikk er problematisk her?

 

Og jeg er fremdeles veldig spent på hva du mener med "instruksjonssettet til et annet program".

 

En interperator kan bruke et slags instrukssjonsett som et oppslagsverk for hva den skal gjøre når den når en spesifikk byte code verdi. Når språket bruker ren linje-for-linje oversettning (som PHP eksempelvis vanligvis gjør) så blir det mer at den deler opp koden i mindre deler og utfører de i riktig rekkefølge. Pluss og minus kan da sees på som en del av "instruksjonssettet" til dette programmet. I byte code så slåes det opp i en tabell for å avgjøre hva instruksjonen gjør, denne tabellen kan sees på som instruksjonsettet til dette programmet.

 

Burde det virkelig vært nødvendig at jeg forklarte deg dette? Absolutt ikke, og derfor gidder jeg ikke å diskutere med noen som argumenterer utifra manglende forståelse.

[zotbar1234]

Slutt å oppføre deg som en liten drittunge zotbar1234. Det er gjennomgående i innleggende dine at du har en arrogant og breial attitude, og du prøver å dra i land diskusjonene ved å bruke dårlig sarkasme og *stjerner*. Skjerpings.

 

Skjerpings? Det sier *du*, hvis *eneste* bidrag i denne tråden har vært dette utsagnet? Begynn med å innstramme din egen oppførsel, før du foreslår det samme for andre.

[zotbar1234]

Ah, "forstår du ikke hva JEG mener med MIN definisjon, gidder jeg ikke å snakke med deg". Hvem sin argumentasjonsteknikk er problematisk her?

 

Og jeg er fremdeles veldig spent på hva du mener med "instruksjonssettet til et annet program".

 

En interperator kan bruke et slags instrukssjonsett som et oppslagsverk for hva den skal gjøre når den når en spesifikk byte code verdi. Når språket bruker ren linje-for-linje oversettning (som PHP eksempelvis vanligvis gjør) så blir det mer at den deler opp koden i mindre deler og utfører de i riktig rekkefølge. Pluss og minus kan da sees på som en del av "instruksjonssettet" til dette programmet. I byte code så slåes det opp i en tabell for å avgjøre hva instruksjonen gjør, denne tabellen kan sees på som instruksjonsettet til dette programmet.

 

Så, instruksjonssettet til et program er alle lovlige bytekodeverdier (med tilhørende operander) som programmet kan kompileres til? Hva om det ikke er definert noen bytekodeverdier, eller det er definert flere forskjellige bytekodeformater som ikke er kompatible? Hva med språk som hverken har noen de facto bytekodeformater eller var designet med en bestemt hardwarearkitektur i tankene? Hva er instruksjonssettet til programmer skrevet i de språkene?

 

La meg prøve å oppsummere det som er kommet i diskusjonen hittil:

 

* Du skiller ikke mellom et *språk* og dets *implementasjon* (hvis ikke, hadde du ikke kommet med komplett absurde påstander om at et språk er mer effektivt enn et annet), og så poengterer du at jeg mangler kunnskap om kompilatorer. Burde ikke du, før du setter en merkelapp på andres kunnskapsnivå, sørge for at du selv mestrer begrepene i diskusjonen?

 

* Du påstår at kompilering av Python er en "klønete prosess", uten at du redegjør for hva du mener med "klønete prosess". Du poengterer riktignok hvilke utfordringer en Pythonkompilator vil stå overfor, men du forteller ikke hvordan runtimesystemet til Python gjør nettopp kompileringen klønete. Kompilering av Pythonkode vha. f.eks. psyco er triviell. Kompilering av Pythonkode vha. CPython er enda mer triviell.

 

* Du påstår videre at kompilering av skriptspråk er problematisk, siden bl.a. datatypene følger objektene heller enn variablene som peker på/refererer til objektene. Språk med slike datamodeller har eksistert siden 60-tallet, og det er blitt laget flere kompilatorer til nettopp slike språk. Jeg ser ikke helt hvordan det er spesielt klønete eller problematisk. Visse språkelementer krever mer av kompilatoren (f.eks. dynamisk typing), eller runtime-systemet (garbage collection, flere separate eksekveringsstacker (som overhodet ikke samsvarer med dagens maskinvare)). Men det gjør ikke selve kompilering av koden skrevet i et gitt språk til "klønete", noe du påstod det gjorde. Og iallfall ikke i konteksten til OP.

 

* Du introduserer så din egen terminologi (jeg kunne ikke finne "instruksjonssett til et program" i noen av kompilatorbøkene jeg har i hyllen, og hvis jeg overså denne definisjonen, beklager jeg denne misforståelsen. Virkelig), og kaller meg vrang, når jeg stiller spørsmål ved denne terminologien. Og deretter har du lite til overs for *min* argumentasjonsteknikk? Fordi jeg ikke forstår *dine* egne begreper?

 

* Deretter kommer du med atter en ubegrunnet påstand -- "å bruke Python til å skrive store omfattende ressurskrevende programmer kan være uheldig for sluttbrukeren", uten at det oppnår noe annet enn å spre usannheter og da spesielt ift en person som ikke vet hvilket språk vedkommende skal velge. Så, har du en begrunnelse for denne påstanden? Hvis du ikke har det, hvem sin argumentasjonsteknikk er det du skal ha lite til overs for?

 

Jeg har en stygg mistanke (rett meg hvis jeg tar feil, fordi jeg gjetter nå) at din aversjon mot Python skyldes at man ikke har en Python->vilkårlig maskinkode kompilator tilgjengelig (slik det gjerne er med f.eks. C), og det på en eller annen måte gjør Python mindre egnet til fysiske beregninger og visualisering. Det er ikke tilfellet. Det at et gitt system (maskinvare + OS) ikke har en Python->maskinkode kompilator gjør heller ikke Python uegnet til å skrive store omfattende ressurskrevende programmer. Man har en del eksempler på nettopp slike systemer.

 

Burde det virkelig vært nødvendig at jeg forklarte deg dette? Absolutt ikke, og derfor gidder jeg ikke å diskutere med noen som argumenterer utifra manglende forståelse.

 

Manglende forståelse av DINE definisjoner, ja. Jeg har ikke utviklet telepatiske evner (enda?), så du får ha meg unnskyldt hvis jeg ikke vet hva DINE definisjoner betyr, enda jeg har slått opp i "Compilers" til Aho et al og ikke funnet DINE definisjoner der.

 

Tilbake til den opprinnelige saken -- du har fremdeles ikke forklart hva gjør kompilering av Python "klønete". Jeg venter fremdeles.

[GeirGrusom]

* Du skiller ikke mellom et *språk* og dets *implementasjon* (hvis ikke, hadde du ikke kommet med komplett absurde påstander om at et språk er mer effektivt enn et annet), og så poengterer du at jeg mangler kunnskap om kompilatorer. Burde ikke du, før du setter en merkelapp på andres kunnskapsnivå, sørge for at du selv mestrer begrepene i diskusjonen?

Dette skiller jeg mellom flere ganger, har du engang lest hva jeg har skrevet?

 

* Du påstår at kompilering av Python er en "klønete prosess", uten at du redegjør for hva du mener med "klønete prosess". Du poengterer riktignok hvilke utfordringer en Pythonkompilator vil stå overfor, men du forteller ikke hvordan runtimesystemet til Python gjør nettopp kompileringen klønete. Kompilering av Pythonkode vha. f.eks. psyco er triviell. Kompilering av Pythonkode vha. CPython er enda mer triviell.

Dette relaterer til når jeg sa at noen språk er mer egnet til kompilering til native code en andre, les hva jeg skriver.

 

* Du påstår videre at kompilering av skriptspråk er problematisk, siden bl.a. datatypene følger objektene heller enn variablene som peker på/refererer til objektene. Språk med slike datamodeller har eksistert siden 60-tallet, og det er blitt laget flere kompilatorer til nettopp slike språk. Jeg ser ikke helt hvordan det er spesielt klønete eller problematisk. Visse språkelementer krever mer av kompilatoren (f.eks. dynamisk typing), eller runtime-systemet (garbage collection, flere separate eksekveringsstacker (som overhodet ikke samsvarer med dagens maskinvare)). Men det gjør ikke selve kompilering av koden skrevet i et gitt språk til "klønete", noe du påstod det gjorde. Og iallfall ikke i konteksten til OP.

Optimalisering er vanskelig dersom språket ikke har eksplisitte datatyper. OP har ingenting med dette å gjøre.

 

* Du introduserer så din egen terminologi (jeg kunne ikke finne "instruksjonssett til et program" i noen av kompilatorbøkene jeg har i hyllen, og hvis jeg overså denne definisjonen, beklager jeg denne misforståelsen. Virkelig), og kaller meg vrang, når jeg stiller spørsmål ved denne terminologien. Og deretter har du lite til overs for *min* argumentasjonsteknikk? Fordi jeg ikke forstår *dine* egne begreper?

Jeg forklarte hva jeg mente flere ganger, derfor er du vrang.

 

* Deretter kommer du med atter en ubegrunnet påstand -- "å bruke Python til å skrive store omfattende ressurskrevende programmer kan være uheldig for sluttbrukeren", uten at det oppnår noe annet enn å spre usannheter og da spesielt ift en person som ikke vet hvilket språk vedkommende skal velge. Så, har du en begrunnelse for denne påstanden? Hvis du ikke har det, hvem sin argumentasjonsteknikk er det du skal ha lite til overs for?

Jeg skrev hvorfor jeg mente dette, du argumenterte med at jeg tok feil fordi du ikke forstod hva jeg mente.

 

Jeg har en stygg mistanke (rett meg hvis jeg tar feil, fordi jeg gjetter nå) at din aversjon mot Python skyldes at man ikke har en Python->vilkårlig maskinkode kompilator tilgjengelig (slik det gjerne er med f.eks. C), og det på en eller annen måte gjør Python mindre egnet til fysiske beregninger og visualisering. Det er ikke tilfellet. Det at et gitt system (maskinvare + OS) ikke har en Python->maskinkode kompilator gjør heller ikke Python uegnet til å skrive store omfattende ressurskrevende programmer. Man har en del eksempler på nettopp slike systemer.

Yay. /care

 

Burde det virkelig vært nødvendig at jeg forklarte deg dette? Absolutt ikke, og derfor gidder jeg ikke å diskutere med noen som argumenterer utifra manglende forståelse.

 

Manglende forståelse av DINE definisjoner, ja. Jeg har ikke utviklet telepatiske evner (enda?), så du får ha meg unnskyldt hvis jeg ikke vet hva DINE definisjoner betyr, enda jeg har slått opp i "Compilers" til Aho et al og ikke funnet DINE definisjoner der.

Så få hodet ditt opp av bøkene og les det jeg skriver.

 

Tilbake til den opprinnelige saken -- du har fremdeles ikke forklart hva gjør kompilering av Python "klønete". Jeg venter fremdeles.

Jeg har annet å gjøre en å krangle med en gjøk som ikke engang gidder å lese igjennom alt jeg skriver, og henger seg opp fordi han ikke forstår hva jeg mener. Det er ikke sånn at det er ulovlig å bruke ord du ikke har lest i en bok, hvis du ikke forstår hva jeg mener, så har du et problem. Jeg har forklart hva jeg mener så tydelig jeg kan.

[zotbar1234]

* Du skiller ikke mellom et *språk* og dets *implementasjon*

Dette skiller jeg mellom flere ganger, har du engang lest hva jeg har skrevet?

 

Du har skrevet:

 

"Men hovedgrunnen til at jeg vil heller anbefale Java, er at språket er mer effektivt"

 

Mao. du skiller ikke mellom et språk og dets implementasjon.

 

* Du påstår at kompilering av Python er en "klønete prosess", uten at du redegjør for hva du mener med "klønete prosess" (...)

 

Dette relaterer til når jeg sa at noen språk er mer egnet til kompilering til native code en andre, les hva jeg skriver.

 

At et språk er mindre egnet til kompilering til maskinkode gjør ikke kompilering av programmer skrevet i det språket til klønete, hvilket var den opprinnelige påstanden. Videre påstod du på aldri i det opprinnelige innlegget at det var snakk om kompilering til maskinkode; du brukte begrepet "kompilering". Eller betyr kompilering nå plutselig utelukkende oversettelse til maskinkode?

 

* Du påstår videre at kompilering av skriptspråk er problematisk, siden bl.a. datatypene følger objektene heller enn variablene som peker på/refererer til objektene (...)

 

Optimalisering er vanskelig dersom språket ikke har eksplisitte datatyper. OP har ingenting med dette å gjøre.

 

Ja, optimalisering blir vanskelig. Det gjør ikke kompilering av skriptspråk problematisk på noen måter. Som jeg gav gjentatte eksempler på er kompilering av Python trivielt.

 

* Du introduserer så din egen terminologi (jeg kunne ikke finne "instruksjonssett til et program" i noen av kompilatorbøkene jeg har i hyllen, og hvis jeg overså denne definisjonen, beklager jeg denne misforståelsen. Virkelig), og kaller meg vrang, når jeg stiller spørsmål ved denne terminologien. Og deretter har du lite til overs for *min* argumentasjonsteknikk? Fordi jeg ikke forstår *dine* egne begreper?

Jeg forklarte hva jeg mente flere ganger, derfor er du vrang.

 

Nei, du gjorde ikke det. Du har fremdeles ikke laget en klar definisjon på "instruksjonssettet til et program", enda du bruker dette begrepet.

 

* Deretter kommer du med atter en ubegrunnet påstand -- "å bruke Python til å skrive store omfattende ressurskrevende programmer kan være uheldig for sluttbrukeren", uten at det oppnår noe annet enn å spre usannheter og da spesielt ift en person som ikke vet hvilket språk vedkommende skal velge. Så, har du en begrunnelse for denne påstanden? Hvis du ikke har det, hvem sin argumentasjonsteknikk er det du skal ha lite til overs for?

Jeg skrev hvorfor jeg mente dette, du argumenterte med at jeg tok feil fordi du ikke forstod hva jeg mente.

 

Du har ikke lagt frem et eneste bevis på hvorfor det å bruke Python til å skrive store omfattende ressurskrevende programmer kan være uheldig for sluttbrukeren. Så *enten* legg frem fakta, eller innrømm at du ikke har noe belegg for slike påstander. Men slutt å spre løgner.

 

Manglende forståelse av DINE definisjoner, ja. Jeg har ikke utviklet telepatiske evner (enda?), så du får ha meg unnskyldt hvis jeg ikke vet hva DINE definisjoner betyr, enda jeg har slått opp i "Compilers" til Aho et al og ikke funnet DINE definisjoner der.

Så få hodet ditt opp av bøkene og les det jeg skriver.

 

Denne var ny. Mao. først blir jeg anklaget for å ikke ha nok kunnskap, og så ber du meg om å ikke skaffe meg kunnskap om emnet? Og det er *min* argumentasjon du har lite til overs for? Imponerende.

 

Tilbake til den opprinnelige saken -- du har fremdeles ikke forklart hva gjør kompilering av Python "klønete". Jeg venter fremdeles.

Jeg har annet å gjøre en å krangle med en gjøk som ikke engang gidder å lese igjennom alt jeg skriver,

 

Flott. Du har altså sunket til å skjellsord. Igjen, det er *min* argumentasjon du har lite til overs for?

 

og henger seg opp fordi han ikke forstår hva jeg mener. Det er ikke sånn at det er ulovlig å bruke ord du ikke har lest i en bok, hvis du ikke forstår hva jeg mener, så har du et problem.

 

Du kan naturligvis bruke din egen terminologi. Det skulle vitterlig bare mangle. Men du kan ikke forvente at andre personer skal kunne *din* (og bare din?) terminologi utenat. Du kan heller ikke forvente at andre skal vite på et magisk vis hvilke tolkninger du legger inn i definisjonene dine. Og når du etter gjentatte forsøk ikke har greidd å definere begrep du bruker selv, når du selv blir forvirret av de mest grunnleggende begrepene innen kompilatorteknikk (jfr språk<->implementasjon) og attpåtil finner du på terminologi som annerkjent litteratur innen faget ikke nevner, så er det ikke jeg som har et problem.

 

Jeg har forklart hva jeg mener så tydelig jeg kan.

 

Men du har ikke svart på det aller første og enkleste spørsmålet. Nok en gang -- hvorfor er:

 

$ python foo.py

 

... klønete?

Endret 17. desember 2008 av zotbar1234

[GeirGrusom]

Slutt å kverulere, jeg har sagt hva jeg mener opp til flere ganger, og jeg har bedre ting enn å krangle med deg.

[zotbar1234]

Slutt å kverulere, jeg har sagt hva jeg mener opp til flere ganger, og jeg har bedre ting enn å krangle med deg.

 

Du trenger ikke å *krangle*. Men enten har du belegg for påstandene dine, eller så har du ikke det. Hittil har du lagt frem en eneste objektiv begrunnelse på hvorfor

 

$ python foo.py

 

(mao. kompilering av Pythonkode) skulle være klønete. Har du ikke en slik begrunnelse, er det helt i orden. Men da bør du innrømme at du ikke har det, og trekke påstanden din om klønete kompilering tilbake, slik at de som faktisk står ved en veiskille ikke blir villedet av uriktige påstander fra din side.

[GeirGrusom]

Påstandene mine er ikke uriktige bare fordi du ikke forstår hva jeg mener.

 

Men det at du skriver ned den kommandolinja der får meg til å tro at du er helt på jordet når det gjelder hva jeg snakker om.

 

edit:

Du visste ikke hvordan en behandler void* datatyper i C, du viser ingen forståelse for hvordan Python eller andre språk kompileres til forskjellige nivåer (det virket ikke som om du er klar over hva python byte code er engang) du skriver ned en kommandolinje for å starte et python script som er 101% irrelevant for diskusjonen.

 

Det eneste du gjør er å forsvare språket du sannsynligvis bruker.

 

Mitt argument var at Python ikke alltid er tilstrekkelig til alle oppgaver når det gjelder visualisering. Helt tilfeldigvis så er det akkurat 3D grafikk og slikt jeg jobber mest med for tiden, og jeg vet hva som kreves.

Hvilken implementasjon av Python som brukes er egentlig irrelevant, av to grunner:

- 99% av alle som bruker Python bruker CPython

- CPython er referanseimplementasjonen og standarden på språket, som andre compilere må føye seg etter, og denne definisjonen mangler noen ting som kan være kritisk når det gjelder ytelse for behandling av svært store datamengder på svært kort tid.

 

OK? dette er argumentene mine summert opp i to forholdsvis korte linjer.

 

Du nevnte for eksempel at en kan skrive utvidelser i C for å gjøre krevende oppgaver, som er et argument jeg aksepterer, og som du burde forsøkt å fremheve bedre.

Istedet har du prøvd å angripe mine argumenter og få meg til å kaste bort masse tid på å forklare deg ting du burde ha visst eller forstått før du kastet deg ut i dette.

 

Jeg har nesten lyst til å fakturere deg for det.

Endret 18. desember 2008 av GeirGrusom

[NevroMance]

Er veldig enig med GeirGrusom her. Python er i bunn og grunn et interpreta språk, og ikke noe som vanligvis kompileres. De fleste kompilatorene til python gjør vel heller ikke stort annet enn å skjule kildekoden, selv om noen selvsagt kompilerer og optimaliserer koden. Ved tester ser en jo også at python er vesentlig tregere enn språk som java som er kompilert. For å ta det siste så kompilerer vel ikke kommandoen:

$ python foo.py

foo.py fila, men kjører kun fila gjennom interpreteren.

 

Når det er sagt synes jeg selv python er et veldig morsomt og nyttig språk, til sitt bruk. Tor beregninger og programmer som trenger hastighet må jeg si python ikke er veldig egnet.

[GeirGrusom]

Er veldig enig med GeirGrusom her. Python er i bunn og grunn et interpreta språk, og ikke noe som vanligvis kompileres. De fleste kompilatorene til python gjør vel heller ikke stort annet enn å skjule kildekoden, selv om noen selvsagt kompilerer og optimaliserer koden. Ved tester ser en jo også at python er vesentlig tregere enn språk som java som er kompilert. For å ta det siste så kompilerer vel ikke kommandoen:

$ python foo.py

foo.py fila, men kjører kun fila gjennom interpreteren.

 

Når det er sagt synes jeg selv python er et veldig morsomt og nyttig språk, til sitt bruk. Tor beregninger og programmer som trenger hastighet må jeg si python ikke er veldig egnet.

 

Endelig! noen som forstår!

spot on!