Hva er poenget med dynamiske datatyper?

[GeirGrusom]

Ikke hundre prosent sikkert, men det er temmelig standard fremgangsmåte når en lager programmeringsspråk.

Ja om du ikke regner Lua, Python og PHP som språk er muligens det riktig.

 

 

C er ganske vanlig at en starter i, fordi bison og yacc er primært for C. Men det er relativt normal praksis å gå over til det språket en utvikler. F# og C# er ikke på noen måte unike når det gjelder dette.

[Gjest Slettet+9871234]

C er ganske vanlig at en starter i, fordi bison og yacc er primært for C.

C er vel også en tallknuser med lite "overhead".

 

Jeg kjenner ikke de andre språkene dere nevner.

[GeirGrusom]

edit: F# er skrevet i F#

Takk for det.

 

Naturlige spørsmål:

 

1. Portabilitet?
   
2. Betinget kompilering?
   
3. Inline assembly?
   
4. Brukerstøtte?
   
5. Utbredelse større enn BETA og GBETA?
   
6. Standardisering.
   
7. Hvor mange jobber med å utvikle språket?
   
8. Biblioteker?
   

Portabilitet: Målet er .NET, og derfor svært portabelt (gjennom Mono). Trenger ikke rekompilere engang.

 

Betinget kompilering: Nei. Programmet blir kompilert just-in-time, så det er ikke noe poeng, ettersom en helt vanlig if setning gjør samme nytten.

 

Inline assembly: Nei. inline assembly er ikke portabelt. Men du kan generere CIL kode run-time (System.Reflection.Emit)

 

Brukerstøtte: Aner ikke, bryr meg ikke

 

Utbredelse: Aner ikke. Jeg tror ikke F# er spesielt utbredt, men det er bare antagelser

 

Standardisering: Vet ikke egentlig, men kildekoden er tilgjengelig under Apache, så virker ganske åpent i det minste.

 

Utviklere: Vet ikke.

 

Standardbiblioteker: Bruker .NET, og har derfor et ganske massivt standardbibliotek.

 

edit:

 

yacc og bison er parser generators, eller compiler compiler om du vil. Disse er svært vanlig i bruk når en lager programmeringsspråk. (Jeg tør vedde sokkene mine på at PHP, Lua og Python alle er laget i bison og yacc)

Endret 28. april 2011 av GeirGrusom

[MailMan13]

Du leser det som om det står "Class is not Type"?

Leste du mine poster #43 og #44?

Jo jeg gjorde det. Derfor synes jeg det er rart at du skiver:

Egenproduserte "datatyper" klasser er ikke datatype.

For det mener jeg det er. Type er som du referer til oppførsel. Oppførselen til et objekt som er instans av en klasse er gitt av objektets klasse, ergo er objektets type gitt av objektets klasse. Jeg ser ingenting i noe av det du refererer som motsier det på noe måte.

 

Typebegrepet er mye videre enn klasse, derfor er jeg enig i at "Type is not class" som du siterer.

 

Klasse definerer mer enn type, blandt annet oppførsel, derfor bestemmer den type også. Derfor har du ikke rett når du sier "Egenproduserte "datatyper" klasser er ikke datatype.", altså kan du ikke lese "Class is not type" av noe du siterer, selv om det motsatte er sant.

 

Andrew Koenig

 

"Templates and generic algorithms" JOOP june 1994

 

"Generic iterators" JOOP September 1994

 

"Function objects, templates and inheritance" JOOP September 1995

 

Oppdater dere på språket før dere dømmer det. Jeg tror jeg holder en knapp på Texas professoren http://www2.research.att.com/~bs/

Hva har disse med saken å gjøre? Jeg viste til og med med eksempel hva jeg mente. I C++ må template-typen eksplisitt deklareres på alle argumenter, og i mange situasjoner er man eksplisitt nødt til å gi typeargument ved invokering også.

 

Du maner til forsiktighet, men dine argumenter er "jeg har rett, du har feil, jeg har ikke tid til å argumentere, men les disse bøkene...". Forklar hva du mener er feil, gi noen eksempler hvis du er uenig. Det kan umulig ta noe særlig lenger tid enn å google noen bøker.

Endret 28. april 2011 av MailMan13

[worseisworser]

C er ganske vanlig at en starter i, fordi bison og yacc er primært for C.

C er vel også en tallknuser med lite "overhead".

 

Jepp, helt klart, men om en ønsker eller trenger rå (eller "hjernedød" .. hehehe) hastighet for en eller annen ting finnes det også andre alternativer:

http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php

 

