hvorfor skal ikke den vanlige personen i gata lenger få bruke delphi ?

[GeirGrusom]

En interessant sak er vel at den gamle sjefsutvikleren for Borland er nå ansatt av Microsoft og er sjefsutvikleren for C#.

[zotbar1234]

alt som må visualiseres mister litt ytelser i forhold til det som kjøres direkte.

 

Jeg vet ikke helt om jeg forstod denne. "Visualiseres" vs "kjøres direkte" -- huh?

 

Om utsagnet er gammelt eller nytt spiller ingen rolle for dets gyldighet. Det gir ikke mening om snakke til hastigheten til språk.

[GeirGrusom]

alt som må visualiseres mister litt ytelser i forhold til det som kjøres direkte.

 

Jeg vet ikke helt om jeg forstod denne. "Visualiseres" vs "kjøres direkte" -- huh?

 

Om utsagnet er gammelt eller nytt spiller ingen rolle for dets gyldighet. Det gir ikke mening om snakke til hastigheten til språk.

Jeg tror den andre elgen snakker om "virtualisering" og de kanskje litt mer presist virtuelle maskiner som Java Runtime Environment eller CPython.

Men hastigheten til en virtuell maskin er avhengig av implementasjonen. JRE og .NET kompilerer som sagt til maskinkode, og utenom at det kan ta lenger tid å laste (ettersom programmet kompileres til maskinkode hver gang kode blir kalt) så skal JRE programmer kjøre vel så raskt som Delphi.

 

Når det gjelder operativsystem virtualisering så gjelder samme regla.

 

Men når det gjelder språk, så er det en viss sannhet i at et programmeringsspråk kan ansees som tregere enn et annet. Eksempelvis kan du sammenligne C som har pekere, peker-aritmetikk og mangler objektorientering som er numero uno på ytelse uavhengig av implementasjon. Det er vanskelig å få et javaprogram (eller Delphi-program for den saks skyld) til å gå like raskt.

Et annet eksempel er språk som kun støtter dynamiske datatyper. Dette fordi en variabel uten en spesifikk datatype er vanskelig å skrive en implementasjon som er istand til å mappe programmet i en slik stil at det er istand til å forutse datatypen uten å måtte sjekke run-time (C programmer trenger ingen run-time sjekk av datatypen til en variabel).

En implementasjon er begrenset av definisjonen.

 

edit: Delphi er vel ikke rette språket å skryte av ytelse på heller. Visual Basic 6.0 kompilerte til native code (som standard) og det hadde statisk typing og alt mulig, men det lå allikevel forholdsvis lavt på ytelsesstokken.

Endret 26. januar 2010 av GeirGrusom

[zotbar1234]

Men når det gjelder språk, så er det en viss sannhet i at et programmeringsspråk kan ansees som tregere enn et annet.

 

Nei, det er ikke det.

 

hint#1: Du kan ikke måle hastigheten til et språk, kun til dets implementasjon.

hint#2: *Alt* utover de mest trivielle (og derfor komplett uinteressante) eksempeler a la "1 + 2" blir fort fryktelig vanskelig å sammenligne språk i mellom. Derfor er det heller ikke meningsfylt å si at "1 + 2" i C er raskere enn "(+ 1 2)" i Common Lisp, selv om man midlertidig skulle se bort fra absurditeten av å nevne språkets hastighet.

 

Eksempelvis kan du sammenligne C som har pekere, peker-aritmetikk og mangler objektorientering som er numero uno på ytelse uavhengig av implementasjon. Det er vanskelig å få et javaprogram (eller Delphi-program for den saks skyld) til å gå like raskt.

 

Si meg en ting, hvordan måler du "like raskt"? Og hvilket Java-program skulle det være? (i forhold til C-programmet).

 

Et annet eksempel er språk som kun støtter dynamiske datatyper. Dette fordi en variabel uten en spesifikk datatype er vanskelig å skrive en implementasjon som er istand til å mappe programmet i en slik stil at det er istand til å forutse datatypen uten å måtte sjekke run-time (C programmer trenger ingen run-time sjekk av datatypen til en variabel).

 

