mboost-dp1
Forskel på programmering og script
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Heay...
Hvad er definitionen egentlig på forskellen mellem programmering og script?
Man hører tit at sprog som C# og C++ er programmeringssprog, mens PHP bare er at scriptsprog. Men hvor går grænsen egentlig?
Hvad skal der til før et sprog bliver et programmeringssprog?
På forhånd tak...
Hvad er definitionen egentlig på forskellen mellem programmering og script?
Man hører tit at sprog som C# og C++ er programmeringssprog, mens PHP bare er at scriptsprog. Men hvor går grænsen egentlig?
Hvad skal der til før et sprog bliver et programmeringssprog?
På forhånd tak...
Problemet er bare at frameworks (læs: .NET) efterhånden så ekstensivt så man faktisk kunne lave en engine der burde kunne fortolke C# eller lign. og dermed bruge det som et scriptsprog. Når du skriver i C# bruger du 90% af tiden biblioteker(klasser), som MS har lavet, og som du, for så vidt, ikke har styr på hvad gør (med mindre du læser koden, som man jo kan nu), helt præcist... Derfor er der specielt megen diskussion på området.
#5: Java er nærmere et scriptsprog, idet det kompileres til bytekode, som principielt set er et stak assembler script. Bytekoden køres af JVM, der foretager runtimefortolkning.
I .Net er der ikke tale om runtimefortolkning, og derfor er det ikke et script sprog. Alt er kompileret, omend efter fortolkning af højniveau sprog, til et fælles underliggende sprog.
Den eneste grund til at jeg vil kalde Java et programmerings sprog, frem for et scriptsprog, er at der er et niveau imellem det skrevne kode og det kørte kode.
I .Net er der ikke tale om runtimefortolkning, og derfor er det ikke et script sprog. Alt er kompileret, omend efter fortolkning af højniveau sprog, til et fælles underliggende sprog.
Den eneste grund til at jeg vil kalde Java et programmerings sprog, frem for et scriptsprog, er at der er et niveau imellem det skrevne kode og det kørte kode.
#7: Så vidt jeg mindes har du fuldstændig ret, bortset fra at .NET ikke er et programmeringssprog men en et framework til f.eks. J#, C#, C++ m.v.. Og jo, på en MS-maskine kompileres koden jo bare til MSIL kode som så afvikles. Den eneste forskel er vel at JVM'en er en VM (Virtual Machine), hvorimod MSIL-koden skal afkodes af på anden vis, før den kommer ned til maskin-kode.
#9 J2EE er vel også et framework, der så bliver yderligere beriget af diverse leverandøre.
Hvis jeg skal kunne se en forskel, er det at JVM'en er en kørende instans, der afvikler applikationer, hvorimod .NET kører en fortolker af MSIL'en...men jeg har ikke den store kendskab til .NET, så jeg ved ikke om det er sådan det forholder sig.
Findes der ikke en applikationsserver til .NET, ligesom til java?!??
Hvis jeg skal kunne se en forskel, er det at JVM'en er en kørende instans, der afvikler applikationer, hvorimod .NET kører en fortolker af MSIL'en...men jeg har ikke den store kendskab til .NET, så jeg ved ikke om det er sådan det forholder sig.
Findes der ikke en applikationsserver til .NET, ligesom til java?!??
#7+#9
Nej, forskellen er at Java faktisk fortolker koden hele vejen igennem kørslen. F.eks. Javas HotSpot teknologi som tilpasser sig udvikling i variable etc.
Læs: http://en.wikipedia.org/wiki/HotSpot
Efter hvad jeg havde forstået, bliver .Nets bytekode bare mere eller mindre linket før det bliver kørt, men det er muligt at jeg tager fejl.
Nej, forskellen er at Java faktisk fortolker koden hele vejen igennem kørslen. F.eks. Javas HotSpot teknologi som tilpasser sig udvikling i variable etc.
Læs: http://en.wikipedia.org/wiki/HotSpot
Efter hvad jeg havde forstået, bliver .Nets bytekode bare mere eller mindre linket før det bliver kørt, men det er muligt at jeg tager fejl.
#11 Det er jeg ikke helt sikker på, uden at skulle være ekspert.
Men jeg mener at .NET også har en runtime-optimering af koden.
Hvis det skal give nogen rigtig god mening, kræver det nok, at man har appserver-tilstande, JRE'en begynder først at optimere kodestumper, når det er blevet kaldt et par hundred gange.
Men jeg mener at .NET også har en runtime-optimering af koden.
Hvis det skal give nogen rigtig god mening, kræver det nok, at man har appserver-tilstande, JRE'en begynder først at optimere kodestumper, når det er blevet kaldt et par hundred gange.
#6 og #11
Nej.
Java og .NET virker stort set paa samme maade.
En Java compiler oversaetter Java source cod etil Java byte code.
En .NET compiler oversætter C#/VB.NET/whatever til MSIL.
JVM JIT compiler Java byte code til native instruktioner.
.NET runtime JIT compiler MSIL til native instruktioner.
Der er kun ganske små forskelle:
- .NET JIT compiler så vidt jeg ved altid
- de kendte JVM JIT compiler kun hvis de mener at koden skal udfoeres mange gange og fortolker ellers
- .NET kommer med en AOT compiler ogsaa (NGEN)
Nej.
Java og .NET virker stort set paa samme maade.
En Java compiler oversaetter Java source cod etil Java byte code.
En .NET compiler oversætter C#/VB.NET/whatever til MSIL.
JVM JIT compiler Java byte code til native instruktioner.
.NET runtime JIT compiler MSIL til native instruktioner.
Der er kun ganske små forskelle:
- .NET JIT compiler så vidt jeg ved altid
- de kendte JVM JIT compiler kun hvis de mener at koden skal udfoeres mange gange og fortolker ellers
- .NET kommer med en AOT compiler ogsaa (NGEN)
#hotspot
HotSpot er en JIT compiler helt ligesom .NET's.
Eneste forskel er at den vurderer hvorvidt det overhovedet kan betale sig at JIT compile inden den gør det.
Det adaptive betyder at de har fortrydelsesret. Den kan vælge at gætte på at noget kun skal køres få gange og undlade at JIT compile det og så når den opdager at det faktisk bliver kørt mange gange JIT compile det. Det har en vis betydning for hvordan man bør lave micro-benchmarks i Java, hvis de skal være korrekte, men jeg har aldrig set effekten i praksis.
HotSpot er en JIT compiler helt ligesom .NET's.
Eneste forskel er at den vurderer hvorvidt det overhovedet kan betale sig at JIT compile inden den gør det.
Det adaptive betyder at de har fortrydelsesret. Den kan vælge at gætte på at noget kun skal køres få gange og undlade at JIT compile det og så når den opdager at det faktisk bliver kørt mange gange JIT compile det. Det har en vis betydning for hvordan man bør lave micro-benchmarks i Java, hvis de skal være korrekte, men jeg har aldrig set effekten i praksis.
#13
Ja. Alle nyere JVM har den feature. Dengang teknologien var ny kunne man i SUN's Java angive om man skulle bruge classic VM eller hotspot VM. Classic VM eksisterer slet ikke i nyere SUN JVM. Hotspot bruges som alias for client VM men brugen af navnet til angivelse af VM er deprecated.
(og det kan iøvrigt i de fleste tilfælde anbefales at bruge server VM !=
Ja. Alle nyere JVM har den feature. Dengang teknologien var ny kunne man i SUN's Java angive om man skulle bruge classic VM eller hotspot VM. Classic VM eksisterer slet ikke i nyere SUN JVM. Hotspot bruges som alias for client VM men brugen af navnet til angivelse af VM er deprecated.
(og det kan iøvrigt i de fleste tilfælde anbefales at bruge server VM !=
#1
Tilbage til det oprindelige spoergsmål.
Der kan anlægges forskellige kriterier.
Et af dem er nævnt:
compilet => programmerings sprog
fortolket => script sprog
En anden er:
statisk typed => programmerings sprog
dynamic typed => script sprog
En tredie er:
skrevet af en med IT uddannelse => programmering
skrevet af en autodidakt => scripting
Men det kan altså godt blive lidt grumset nogen gange med moderne software. Lad os tage et eksempel: EL embedded i JSP sider.
Tilbage til det oprindelige spoergsmål.
Der kan anlægges forskellige kriterier.
Et af dem er nævnt:
compilet => programmerings sprog
fortolket => script sprog
En anden er:
statisk typed => programmerings sprog
dynamic typed => script sprog
En tredie er:
skrevet af en med IT uddannelse => programmering
skrevet af en autodidakt => scripting
Men det kan altså godt blive lidt grumset nogen gange med moderne software. Lad os tage et eksempel: EL embedded i JSP sider.
#19
ASP.NET er det ekvivalente til en Java EE web container.
COM+ er det ekvivalente til en Java EE EJB container.
BizTalk svarer mere til IBM's WebSphere ESB, WebSphere Message Broker, WebSphere Business Integration etc. (IBM har et hav af produkter på det område).
SharePoint svarer mere til JSR 168 compliant portals (IBM's WebSphere Portal etc.).
ASP.NET er det ekvivalente til en Java EE web container.
COM+ er det ekvivalente til en Java EE EJB container.
BizTalk svarer mere til IBM's WebSphere ESB, WebSphere Message Broker, WebSphere Business Integration etc. (IBM har et hav af produkter på det område).
SharePoint svarer mere til JSR 168 compliant portals (IBM's WebSphere Portal etc.).
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.