ADA og ATS er f.eks. ganske gode m.t.p. dette. En kan så klart også skrive sin løsning i flere språk "samtidig"; altså f.eks. kombinere Python og C ved å bruke FFI ( http://en.wikipedia.org/wiki/Foreign_function_interface ).

Endret 28. april 2011 av worseisworser

[Gjest Slettet+9871234]

Betinget kompilering: Nei. Programmet blir kompilert just-in-time, så det er ikke noe poeng, ettersom en helt vanlig if setning gjør samme nytten.

 

Inline assembly: Nei. inline assembly er ikke portabelt. Men du kan generere CIL kode run-time (System.Reflection.Emit)

Dermed kan man heller ikke skrive inline assembly kode som avhenger av prosessor, AMD, Motorola, Intel, Sparc, RISC, Vektorprosessor etc.

[Gjest Slettet+9871234]

ADA og ATS er f.eks. ganske gode. En kan så klart også skrive sin løsning i flere språk "samtidig"; altså f.eks. kombinere Python og C ved å bruke FFI ( http://en.wikipedia.org/wiki/Foreign_function_interface ).

Ja og hvorfor ikke

 

ALGOL 58 predates Simula; Simula is a "fairly faithful" superset of ALGOL 60.

 

og Simula som også er ganske raskt. Mener ADA ble brukt på FFI på Kjeller. Og Delphi http://www.embarcadero.com/products/delphi er jo Object Pascal som svært mange liker.

 

C passer som hånd i hanske med C++ og mange språk har C syntaks som man er vant til. Et sted må man sette strek.

 

Skal se på debatten på NrK 1 om skatt og avgifter.

 

Rettet NrK 2 til NrK 1 etter svar.

Endret 28. april 2011 av Slettet+9871234

[GeirGrusom]

Betinget kompilering: Nei. Programmet blir kompilert just-in-time, så det er ikke noe poeng, ettersom en helt vanlig if setning gjør samme nytten.

 

Inline assembly: Nei. inline assembly er ikke portabelt. Men du kan generere CIL kode run-time (System.Reflection.Emit)

Dermed kan man heller ikke skrive inline assembly kode som avhenger av prosessor, AMD, Motorola, Intel, Sparc, RISC, Vektorprosessor etc.

Nei. Men et program skrevet i C eller C++ kan da heller ikke flyttes til andre plattformer uten at koden må rekompileres. Og har du inline assembly, så vil det bli masse ekstra jobb.

[worseisworser]

Et sted må man sette strek.

 

Helt klart, men en kan da være nysgjerrig på og snakke om en verden også utenfor (eller i ytterkanten av) den en har umiddelbart foran seg -- uten at det er truende? Jeg synes i hvert fall mye av dette er interessant og spennende, selv om språkene vi faktisk bruker ikke støtter alt like bra eller t.o.m. i det hele tatt. Det originale spørsmålet (emnet for tråden) er jo også veldig generelt når en ser etter; det kan omhandle ting som allerede eksisterer, og kun det, eller også ting en "ser for seg"; potensielle muligheter.

 

I utgangspunktet er både bruk av språk, i seg selv, og valg av språk (etterfulgt av det å lære seg det en har bestemt seg for) snakk om et forsøk på å spare mest mulig tid totalt sett.

 

Jeg skulle veldig gjerne ha sett nærmere på flere sider ved Haskell f.eks., men setter også ei grense foreløpig m.t.p. tid, ja -- selv om det sikkert er flere ting og muligheter ved det språket som ville spart meg for tid i visse sammenhenger. Det handler vel om totalen og balanse, eller grenseverdier -- og en er tilbake til streken din igjen.

Endret 28. april 2011 av worseisworser

[Gjest Slettet+9871234]

Nei. Men et program skrevet i C eller C++ kan da heller ikke flyttes til andre plattformer uten at koden må rekompileres. Og har du inline assembly, så vil det bli masse ekstra jobb.

Som nevnt er formålene ulike.

 

For de som skal ta bilder av fjerne gallakser som vil kreve 30 års kjøretid med noen programmer og prosessorer, betyr det gjerne ikke så mye at man rekompilerer og at man får ekstra jobb med inline assembly.

 

C er minimalistisk, kompakt og nær maskinkode, lavnivå. Det trengs til noe. Inline ASM { } beregnet på andre prosessorer er også viktige argumenter i disse sammenhengene.

 

Personlig bruker jeg som nevnt php til web programmering.

 

Helt klart, men en kan da være nysgjerrig på og snakke om en verden også utenfor (eller i ytterkanten av) den en har umiddelbart foran seg -- uten at det er truende?

 

Jeg driver ikke med å sende rakatter til mars eller romskip lenger ut i verdensrommet der man trenger å legge inn kaotisk dynamikk for at de skal kunne forlate vårt solsystem. Til mitt bruk ville "rocket scientists crash out of orbit".

 

GeirGrusom som driver med spillprogammering skulle jo aldri får nok datakraft om han vil lage spill som simulerer andre gallakser, intergallaktiske reiser og fraktale plasmaskyer .

 

Som ord av en papegøye, men ...

Endret 28. april 2011 av Slettet+9871234

[x871kx6167ss7]

Med alt dette snakket om verdensrommet kom jeg på følgende.

 

An even more impressive instance of remote debugging occurred on NASA's 1998 Deep Space 1 mission. A half year after the space craft launched, a bit of Lisp code was going to control the spacecraft for two days while conducting a sequence of experiments. Unfortunately, a subtle race condition in the code had escaped detection during ground testing and was already in space. When the bug manifested in the wild--100 million miles away from Earth--the team was able to diagnose and fix the running code, allowing the experiments to complete.¹⁴ One of the programmers described it as follows:

Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem.

 

fra http://www.gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-the-repl.html

Endret 28. april 2011 av peterbb

[Gjest Slettet+9871234]

Interessant.

 

"Hello, World," Lisp Style

 

No programming book is complete without a "hello, world" program. As it turns out, it's trivially easy to get the REPL to print "hello, world."

CL-USER> "hello, world"
"hello, world"

 

Et av begrepene jeg nevnte ovenfor trenger gjerne forklaring, nemlig begrepet kaotisk dynamikk.

 

Med det menes at raketten som skulle sendes ut av vår solsystem benytter de interplanetære gravitasjonene. Den tangerer planetenes atmosfærer som en sten tangerer vannflaten. Romskipet oppnår på den måten økt fart for videre reise utover i rommet når det tangerer planetenes baner om beregningene er nøyaktige nok.

 

Her http://www.kjellbleivik.com/temp/ er litt fractal kode i C. Last ned til undervisningsformål om dere trenger den før den fjernes fra temp mappen.

Endret 30. april 2011 av Slettet+9871234

[Gjest Slettet+9871234]

Du leser det som om det står "Class is not Type"?

Godt poeng.

 

Du leser det som om det står "Class is not Type"?

Leste du mine poster #43 og #44?

Jo jeg gjorde det. Derfor synes jeg det er rart at du skiver:

Egenproduserte "datatyper" klasser er ikke datatype.

For det mener jeg det er. Type er som du referer til oppførsel. Oppførselen til et objekt som er instans av en klasse er gitt av objektets klasse, ergo er objektets type gitt av objektets klasse. Jeg ser ingenting i noe av det du refererer som motsier det på noe måte.

 

Typebegrepet er mye videre enn klasse, derfor er jeg enig i at "Type is not class" som du siterer.

 

Klasse definerer mer enn type, blandt annet oppførsel, derfor bestemmer den type også. Derfor har du ikke rett når du sier "Egenproduserte "datatyper" klasser er ikke datatype.", altså kan du ikke lese "Class is not type" av noe du siterer, selv om det motsatte er sant.

Det er år siden jeg leste ovenfor siterte bok og jeg er langt borte fra de finere detalsjer i OOP. Forutsatt at du har rett, og det har du sikkert, så lærer man så lenge man lever. Den som er ferdig utlært er ikke utlært men ferdig. Slike innlegg gjør denne tråden svært opplysende og interessant.

 

 

 

Andrew Koenig

 

"Templates and generic algorithms" JOOP june 1994

 

"Generic iterators" JOOP September 1994

 

"Function objects, templates and inheritance" JOOP September 1995

 

Oppdater dere på språket før dere dømmer det. Jeg tror jeg holder en knapp på Texas professoren http://www2.research.att.com/~bs/

Hva har disse med saken å gjøre? Jeg viste til og med med eksempel hva jeg mente. I C++ må template-typen eksplisitt deklareres på alle argumenter, og i mange situasjoner er man eksplisitt nødt til å gi typeargument ved invokering også.

 

Du maner til forsiktighet, men dine argumenter er "jeg har rett, du har feil, jeg har ikke tid til å argumentere, men les disse bøkene...". Forklar hva du mener er feil, gi noen eksempler hvis du er uenig. Det kan umulig ta noe særlig lenger tid enn å google noen bøker.

Forsiktighet i betydningen dersom du ikke kjenner den siste utviklingen av C++. Uansett om de artiklene jeg refererer til ikke svarer på dine spørsmål indikerer ihvertfall titlene hva som var mulig i C++ på midten av 90 tallet. Den siste utviklingen av språket kjenner jeg som nevnt ikke. Andre som poster i denne tråden er i samme bås ser det ut til.

 

Takk for glimrende svar. Det er lenge siden jeg har brukt C++ bortsett fra som en introduksjon til C++Builder 2009 og C++Builder og da som meget enkle eksempler. Jeg bruker stort sett bare JavaScript og PHP for tiden av naturlige årsaker og de språkene er svært "sloppy" for å si det mildt.

Endret 30. april 2011 av Slettet+9871234