Jeg ser ikke helt hvordan dette er overhodet relevant for gyldigheten av utsagnet "språk A er raskere enn språk B".

 

En implementasjon er begrenset av definisjonen.

 

Ja, og? Hvordan i himmelens navn greier du deretter å komme frem til konklusjonen om at det er en viss sannhet i et meningsløst utsagn?

[tingo]

@den andre elgen:

kan du ikke bare bruke Free Pascal da?

[sinnaelgen]

det kan jeg sikkert.

men er ikke lazarus en del av freepascal ?

 

som jeg skrevi første post så var ikke lazarus het etter forventingen.

 

jeg er enig med der i at det er sunt å kunne mange programmeringsspråk.

 

derimot så er jeg ikke sikker på om det er bra å lære så mange på samme tid.

 

 

et problem med pascal/delphi var at i en tidligere versjon var det enkelt operette en database etter egne ønsker , men denne muligheten forsvant i senere versjoner.

 

jeg kunne tenke meg å lage et program som betjener flere databaser på en gang.

det jeg har i tanken er en database over bladsamlingen jeg har.

grunn tanken er hver blad type eller bok har hver sin tabell som likevel kan ha referanser med hverandre.

 

 

f.eks så har jeg en donald duck samling som består av både bøker og blader i permer.

 

bladene i en tabell

bladene er plassert i permer . der trenger jeg en tabell

pocketbøkene i en ( egentlig fler - det er flere typer pocketbøker )

o.s.v

detaljene for jeg ta i en anen sammenheng

 

 

her kunne jeg tenke meg fler måter å få ut informasjon fra en slik database og gjerne fler typer statistikker

 

 

hvilket språk/ program er best egnet til det ?

 

 

 

Delphi/pascal kompiler til "maskin kode" til en exe fil før det kjøres i operativsystemet.

det samme er det med C eller C+ eller hva nå de heter alle disse variantene

 

Java som er avhengig av et skall ( Java visuel runtime) som alt må gå mellom så forstår jeg ikke hvor det skal forløpe like fort. det enste må være at pcen er så kjapp i seg selv at det spiller ingen rolle.

 

driver man å leker seg med lit grafikk så skal det ikke mye til før det går tregt

 

virtuell pc ( som jeg prøvde å komme lit inn på) for å sammenligne det med Java virtuelt runetime er i mine øyene en simulator

Endret 26. januar 2010 av den andre elgen

[Sokkalf™]

Høres ut som språket du er ute etter er SQL

 

Fra spøk til alvor. En øvelse med å lage en slik database er en perfekt jobb for PHP, Ruby (on Rails), Python (Django), Java (JSP, Servlet eller Groovy on Grails), e.l.

 

Dvs at du presenterer dataene i en webside.

 

Å lage selve databasen selv er meningsløst. Bruk MySQL, SQLite, PostgreSQL e.l, du gjør oppslag i disse fra programmeringsspråket du velger.

 

Hvis det er denne typen programmering du ønsker å drive med - lær deg ett av de ovennevnte språkene samt SQL. Da er du et godt stykke på vei.

[sinnaelgen]

@den andre elgen:

kan du ikke bare bruke Free Pascal da?

 

jeg forsøkte å laste ned et eksempel via den nettsiden men da må jeg ha brukernavn og passord .

her kunne jeg ikke finne noen måte å registrer seg på.

[zotbar1234]

Delphi/pascal kompiler til "maskin kode" til en exe fil før det kjøres i operativsystemet.

det samme er det med C eller C+ eller hva nå de heter alle disse variantene

 

Pythonkoden kan også kompileres til exe-kode før "den kjøres i operativsystemet". Hva er poenget ditt?

 

Java som er avhengig av et skall ( Java visuel runtime)

 

Java hva-for-noe?

 

Hvis du mente å si at Java-programmene er avhengige av Java-omgivelsen for å kunne eksekveres, så gjelder dette mesteparten av språk, uansett om de er kompilerte eller interpreterte.

 

(...) som alt må gå mellom så forstår jeg ikke hvor det skal forløpe like fort.

 

Ja, det er opplagt at du ikke forstår hvorfor "det" skal forløpe like fort. Men jeg ser ikke helt hvordan din mangel på forståelse gir utsagnet "språk A er raskere enn språk B" mening. Eller hvorfor din mangel på forståelse skal hindre at en, si Common Lisp, implementasjon ikke skal kunne eksekvere et gitt program like kjapt som det ekvivalente C-programmet.

 

driver man å leker seg med lit grafikk så skal det ikke mye til før det går tregt

 

Denne setningen gav overhodet ikke mening.

 

virtuell pc ( som jeg prøvde å komme lit inn på) for å sammenligne det med Java virtuelt runetime er i mine øyene en simulator

 

Hva i huleste har en virtuell PC med JVM å gjøre? Ved siden av dette, har du hørt om JIT? Eller om en rekke andre teknikker for mapping av bytekoden til maskinkode (psyco+CPython er et annet opplagt eksempel)? Kan du komme på et eneste ikketrivielt eksempel der *språkets* konstruksjoner (heller enn begrensningene i en spesifikk implementasjon) har hindret deg fra å oppnå spesifikke ytelsesmål?

[Emancipate]

det er selvfølgelig en vane sak. Men hvem har lyst til å gå tilbake flere år for så å begynne på nytt.

C-familie-syntaksen er det nok lurt å venne seg til uansett

Tror ikke det er noen vanesak. Jeg lærte meg programmering i et curly-braces-språk, og likevel vente jeg meg aldri til det. Det er ikke det at det er uleselig, det er bare så vanvittig stygt.

 

Free Pascal kan for øvrig lastes ned her: ftp://ftp.freepascal.org/pub/fpc/dist/2.4....i386-win32.exe

 

Men det passer nok ikke for trådstarter ettersom det ikke følger med grafiske komponenter og IDE.

[sinnaelgen]

poenget mit er at når java må kjøre via denne "virtuelle maskinen" så er både pascl, C og python for den saks skyld raskere å kjøre ( programmet kjøre på en raskere kode )

 

 

jeg mener disse greine som må til for at java programmer kan utføres .

java blir ikke kompilert til rask kode når det utføres men må kjøres via dett tillegget

 

 

kan du forklare meg hvorfor 2 programmer der det ene er kompilert til kjørbar kode og det andre må gå et ekstra ledd

er like raskere ? du vil nok også påstå at Java utføres raskere en C programmer

 

det med grafikken var å poengtere at det går raskere jo mer direkte koden er

 

 

nå er det ikke språket ( syntaksen) i seg selv som er problem men hvordan koden utføres når programmet kjøres altså den plattformen det er avhengig av for å kjøres.

 

jave ar avhengig av en plattform for kjøre : java runtim et eller annet

 

 

JVM er an visualisering ( gjerne simulering av hardware og maskin kode) mens virtuelt pc er simulering av al hardware.

det har sammenheng fordi det er så likt hverandre

 

 

men hvordan får jeg laste ned freepascal uten passord ?

[sinnaelgen]

Høres ut som språket du er ute etter er SQL

 

Fra spøk til alvor. En øvelse med å lage en slik database er en perfekt jobb for PHP, Ruby (on Rails), Python (Django), Java (JSP, Servlet eller Groovy on Grails), e.l.

 

Dvs at du presenterer dataene i en webside.

 

Å lage selve databasen selv er meningsløst. Bruk MySQL, SQLite, PostgreSQL e.l, du gjør oppslag i disse fra programmeringsspråket du velger.

 

Hvis det er denne typen programmering du ønsker å drive med - lær deg ett av de ovennevnte språkene samt SQL. Da er du et godt stykke på vei.

 

 

når det gjelder SQL så klarte jeg aldri å forstå det helt.

jeg har fått den fornærmelsen for å bruke det til å finne data må vite stedet ( mas skal søke opp) før man søker det opp.

 

forøvrig så er det ikke bare Databaser jeg ønsker å lære meg.

 

jeg har nå begynt å lure på om dere skal bestemme hva jeg bør lage fremfor det jeg har lyst å lage.

her er det mest snak om å eksperimentere og se hva som går an.

 

ikke det at jeg tro at dere vil det , men ...

 

 

hvorfor webside ? jeg vil ikke gjøre programmet avhengig av en nettlser.

 

jeg ønsker å ha mulighetene til å endre antall kolonner i tabellen uten at alt dat må tastes inn på nytt

 

det du skriver innenfor parentesene er det navnet på prosjekter eller : on Rails,Django,JSP, Servlet eller Groovy on Grails.

det er ting jeg aldri har hørt om.

jSP mener jeg har hørt om

[GeirGrusom]

Men når det gjelder språk, så er det en viss sannhet i at et programmeringsspråk kan ansees som tregere enn et annet.

 

Nei, det er ikke det.

 

hint#1: Du kan ikke måle hastigheten til et språk, kun til dets implementasjon.

hint#2: *Alt* utover de mest trivielle (og derfor komplett uinteressante) eksempeler a la "1 + 2" blir fort fryktelig vanskelig å sammenligne språk i mellom. Derfor er det heller ikke meningsfylt å si at "1 + 2" i C er raskere enn "(+ 1 2)" i Common Lisp, selv om man midlertidig skulle se bort fra absurditeten av å nevne språkets hastighet.

 

Så språkfeatures laget for å øke hastigheten (inline, fastcall, pekere, referanser, unchecked, strukturer i C#) er unødvendig fordi implementasjonen burde klare å gjette seg frem til disse hintene?

[zotbar1234]

poenget mit er at når java må kjøre via denne "virtuelle maskinen" så er både pascl, C og python for den saks skyld raskere å kjøre ( programmet kjøre på en raskere kode )

 

"Programmet kjører på en raskere kode" -- i hvilket univers gir dette utsagnet mening?

 

At java har en virtuell maskin, betyr *slettes* ikke at Java ikke kan kompileres til maskinkoden på den platformen som JVM kjører på. Herregud, du trenger ikke lengre enn wikipedia for å få med deg dette.

 

jeg mener disse greine som må til for at java programmer kan utføres .

 

"Disse greiene"? Takk for en presis beskrivelse.

 

java blir ikke kompilert til rask kode når det utføres

 

Om java blir kompilert til _rask_ kode avhenger av definisjonen av rask og kvaliteten på implementasjonen. Det er heller ingenting i språkdefinisjonen som gjør det umulig å kompilere java til maskinkoden for den arkitekturen som programmet skal utføres på. Igjen, wikipedia.

 

Maskinkode != rask kode. Sånn, for ordens skyld.

 

(...) men må kjøres via dett tillegget

 

Meningsløst utsagn. Igjen.

 

kan du forklare meg hvorfor 2 programmer der det ene er kompilert til kjørbar kode og det andre må gå et ekstra ledd er like raskere ? du vil nok også påstå at Java utføres raskere en C programmer

 

Kan du først mestre dine egne utsagn, før du begynner å tilordne dem meg? Kan du greie dette, om ikke annet?

 

Jeg savner fortsatt beskrivelsen av dette "ekstra leddet" (og ikke minst hva det gjør, og hvorfor det leddet *må* finnes der). Jeg har allerede gitt deg 2 eksempler på mekanismer som kan brukes av språk der mellomrepresentasjonen av noe form står relativt sentralt i eksekveringsmodellen. Jeg ser ikke noe poeng i å gjenta det samme for å svare på det samme spørsmålet, siden du opplagt ikkke leste det den første gangen.

 

Sist, men ikkke minst, vil jeg aldri finne på å komme med et meningsløst utsagn som "Java er raskere/tregere enn C". Ingen språk er raskere/tregere enn andre -- hvorfor er det så vanskelig å fatte?

 

nå er det ikke språket ( syntaksen) i seg selv som er problem men hvordan koden utføres når programmet kjøres altså den plattformen det er avhengig av for å kjøres.

 

Ja, og?

 

jave ar avhengig av en plattform for kjøre : java runtim et eller annet

 

C er avhengig av runtime environment til språket C. DUH!

 

JVM er an visualisering ( gjerne simulering av hardware og maskin kode)

 

Vær så snill, åpne en Java-bok, les den, og kom deretter tilbake. Da kan vi fortsette denne diskusjonen.

 

At java virtual machine er en visualisering (og av hva, eksakt?) var nokså nytt for meg. At JVM var en simulering av hardware var også rimelig nytt, selv om bytekoden i seg selv representerer konseptuelt sett en stack-orientert maskin.

 

At du derfra greier på et magisk vist å slutte at C må være raskere enn Java er hinsides all fornuft.

Endret 27. januar 2010 av zotbar1234

[zotbar1234]

Så språkfeatures laget for å øke hastigheten (inline, fastcall, pekere, referanser, unchecked, strukturer i C#) er unødvendig fordi implementasjonen burde klare å gjette seg frem til disse hintene?

 

Hvordan greide du å slutte dette fra det jeg skrev?

 

At et språk A har konstruksjoner for å hjelpe kompilatoren når et annet språk B ikke har det BETYR IKKE at A er raskere enn B. Det kan bety at det er lettere å lage en implementasjon av A som genererer bedre kode enn en implementasjon av B. Men det igjen er ingen ekvivalens med at "språk A er raskere enn språk B".

Endret 27. januar 2010 av zotbar1234

[JohndoeMAKT]

For å gjøre zotbar1234s utsagn at «et språk er ikke raskere enn et annet, en implementasjon er raskere enn en annen» kan jeg komme med en *drumroll* bilanalogi.

 

Dersom jeg er passasjer i en bil og sier til sjoføren «akselerer fra null km/h opp til hundre km/h» eller «accelerate from zero km/h to one hundred km/h», hvilken av de to språkene får bilen til å akselerere på kortest tid?

 

Her er det ganske klart at hvilket språk kommandoen blir gitt på ikke har noe å si på bilens akselerasjon, det er helt opp til førerens (parserens/kompilererens/enterpreterens) dyktighet og bilens (maskinvarens) egenskaper. Dersom du snakker norsk til en Ferrari-fører og englandsk til en Lada-fører betyr ikke det at «norsk akselererer raskere enn englandsk» og det gjelder heller ikke dersom du gir den norske kommandoen til en norsk fører som med en gang utfører den og den englandske til en greker som må slå opp i en ordbok for å forstå hva som skal gjøres.

 

Gitt samme bil (maskinvare) vil forskjellen på eksekveringshastighet av forskjellige språk ligge på føreren hvor du derimot kan si at en fører er dyktigere eller raskere enn en annen. JavaScript er et godt eksempel hvor det finnes mange motorer som JScript, Rhino, Spidermonkey, Tracemonkey, V8, KJS, JavaScriptCore, SquirrelFish, Nitro, Linear A, Linear B, Futhark, Carakan, Narcissus, Tamarin og IBM JS. Carakan er Operas nyeste motor som finnes i Opera 10.50 mot Futhark som har vært med oss i over halvannet år. I praksis er Carakan omtrent tyve ganger raskere enn Futhark som igjen i noen tilfeller er hundre ganger raskere enn Internet Explorers JScript, men det betyr ikke at selve JavaScript-koden er raskere eller tregere, det er jo nøyaktig samme kode som blir kjørt.

[GeirGrusom]

Jeg får ta det i ytterste ekstreme poler: vil en latterlig god implementasjon av brainfuck noensinne kunne gi maskinkode som er tilsvarende rask som GCC?

[Wattengård]

Er det bare jeg som lukter et forumtroll her?

 

-C-

[quantum]

Dine argumenter mot andre språk enn Delphi/Pascal forekommer meg veldig merkelige, og sære. At curly brackets skulle være noe argument mot å bruke C er jo direkte latterlig.

Heh, ja det blir jo ikke mye igjen da, for å si det sånn, C, C++, Java, Groovy, C# m.fl.

[quantum]

det er selvfølgelig en vane sak. Men hvem har lyst til å gå tilbake flere år for så å begynne på nytt.

 

det med disse klammene er at de er så like parentesene som ellers brukes i koder

i pascall språket skiller det seg såpass ut fra resten av koden.

 

det er når man bruker prosedyrer inne hverandre - som kaller seg selv man man trenger en god oversikt.

da fremstår pascal som det språket i forhold til C som det som har den leste koden å lese

 

hvis jeg sule lære meg C ( en eller annen variant ) så måtte det være Visual C som nok også har slektskap med de andre språken der man dra komponentene over på en form

 

nå er det vel ikke uten grunn at mange holder seg unna java.

hvis jeg har forstått det rett så har det en del begrensninger i for hold til mange arde programgrinespråk.

 

hvis man sammenligner java med programprinsspråket basic så har Java den begrensningen at det må kjøres på en slags virtuelt maskin som sinker utførelsen i motsetning til pascal og C som kjøre direkte på operativsystemet og er dermed raskere å utføre

 

hvis jeg lager meg et program så ønsker jeg at det ikke skal være noen somm er avhengig av en netleser ( internett ) for å fungere

det bør fungere på Windows og gjerne andre operativsystemer også

 

det var hovedgrunnene til at jeg ikke liker hverken C eller java

 

 

python er det ikke et programgrinespråk beregnet direkte for nett applikasjoner ?

 

 

når man er inne på de hvor finner jeg noen gratis -eller prøve- versjoner av disse språken med dertil-hørende eksempler og forklaringer

 

Du har en god del ting å sette deg inn i før du bestemmer deg for hvilket språk du eventuelt skal gå videre med.

 

Punkt én dreier seg om design av grensesnitt. Dette har *ingenting* med språket å gjøre, det har med oppbygningen av grensesnittbiblioteket å gjøre, og mange ganger benyttes ulike grensesnittbiblioteker på ulike plattformer. Så kommer verktøyet man bruker for å designe grensesnitt oppå der igjen. Noen foretrekker et IDE hvor man designer vha. drag'n'drop, andre foretrekker å kode mer for hånd. Dette har *enda mindre* å gjøre med hvilket språk man programmerer i.

 

Jeg forstår godt at du foretrekker Pascal fremfor C. De har ulikt bruksområde. Det er vel også jevnt over disse to språkene man reelt sett hadde å velge mellom hvis man skulle drive med applikasjonsutvikling, for en 20-30 år siden.

 

Videre; hvis du skal sammenligne Basic og Java så må du nok finne deg i å forholde deg til fakta. Basic er IKKE et kompilert språk. Veldig grovt sett kan du sammenligne en basic runtime, f.eks. slik Visual Basic fungerte opptil .NET kom, med en Java virtual machine. I .NET har man innført en virtuell maskin som ligger tettere opp til Java-varianten, men konstruert for å kunne håndtere språk med mer varierende egenskaper enn en JVM.

 

I likhet med en vanlig eksekverbar fil, blir et javaprogram, eller et .NET-program, kompilert til maskinkode. Forskjellen er at dette skjer runtime. Dette medfører riktig nok noe overhead i den tidlige fasen av eksekveringen, men ikke mye. Den store, store fordelen, er at kompilatoren alltid vet nøyaktig hvilke prosessor og instruksjonssett som er tilgjengelig og kan utnytte dette maksimalt, mens en vanlig/tradisjonell eksekverbar fil typisk vil være begrenset til instruksjonene tilgjengelig på den svakeste prosessoren i den gitte arkitekturen. Det er ikke akkurat optimalt det heller.

 

Når det gjelder portabilitet - du vil jo gjerne at programmet ditt skal kjøre på både Windows og andre OS - så har du også misforstått alt sammen. Java er pr. i dag det språket som faktisk oppfyller compile-once-run-anywhere best. Det fins nok C-kompilatorer tilgjengelig for flere av de mindre vanlige plattformene, men Java er tilgjengelig på ymse stormaskiner, Windows, Unix (Linux, BSD, OS-X) mv. Når det gjelder portabiliteten til Pascal-kode har jeg vel egentlig ingen formening om hvor landet ligger. Det fantes vel en Delphi-variant for Linux en gang i tiden, men denne er nå nedlagt svjv. Det fins andre Pascal-kompilatorer for Linux, men tviler på at disse er kildekodekompatible med Delphi. Hva med Mac? osv. osv.

 

Når det gjelder curly-braces skal jeg gi deg rett, for det er og blir en smakssak om man liker dem eller ikke. Dersom du skulle bestemme deg for et krøllebasert språk som f.eks. Java kan jeg forberede deg på at det neste store issuet blir om venstrekrøllen skal stå på slutten av en linje, eller i begynnelsen av neste. Derom strides nemlig de lærde.