mboost-dp1
Hvor går grænsen mellem scripts og et reelt program?
Scripting: Ingen kompilering, koden parses under løbetid. Den er aldrig "maskinkode". PHP, Perl, Ruby, Python, etc.
JIT (Just-In-Time compiling): Programmet "kompileres" ind i binær som kan forstås af en ... øhm, parser. Samme koncept som scripting, bare på en anden måde.
Binære executables ("Ægte" programmer): C++, C, etc.
PS. Jeg er ikke god til at forklare JIT da jeg ikke har ekspertisen til at udtale mig på området. Læs hellere om JIT på Wikipedia.
JIT (Just-In-Time compiling): Programmet "kompileres" ind i binær som kan forstås af en ... øhm, parser. Samme koncept som scripting, bare på en anden måde.
Binære executables ("Ægte" programmer): C++, C, etc.
PS. Jeg er ikke god til at forklare JIT da jeg ikke har ekspertisen til at udtale mig på området. Læs hellere om JIT på Wikipedia.
Nej, det gør den absolut ikke.
Bliver asp.net kode på noget tidspunkt lavet om til bytecode, eller er det et script som du kan læse i en text-editor?
Hvis det første er tilfældet, så er ASP.net en JIT-teknologi. Hvis det andet er tilfældet, så er asp.net en scripting-teknologi.
Og jeg er, som i tilfældet med JIT, ikke ekspert på området omkring .net og asp.net, men satser kraftigt på at ASP.net er Scripting.
Bliver asp.net kode på noget tidspunkt lavet om til bytecode, eller er det et script som du kan læse i en text-editor?
Hvis det første er tilfældet, så er ASP.net en JIT-teknologi. Hvis det andet er tilfældet, så er asp.net en scripting-teknologi.
Og jeg er, som i tilfældet med JIT, ikke ekspert på området omkring .net og asp.net, men satser kraftigt på at ASP.net er Scripting.
Citat af Peter A. Bromberg, Ph.D.
Fra: The Codebehind vs. Inline Code ASP.NET Debate
Link: http://www.eggheadcafe.com/articles/20030518.asp
"The page is parsed by the ASP.NET engine when it is first requested, and then its JIT compiled version is cached in the Temporary ASP.NET Files folder as long as the application is running and the .aspx page hasn't been changed."
Citat af Steven Kapsinow
Fra: What's Neat in ASP.NET?
Link: http://www.15seconds.com/issue/010406.htm
"When an ASP.NET page is first requested, the VB/C#/JScript gets converted to IL (Intermediate Language) by the CLR (Common Language Runtime). Then the IL is compiled into Machine code by the .NET JIT Compiler. The data is stored as a .dll file, which is used for subsequent calls to that page until the file is changed."
Jeg "snublede" lige over disse 2 sider. Det tyder på at der sker en form for kompilering af asp.net koden, eller misforstår jeg noget? (det skulle ikke være første gang ;-) )
Fra: The Codebehind vs. Inline Code ASP.NET Debate
Link: http://www.eggheadcafe.com/articles/20030518.asp
"The page is parsed by the ASP.NET engine when it is first requested, and then its JIT compiled version is cached in the Temporary ASP.NET Files folder as long as the application is running and the .aspx page hasn't been changed."
Citat af Steven Kapsinow
Fra: What's Neat in ASP.NET?
Link: http://www.15seconds.com/issue/010406.htm
"When an ASP.NET page is first requested, the VB/C#/JScript gets converted to IL (Intermediate Language) by the CLR (Common Language Runtime). Then the IL is compiled into Machine code by the .NET JIT Compiler. The data is stored as a .dll file, which is used for subsequent calls to that page until the file is changed."
Jeg "snublede" lige over disse 2 sider. Det tyder på at der sker en form for kompilering af asp.net koden, eller misforstår jeg noget? (det skulle ikke være første gang ;-) )
#6 amokk:
Der er fire 'compilations models' med ASP.NET 2.0.
# batch-compilation - alt kompileres med én (selvsagt den første) request.
# full runtime compilation - kode kompileres først ved afvikling (desværre er dette standardopsætningen).
# deployment pre-compilation (in-place compilation) - alt kompileres dvs. kilde, men også indhold af ASPX-filer. Filerne eksisterer dog stadig, men kun som tomme pointers (for at undgå fejl 404, forståes).
# normal - identisk med modellen fra ASP.NET 1.x, hvor kode kompileres til eget assembly, og hvor ASPX-filerne kompileres ved afvikling (første request er langsom).
Med deployment pre-compilation kompileres det hele til de filer, der ellers vil gemmes i 'Temporary ASP.NET Files', og det er så vidt jeg husker outputtet _efter_ JIT-kompileringen (dvs. maskinkode).
Det andet gemmes også som maskinkode, men når det sker ved den første request på hele sitet eller den første request på den enkelte side, så kan man diskutere, hvorvidt der er tale om en fortolkning.
Jeg vil dog ikke mene, at ASP.NET er ren scripting. Det er som alt andet JIT-kompileret en mellemting imellem det ægte og det, der skal fortolkes.
Der er fire 'compilations models' med ASP.NET 2.0.
# batch-compilation - alt kompileres med én (selvsagt den første) request.
# full runtime compilation - kode kompileres først ved afvikling (desværre er dette standardopsætningen).
# deployment pre-compilation (in-place compilation) - alt kompileres dvs. kilde, men også indhold af ASPX-filer. Filerne eksisterer dog stadig, men kun som tomme pointers (for at undgå fejl 404, forståes).
# normal - identisk med modellen fra ASP.NET 1.x, hvor kode kompileres til eget assembly, og hvor ASPX-filerne kompileres ved afvikling (første request er langsom).
Med deployment pre-compilation kompileres det hele til de filer, der ellers vil gemmes i 'Temporary ASP.NET Files', og det er så vidt jeg husker outputtet _efter_ JIT-kompileringen (dvs. maskinkode).
Det andet gemmes også som maskinkode, men når det sker ved den første request på hele sitet eller den første request på den enkelte side, så kan man diskutere, hvorvidt der er tale om en fortolkning.
Jeg vil dog ikke mene, at ASP.NET er ren scripting. Det er som alt andet JIT-kompileret en mellemting imellem det ægte og det, der skal fortolkes.
#7
Sådan som du forklarer det, så er asp.net rent JIT, eller kan i hvert fald klaccificeres i en gruppe sammen med Java, da det aldrig er selve koden som parses og giver output fra parseren - men kode som først bliver til bytecode og derefter bliver konverteret til maskinkode på et andet tidspunkt.
Sådan som du forklarer det, så er asp.net rent JIT, eller kan i hvert fald klaccificeres i en gruppe sammen med Java, da det aldrig er selve koden som parses og giver output fra parseren - men kode som først bliver til bytecode og derefter bliver konverteret til maskinkode på et andet tidspunkt.
#8 hvad faen kalder man så sådan noget som perl hvor parseren kompiler det hele til en exe fil inden den eksekvere koden, det må vel næsten gøre at perl er et JIT sprog, man kunne engang tilogmed kompilere perl direkte til maskin kode.
Python er et andet scripsprog der ofte på run time opføre sig som noget andet, der er f.eks. jpython der kompilere python til java bytecode, hvilket vel er JIT kompilering.
Og hvis man på den måde kan klassificere perl og python uden for kategorien af scrips, tjaa så har man et problem med sin definition, og lisp en af de gamle arbejdsheste inden for meget komplekse systemer er ofte eksekveret som et scripsprog.
En anden måde at definere scripts på er relativt små programmer skrævet i et sporg hvor man distribuere sourcekode og ikke prekompilerede binære filer.
Python er et andet scripsprog der ofte på run time opføre sig som noget andet, der er f.eks. jpython der kompilere python til java bytecode, hvilket vel er JIT kompilering.
Og hvis man på den måde kan klassificere perl og python uden for kategorien af scrips, tjaa så har man et problem med sin definition, og lisp en af de gamle arbejdsheste inden for meget komplekse systemer er ofte eksekveret som et scripsprog.
En anden måde at definere scripts på er relativt små programmer skrævet i et sporg hvor man distribuere sourcekode og ikke prekompilerede binære filer.
#9
okay, hvad er "relativt små programmer", da jeg har set batch scripts på omkring 100kb, og det er scrips. Er alle programmer under 100kb som man får sourcekode med til så scripts.. ? for så er hovedparten af *nix core utils lige blevet ændret fra programmer til scripts.
En anden måde at definere scripts på er relativt små programmer skrævet i et sporg hvor man distribuere sourcekode og ikke prekompilerede binære filer.
okay, hvad er "relativt små programmer", da jeg har set batch scripts på omkring 100kb, og det er scrips. Er alle programmer under 100kb som man får sourcekode med til så scripts.. ? for så er hovedparten af *nix core utils lige blevet ændret fra programmer til scripts.
#9 de ting jeg har rodet med i perl er nu ikke blevet compilet til exe filer?
Hvis du kører perl på en windows, er det rigtigt at du er nødt til at udføre scripts igennem perl.exe men det er stadig scripts
så vidt jeg ved er python-kode endnu mere script-agtigt, da man endda kan ændre i scriptet under udførsel, og herefter vil udførslen forløbe anderledes...
Hvis du kører perl på en windows, er det rigtigt at du er nødt til at udføre scripts igennem perl.exe men det er stadig scripts
så vidt jeg ved er python-kode endnu mere script-agtigt, da man endda kan ændre i scriptet under udførsel, og herefter vil udførslen forløbe anderledes...
#11: Nej ikke nødvendigvis.. men du kan godt kompilere perl til exe
http://www.indigostar.com/perl2exe.htm
http://www.indigostar.com/perl2exe.htm
#12
Ja, man kan. Men det gør ikke Perl til et JIT sprog.
Man kan også lave PHP om til maskinkode, men derfor er PHP stadigvæk et scriptsprog.
Man kan også, i teorien, eksekvere C programmer fra kildekoden ved at lave en C-parser, men derfor er C stadigvæk et "ægte" programmeringssprog.
Ja, man kan. Men det gør ikke Perl til et JIT sprog.
Man kan også lave PHP om til maskinkode, men derfor er PHP stadigvæk et scriptsprog.
Man kan også, i teorien, eksekvere C programmer fra kildekoden ved at lave en C-parser, men derfor er C stadigvæk et "ægte" programmeringssprog.
#11 #12 perl kompilere altid til exe før eksekveringen af et perl script nårmalt lagres filen ikke efter ekesekveringen men...
#13 Du er vel ved at værre ude i noget fordi... fordi argumentering, når C er et programerings selv hvis det ekeskveres via en parser og Python altid producere scrips selv når det kompileres til maskin kode.
For hvad kan gøre perl til et JIT sprog og C til at scriptsprog?
Et sprog som lisp smider også grus i definitionerne, lisp er parset, lisp programmer kan modificeres mens programmet kører og alligevel er lisp aplikationer traditionelt ikke scrips fordi de tradinelt er mere komplekse end det gennemsnitslige.
Og her er problemet måske nok scripting parsere, scripting sprog og scripts reffere ikke til helt samme ting.
Både perl python og lisp kan parses både af scripting parsere og kompilere, der fandtes hardware der havde lisp som maskinkode, og sprog som java kan både fungere via JIT, men også som traditionelt kompileret sprog via GCC, så definitionen kan simpelt hen ikke værre så simpel som at perl==script JAVA=="noget andet"
Script har også ofte haft en biklang af noget der er lidt mindre end rigtige programmer, men ser man på sprognes realle brug, tjaa er RRM(skrevet i perl) mindre et program end DKPG(der kan mindre og er skrevet i C++) ja måske men så mister script vel sin betydning af at værre mindre værd og mere trivielt end et program.
#13 Du er vel ved at værre ude i noget fordi... fordi argumentering, når C er et programerings selv hvis det ekeskveres via en parser og Python altid producere scrips selv når det kompileres til maskin kode.
For hvad kan gøre perl til et JIT sprog og C til at scriptsprog?
Et sprog som lisp smider også grus i definitionerne, lisp er parset, lisp programmer kan modificeres mens programmet kører og alligevel er lisp aplikationer traditionelt ikke scrips fordi de tradinelt er mere komplekse end det gennemsnitslige.
Og her er problemet måske nok scripting parsere, scripting sprog og scripts reffere ikke til helt samme ting.
Både perl python og lisp kan parses både af scripting parsere og kompilere, der fandtes hardware der havde lisp som maskinkode, og sprog som java kan både fungere via JIT, men også som traditionelt kompileret sprog via GCC, så definitionen kan simpelt hen ikke værre så simpel som at perl==script JAVA=="noget andet"
Script har også ofte haft en biklang af noget der er lidt mindre end rigtige programmer, men ser man på sprognes realle brug, tjaa er RRM(skrevet i perl) mindre et program end DKPG(der kan mindre og er skrevet i C++) ja måske men så mister script vel sin betydning af at værre mindre værd og mere trivielt end et program.
Blot for at være besværlig, så er et programeringssprog jo et sprog der gør det muligt at få en computer til at udføre en række instruktioner, hvilket sådan set alt fra ASM til MS Makro fint kan håndtere.
Så i stedet for at opdele i script-sprog osv. burde man måske kigge på hvad sproget er designet til (ingen skriver en bootloader i PHP) og inddele dem efter det? Nogle af sprogene kan findes i flere kategorier, mens andre kun findes i en. Meget simpelt.
Om det compiles inden og gemmes i binært, bytecode eller noget helt tredie er vel ligegyldigt? CPU'en ser alligevel aldrig andet end maskine/mikrokoden, og kan derfor reelt ikke se nogen forskel om det lige er blevet compilet, eller om det skete i 1982.
Så i stedet for at opdele i script-sprog osv. burde man måske kigge på hvad sproget er designet til (ingen skriver en bootloader i PHP) og inddele dem efter det? Nogle af sprogene kan findes i flere kategorier, mens andre kun findes i en. Meget simpelt.
Om det compiles inden og gemmes i binært, bytecode eller noget helt tredie er vel ligegyldigt? CPU'en ser alligevel aldrig andet end maskine/mikrokoden, og kan derfor reelt ikke se nogen forskel om det lige er blevet compilet, eller om det skete i 1982.
DUdsen,
nej nej nej NEJ!
Forskellen mellem "scriptsprog" og "programmeringssprog" er ABSOLUT IKKE størrelsen på selve det resultat som programmøren producerer.
Det handler IKKE om hvor mange funktioner eller hvor mange linier koder der er, men om at det er to forskellige teknologier der snakkes om når vi snakker JIT og scripting.
nej nej nej NEJ!
Forskellen mellem "scriptsprog" og "programmeringssprog" er ABSOLUT IKKE størrelsen på selve det resultat som programmøren producerer.
Det handler IKKE om hvor mange funktioner eller hvor mange linier koder der er, men om at det er to forskellige teknologier der snakkes om når vi snakker JIT og scripting.
#18 igen så kan python både værre JIT-sprog og scriptsprog, perl kan både værre kompileret kode og scriptsprog, java både kompileret og JIT-sprog, og så er der the lisp machine hvor et scrips bliver til maskin kode.
Altså hele definitionen afhænger af hvilket miljø der på et specifikt tidspunkt afvikler koden.
Og det er din meget abstrakte meget teoretiske definition der fratager begrebet script enhver betydning ud over brug af kode parser parset frem for anden eksekverings teknologi, hvilket i teorien gør 90% af windows VII til et script når det engang kommer med de sprecifikationer VIsta burde have haft!
Det er korekt at scrips altid er parsed kode men giver det ikke meget lidt mening at skeldne mellem scripts og programmer når vi snart ikke finder andet end perset kode uden for kernel space.
Og du er iøvrigt den første jeg har mødt de bruger scripts i den definition, der er teknisk korekt men IMHO sprogligt ukorekt for ordet script bruges meget mere begrenset i daglig tale.
Altså hele definitionen afhænger af hvilket miljø der på et specifikt tidspunkt afvikler koden.
Og det er din meget abstrakte meget teoretiske definition der fratager begrebet script enhver betydning ud over brug af kode parser parset frem for anden eksekverings teknologi, hvilket i teorien gør 90% af windows VII til et script når det engang kommer med de sprecifikationer VIsta burde have haft!
Det er korekt at scrips altid er parsed kode men giver det ikke meget lidt mening at skeldne mellem scripts og programmer når vi snart ikke finder andet end perset kode uden for kernel space.
Og du er iøvrigt den første jeg har mødt de bruger scripts i den definition, der er teknisk korekt men IMHO sprogligt ukorekt for ordet script bruges meget mere begrenset i daglig tale.
Jamen hvorfor være så utroligt pedantiske og gå ned i alle detaljer, når det bare kan gøres meget simplet og straks afgøres at:
PHP, Perl og Ruby er interpreted scripting languages fordi deres primære brug er at de bliver interpreted gennem en parser.
C# og andre .net sprog samt Java er Just-In-Time compiled languages, der oftest kompileres til bytecode og derefter skal benytte en virtual machine til at afvikles på det enkelte system.
C++, C, mm. er "ægte" programmeringssprog som skal kompileres til maskinkode så de kan afvikles på det enkelte system, altså på den enkelte CPU arkitektur og det miljø hvor de skal benyttes.
Alt andet er vilde påstande om mulige - men sjældne - tilfælde.
PHP, Perl og Ruby er interpreted scripting languages fordi deres primære brug er at de bliver interpreted gennem en parser.
C# og andre .net sprog samt Java er Just-In-Time compiled languages, der oftest kompileres til bytecode og derefter skal benytte en virtual machine til at afvikles på det enkelte system.
C++, C, mm. er "ægte" programmeringssprog som skal kompileres til maskinkode så de kan afvikles på det enkelte system, altså på den enkelte CPU arkitektur og det miljø hvor de skal benyttes.
Alt andet er vilde påstande om mulige - men sjældne - tilfælde.
#20 Lisp er ikke i brug så ofte, mere, men de komersielle IDE'er understøtter som regel både script-mode og kopmpilering til exe, lisp er interesant fordi det har været implementeret så mange forskellige steder.
perl parseren er som jeg har nævnt, faktisk en mellemting mellem en jit kompiler og en rigtig kompiler, altså parseren eksekvere ikke bare scriptet men omdanner det til objekt kode, og svjv i sidste fase til exe.
Når man begynder at fodre en .net parser med C# kode og den så selv kompilere til bytecode, ligner det altså perl's arkitektur mere end java.
iøvrigt er min avasion mere at du sætter script == med script sprog, og program lig med gammeldags prekompilering, som man ser mindre og mindre uden for kernel space, der er for meget virkeligt kompliceret kode der er scrips og ikke programmer efter din definition, hviket betyder at script's og prgram i praktisk kommer til at miste deres særpræg.
forestil dig at skulle kalde et kompelt first person shooter spil for et script fordi det nu er skrevet i python, og dermed ikke er prekompileret.
BTW perl kompiler http://www.activestate.com/Products/Perl_Dev_Kit/ python til java http://www.jython.org/Project/index.html, det er ikke vilde teoretiske take elsprimenter værktøjerne har været her længe.
http://www.jython.org/Project/index.html spil udvikling med python.
For 10år siden var den slags bleading edge programmer, som, man ikke kunne finde på at kalde for et script, men det kører parsed!
Som det måske også er antydet så er script parsere, ofte forklædte JIT-kompilere, ellers opnår man ikke den performance vi kræver af dem, jeg kigger lige lidt efter lidt doc på php parseren og kommer tilbage med en melding på om den også bruger bytecode internt.
perl parseren er som jeg har nævnt, faktisk en mellemting mellem en jit kompiler og en rigtig kompiler, altså parseren eksekvere ikke bare scriptet men omdanner det til objekt kode, og svjv i sidste fase til exe.
Når man begynder at fodre en .net parser med C# kode og den så selv kompilere til bytecode, ligner det altså perl's arkitektur mere end java.
iøvrigt er min avasion mere at du sætter script == med script sprog, og program lig med gammeldags prekompilering, som man ser mindre og mindre uden for kernel space, der er for meget virkeligt kompliceret kode der er scrips og ikke programmer efter din definition, hviket betyder at script's og prgram i praktisk kommer til at miste deres særpræg.
forestil dig at skulle kalde et kompelt first person shooter spil for et script fordi det nu er skrevet i python, og dermed ikke er prekompileret.
BTW perl kompiler http://www.activestate.com/Products/Perl_Dev_Kit/ python til java http://www.jython.org/Project/index.html, det er ikke vilde teoretiske take elsprimenter værktøjerne har været her længe.
http://www.jython.org/Project/index.html spil udvikling med python.
For 10år siden var den slags bleading edge programmer, som, man ikke kunne finde på at kalde for et script, men det kører parsed!
Som det måske også er antydet så er script parsere, ofte forklædte JIT-kompilere, ellers opnår man ikke den performance vi kræver af dem, jeg kigger lige lidt efter lidt doc på php parseren og kommer tilbage med en melding på om den også bruger bytecode internt.
#21 DUdsen:
C#-kode kompileres til MSIL _inden_ afvikling. Du tror da vel ikke, at du kan downloade en .NET-applikation og se kilden? MSIL kompileres til maskinkode ved afvikling (dvs. JIT), og man kan, som jeg nævnte tidligere, også springe det led over, så man fra starten får det resultat, som man normalt først står med efter JIT-kompileringen.
C#-kode kompileres til MSIL _inden_ afvikling. Du tror da vel ikke, at du kan downloade en .NET-applikation og se kilden? MSIL kompileres til maskinkode ved afvikling (dvs. JIT), og man kan, som jeg nævnte tidligere, også springe det led over, så man fra starten får det resultat, som man normalt først står med efter JIT-kompileringen.
#23 Jo det er det samme med MSIL. Man kan sagtens decompile en .NET *.exe eller *.dll-fil med tools som Salamander.
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.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund