How not to Design a Scripting Language Department of Computer - - PowerPoint PPT Presentation

▶
how not to design a scripting language
SMART_READER_LITE
LIVE PREVIEW

How not to Design a Scripting Language Department of Computer - - PowerPoint PPT Presentation

Jan 14, 2024 264 likes •738 views

How not to Design a Scripting Language Paul Biggar How not to Design a Scripting Language Department of Computer Science and Statistics Trinity College Dublin StackOverflow London, 28th October, 2009 Paul Biggar Department of Computer Science

slide-1
SLIDE 1

How not to Design a Scripting Language

Paul Biggar

Department of Computer Science and Statistics Trinity College Dublin

StackOverflow London, 28th October, 2009

How not to Design a Scripting Language Paul Biggar

How not to Design a Scripting Language

Paul Biggar

Department of Computer Science and Statistics Trinity College Dublin

StackOverflow London, 28th October, 2009

slide-2
SLIDE 2

About me

  • PhD candidate, Trinity College Dublin
  • Topic: Compilers, optimizations, scripting languages.

How not to Design a Scripting Language Paul Biggar

  • 1. means I just

submitted

  • 2. So that’s what this

talk is about

About me

  • PhD candidate, Trinity College Dublin
  • Topic: Compilers, optimizations, scripting languages.
slide-3
SLIDE 3

About me

  • PhD candidate, Trinity College Dublin
  • Topic: Compilers, optimizations, scripting languages.

PhD Dissertation

Design and Implementation of an Ahead-of-time PHP Compiler phc (http://phpcompiler.org)

How not to Design a Scripting Language Paul Biggar

  • 1. means I just

submitted

  • 2. So that’s what this

talk is about

  • 3. Not much PHP

About me

  • PhD candidate, Trinity College Dublin
  • Topic: Compilers, optimizations, scripting languages.

PhD Dissertation

Design and Implementation of an Ahead-of-time PHP Compiler phc (http://phpcompiler.org)

slide-4
SLIDE 4

How not to design a scripting language

  • Compilers
  • Scripting Languages

How not to Design a Scripting Language Paul Biggar

  • 1. really, this is a talk

about compilers and scripting languages

How not to design a scripting language

  • Compilers
  • Scripting Languages
slide-5
SLIDE 5

How not to design a scripting language

  • Compilers
  • Scripting Languages
  • Speed

How not to Design a Scripting Language Paul Biggar

  • 1. Thats whats in the

back of my head all the time

How not to design a scripting language

  • Compilers
  • Scripting Languages
  • Speed
slide-6
SLIDE 6

What is a scripting language?

  • Javascript
  • Lua
  • Perl
  • PHP
  • Python
  • Ruby

How not to Design a Scripting Language Paul Biggar

  • 1. well, no-one

actually has a good definition of scripting language!

  • 2. I’m not talking

about Bash or Powershell or VB,

  • r some little

language you wrote last week

What is a scripting language?

  • Javascript
  • Lua
  • Perl
  • PHP
  • Python
  • Ruby
slide-7
SLIDE 7

What is a scripting language?

  • Javascript
  • Lua
  • Perl
  • PHP
  • Python
  • Ruby

Common Features:

  • Dynamic typing
  • Duck typing
  • Interpreted by default
  • FFI via C API

How not to Design a Scripting Language Paul Biggar

  • 1. well, no-one

actually has a good definition of scripting language!

  • 2. I’m not talking

about Bash or Powershell or VB,

  • r some little

language you wrote last week

  • 3. exposing their

internals

What is a scripting language?

  • Javascript
  • Lua
  • Perl
  • PHP
  • Python
  • Ruby

Common Features:

  • Dynamic typing
  • Duck typing
  • Interpreted by default
  • FFI via C API
slide-8
SLIDE 8

Language implementation

  • Interpreters: Easy, portable

How not to Design a Scripting Language Paul Biggar

  • 1. Reads one line at

a time (kinda)

  • 2. hence used in

many scripting langs

Language implementation

  • Interpreters: Easy, portable
slide-9
SLIDE 9

Language implementation

  • Interpreters: Easy, portable
  • Compilers: Not too hard, sometimes portable,
  • ptimizations

How not to Design a Scripting Language Paul Biggar

  • 1. Converts source

code into machine code programs (kinda)

  • 2. Lots of time to
  • ptimize

Language implementation

  • Interpreters: Easy, portable
  • Compilers: Not too hard, sometimes portable,
  • ptimizations
slide-10
SLIDE 10

Language implementation

  • Interpreters: Easy, portable
  • Compilers: Not too hard, sometimes portable,
  • ptimizations

NOT THE DRAGON BOOK

Engineering a Compiler by Cooper/Torczon Modern Compiler Implementation in X by Appel

How not to Design a Scripting Language Paul Biggar

  • 1. 2 months, Joel,

Dragon

  • 2. For intermediate

and advanced, there are also much better books

Language implementation

  • Interpreters: Easy, portable
  • Compilers: Not too hard, sometimes portable,
  • ptimizations

NOT THE DRAGON BOOK

Engineering a Compiler by Cooper/Torczon Modern Compiler Implementation in X by Appel

slide-11
SLIDE 11

Language implementation

  • Interpreters: Easy, portable
  • Compilers: Not too hard, sometimes portable,
  • ptimizations
  • Just-in-time compilers: Very difficult, unportable, fast

interpreter.

How not to Design a Scripting Language Paul Biggar

  • 1. Amazing
  • ptimizations;

Hotspot; dispatch, exceptions and arithmetic

  • 2. Shockingly difficult

to write

Language implementation

  • Interpreters: Easy, portable
  • Compilers: Not too hard, sometimes portable,
  • ptimizations
  • Just-in-time compilers: Very difficult, unportable, fast

interpreter.

slide-12
SLIDE 12

What’s right with scripting languages?

How not to Design a Scripting Language Paul Biggar

  • 1. dont dwell here -

I’m not here to convince you

  • 2. the bad things dont

touch these

What’s right with scripting languages?

slide-13
SLIDE 13

What’s right with scripting languages?

1 Elegant and well designed,

How not to Design a Scripting Language Paul Biggar

  • 1. dont dwell here -

I’m not here to convince you

  • 2. the bad things dont

touch these

  • 3. Python, Ruby; JS

too in a certain way

What’s right with scripting languages?

1 Elegant and well designed,

slide-14
SLIDE 14

What’s right with scripting languages?

1 Elegant and well designed, 2 High level of abstraction,

How not to Design a Scripting Language Paul Biggar

  • 1. dont dwell here -

I’m not here to convince you

  • 2. the bad things dont

touch these

  • 3. get things done, as

Joel would say

What’s right with scripting languages?

1 Elegant and well designed, 2 High level of abstraction,

slide-15
SLIDE 15

What’s right with scripting languages?

1 Elegant and well designed, 2 High level of abstraction, 3 Dynamic typing (and duck typing).

How not to Design a Scripting Language Paul Biggar

  • 1. dont dwell here -

I’m not here to convince you

  • 2. the bad things dont

touch these

  • 3. avoids many

problems inherent in Java, C# and C++: verbosity, type systems

What’s right with scripting languages?

1 Elegant and well designed, 2 High level of abstraction, 3 Dynamic typing (and duck typing).

slide-16
SLIDE 16

What’s wrong with scripting languages?

Symptoms: Speed, Portability

How not to Design a Scripting Language Paul Biggar

  • 1. portable to .Net,

JVM, etc?

  • 2. not fast means you

cant use it as much

What’s wrong with scripting languages?

Symptoms: Speed, Portability

slide-17
SLIDE 17

What’s wrong with scripting languages?

Symptoms: Speed, Portability Problem: Language designed for interpreters

  • Run-time source code execution

How not to Design a Scripting Language Paul Biggar

  • 1. portable to .Net,

JVM, etc?

  • 2. not fast means you

cant use it as much

What’s wrong with scripting languages?

Symptoms: Speed, Portability Problem: Language designed for interpreters

  • Run-time source code execution
slide-18
SLIDE 18

What’s wrong with scripting languages?

Symptoms: Speed, Portability Problem: Language designed for one specific interpreter

  • Run-time source code execution
  • Foreign Function Interface

How not to Design a Scripting Language Paul Biggar

  • 1. portable to .Net,

JVM, etc?

  • 2. not fast means you

cant use it as much

What’s wrong with scripting languages?

Symptoms: Speed, Portability Problem: Language designed for one specific interpreter

  • Run-time source code execution
  • Foreign Function Interface
slide-19
SLIDE 19

FFI

FFI

Foreign Function Interface based on CPython interpreter

  • Access to C libraries
  • Script C applications using Python scripts
  • Rewrite hot code in C

How not to Design a Scripting Language Paul Biggar

  • 1. define FFI
  • 2. glue code in C;

wrap things in python data structures; expose interpreter internals

  • 3. Works for all

except JS - I’m using Python as example

FFI

Foreign Function Interface based on CPython interpreter

  • Access to C libraries
  • Script C applications using Python scripts
  • Rewrite hot code in C
slide-20
SLIDE 20

FFI

FFI (good) implications

  • Libraries not that slow
  • Can break out of Python for slow code.

How not to Design a Scripting Language Paul Biggar

FFI (good) implications

  • Libraries not that slow
  • Can break out of Python for slow code.
slide-21
SLIDE 21

FFI

FFI (bad) implications

  • Language is allowed to be slow
  • Must break out of Python for speed.

How not to Design a Scripting Language Paul Biggar

  • 1. nice things about

python are lost (high level, elegant

FFI (bad) implications

  • Language is allowed to be slow
  • Must break out of Python for speed.
slide-22
SLIDE 22

FFI

FFI (worse) implications

  • Legacy issues

How not to Design a Scripting Language Paul Biggar

  • 1. you cant change

the interpreter much - it cant get faster

FFI (worse) implications

  • Legacy issues
slide-23
SLIDE 23

FFI

FFI (worse) implications

  • Legacy issues
  • Reimplementations

How not to Design a Scripting Language Paul Biggar

  • 1. Jython,

IronPython, PyPy, cant use the same code

  • 2. cant even

reimplement own language

  • 3. by constrast, look

at JS

FFI (worse) implications

  • Legacy issues
  • Reimplementations
slide-24
SLIDE 24

FFI

FFI solution

Don’t expose yourself!

  • Importing functions into Python with a Domain Specific

Language is good

How not to Design a Scripting Language Paul Biggar

  • 1. rule for life, really
  • 2. like pyrex, ctypes,

etc

  • 3. no implementation

specific code at all

  • 4. import functions

directly, and access them from within Python without a line of C

  • 5. Ruby libFFI

FFI solution

Don’t expose yourself!

  • Importing functions into Python with a Domain Specific

Language is good

slide-25
SLIDE 25

FFI

FFI solution

Don’t expose yourself!

  • Importing functions into Python with a Domain Specific

Language is good

  • Only one way of FFI is better

How not to Design a Scripting Language Paul Biggar

  • 1. rule for life, really
  • 2. like pyrex, ctypes,

etc

  • 3. for

reimplementation

  • 4. no implementation

specific code at all

  • 5. import functions

directly, and access them from within Python without a line of C

  • 6. Ruby libFFI

FFI solution

Don’t expose yourself!

  • Importing functions into Python with a Domain Specific

Language is good

  • Only one way of FFI is better
slide-26
SLIDE 26

FFI

FFI solution

Don’t expose yourself!

  • Importing functions into Python with a Domain Specific

Language is good

  • Only one way of FFI is better
  • Declarative is best

How not to Design a Scripting Language Paul Biggar

  • 1. rule for life, really
  • 2. like pyrex, ctypes,

etc

  • 3. no implementation

specific code at all

  • 4. import functions

directly, and access them from within Python without a line of C

  • 5. Ruby libFFI

FFI solution

Don’t expose yourself!

  • Importing functions into Python with a Domain Specific

Language is good

  • Only one way of FFI is better
  • Declarative is best
slide-27
SLIDE 27

FFI

FFI solution

Don’t expose yourself!

  • Importing functions into Python with a Domain Specific

Language is good

  • Only one way of FFI is better
  • Declarative is best
  • Any reimplementation can reuse the same libraries without

any modifications

  • CPython itself can change without hassle

How not to Design a Scripting Language Paul Biggar

  • 1. rule for life, really
  • 2. like pyrex, ctypes,

etc

  • 3. no implementation

specific code at all

  • 4. import functions

directly, and access them from within Python without a line of C

  • 5. Ruby libFFI

FFI solution

Don’t expose yourself!

  • Importing functions into Python with a Domain Specific

Language is good

  • Only one way of FFI is better
  • Declarative is best
  • Any reimplementation can reuse the same libraries without

any modifications

  • CPython itself can change without hassle
slide-28
SLIDE 28

Compiled and interpreted models

Dynamic source code generation

  • eval and dynamic include/import

How not to Design a Scripting Language Paul Biggar

  • 1. Should be used for

source inclusion. But because they’re interpreted, they can be used for:

Dynamic source code generation

  • eval and dynamic include/import
slide-29
SLIDE 29

Compiled and interpreted models

Dynamic source code generation

  • eval and dynamic include/import
  • meta-programming

eval (mysql_read (...)[0]);

How not to Design a Scripting Language Paul Biggar

  • 1. Should be used for

source inclusion. But because they’re interpreted, they can be used for:

Dynamic source code generation

  • eval and dynamic include/import
  • meta-programming

eval (mysql_read (...)[0]);

slide-30
SLIDE 30

Compiled and interpreted models

Dynamic source code generation

  • eval and dynamic include/import
  • meta-programming
  • .rc files

username = "myname" password = "mypass" server = "srv.domain.com"

How not to Design a Scripting Language Paul Biggar

  • 1. Should be used for

source inclusion. But because they’re interpreted, they can be used for:

Dynamic source code generation

  • eval and dynamic include/import
  • meta-programming
  • .rc files

username = "myname" password = "mypass" server = "srv.domain.com"

slide-31
SLIDE 31

Compiled and interpreted models

Dynamic source code generation

  • eval and dynamic include/import
  • meta-programming
  • .rc files
  • localization

$lang = ....; include ("localisation/locale.$lang.php");

How not to Design a Scripting Language Paul Biggar

  • 1. Should be used for

source inclusion. But because they’re interpreted, they can be used for:

Dynamic source code generation

  • eval and dynamic include/import
  • meta-programming
  • .rc files
  • localization

$lang = ....; include ("localisation/locale.$lang.php");

slide-32
SLIDE 32

Compiled and interpreted models

Dynamic source code generation

We don’t even know the full program source!!

How not to Design a Scripting Language Paul Biggar

  • 1. go to next slide

straight away

Dynamic source code generation

We don’t even know the full program source!!

slide-33
SLIDE 33

Compiled and interpreted models

So they can’t be compiled (ahead-of-time)

Downsides:

  • Must use FFI for speed
  • Static analysis
  • Cool optimizations can’t happen

How not to Design a Scripting Language Paul Biggar

  • 1. self-perpetuating

cycle

  • 2. shame, scripting

languages could really use static analysis

  • 3. high-level means

high level

  • ptimizations? no
  • 4. redundency

elimination - some cant be done by hand

So they can’t be compiled (ahead-of-time)

Downsides:

  • Must use FFI for speed
  • Static analysis
  • Cool optimizations can’t happen
slide-34
SLIDE 34

Compiled and interpreted models

So they can’t be compiled (ahead-of-time)

Downsides:

  • Must use FFI for speed
  • Static analysis
  • Cool optimizations can’t happen

t = ...; for (i = 0; i < strlen(t); i++) { s[i] = t[i]; }

How not to Design a Scripting Language Paul Biggar

  • 1. self-perpetuating

cycle

  • 2. shame, scripting

languages could really use static analysis

  • 3. high-level means

high level

  • ptimizations? no
  • 4. redundency

elimination - some cant be done by hand

So they can’t be compiled (ahead-of-time)

Downsides:

  • Must use FFI for speed
  • Static analysis
  • Cool optimizations can’t happen

t = ...; for (i = 0; i < strlen(t); i++) { s[i] = t[i]; }

slide-35
SLIDE 35

Compiled and interpreted models

So they can’t be compiled (ahead-of-time)

Downsides:

  • Must use FFI for speed
  • Static analysis
  • Cool optimizations can’t happen

t = ...; _temp = strlen(t); for (i = 0; i < _temp; i++) { s[i] = t[i]; }

How not to Design a Scripting Language Paul Biggar

  • 1. self-perpetuating

cycle

  • 2. shame, scripting

languages could really use static analysis

  • 3. high-level means

high level

  • ptimizations? no
  • 4. redundency

elimination - some cant be done by hand

So they can’t be compiled (ahead-of-time)

Downsides:

  • Must use FFI for speed
  • Static analysis
  • Cool optimizations can’t happen

t = ...; _temp = strlen(t); for (i = 0; i < _temp; i++) { s[i] = t[i]; }

slide-36
SLIDE 36

Compiled and interpreted models

So they can’t be compiled (ahead-of-time)

Downsides:

  • Must use FFI for speed
  • Static analysis
  • Cool optimizations can’t happen

alert ($(’li’).get(0).nodeName);

How not to Design a Scripting Language Paul Biggar

  • 1. self-perpetuating

cycle

  • 2. shame, scripting

languages could really use static analysis

  • 3. high-level means

high level

  • ptimizations? no
  • 4. redundency

elimination - some cant be done by hand

So they can’t be compiled (ahead-of-time)

Downsides:

  • Must use FFI for speed
  • Static analysis
  • Cool optimizations can’t happen

alert ($(’li’).get(0).nodeName);

slide-37
SLIDE 37

Compiled and interpreted models

So they can’t be compiled (ahead-of-time)

Downsides:

  • Must use FFI for speed
  • Static analysis
  • Cool optimizations can’t happen

alert ($(’li’)[0].nodeName);

How not to Design a Scripting Language Paul Biggar

  • 1. self-perpetuating

cycle

  • 2. shame, scripting

languages could really use static analysis

  • 3. high-level means

high level

  • ptimizations? no
  • 4. redundency

elimination - some cant be done by hand

So they can’t be compiled (ahead-of-time)

Downsides:

  • Must use FFI for speed
  • Static analysis
  • Cool optimizations can’t happen

alert ($(’li’)[0].nodeName);

slide-38
SLIDE 38

Compiled and interpreted models

JIT compiled

Tracemonkey

http://hacks.mozilla.org/2009/07/tracemonkey-overview/

How not to Design a Scripting Language Paul Biggar

  • 1. instead, they must

be JIT compiled. We’ll still never get cool optimizations

  • 2. worse, the

research just gets us, at run-time, expensively, information we could get at compile-time.

JIT compiled

Tracemonkey

http://hacks.mozilla.org/2009/07/tracemonkey-overview/

slide-39
SLIDE 39

Compiled and interpreted models

JIT compiled

Tracemonkey

http://hacks.mozilla.org/2009/07/tracemonkey-overview/

Type Analysis for Javascript

Simon Holm Jensen, Anders Møller and Peter Thiemann SAS ’09 http://www.brics.dk/TAJS/

How not to Design a Scripting Language Paul Biggar

  • 1. instead, they must

be JIT compiled. We’ll still never get cool optimizations

  • 2. worse, the

research just gets us, at run-time, expensively, information we could get at compile-time.

JIT compiled

Tracemonkey

http://hacks.mozilla.org/2009/07/tracemonkey-overview/

Type Analysis for Javascript

Simon Holm Jensen, Anders Møller and Peter Thiemann SAS ’09 http://www.brics.dk/TAJS/

slide-40
SLIDE 40

Compiled and interpreted models

Fix at language design time

  • No dynamic include; no eval.
  • Compile-time meta-programming

How not to Design a Scripting Language Paul Biggar

  • 1. do it like Perl, or

C++

Fix at language design time

  • No dynamic include; no eval.
  • Compile-time meta-programming
slide-41
SLIDE 41

Compiled and interpreted models

Fix at language design time

  • No dynamic include; no eval.
  • Compile-time meta-programming
  • .rc files

How not to Design a Scripting Language Paul Biggar

  • 1. sandbox them

Fix at language design time

  • No dynamic include; no eval.
  • Compile-time meta-programming
  • .rc files
slide-42
SLIDE 42

Compiled and interpreted models

Fix at language design time

  • No dynamic include; no eval.
  • Compile-time meta-programming
  • .rc files
  • localization

How not to Design a Scripting Language Paul Biggar

  • 1. With a compiled

model, we know all the files

Fix at language design time

  • No dynamic include; no eval.
  • Compile-time meta-programming
  • .rc files
  • localization
slide-43
SLIDE 43

Compiled and interpreted models

Doing it right

  • Factor
  • compiled model
  • compile-time meta-programming
  • declarative FFI

How not to Design a Scripting Language Paul Biggar

  • 1. unfortunately

chose a paradigm that nobody knows: stack-based; whoops!

Doing it right

  • Factor
  • compiled model
  • compile-time meta-programming
  • declarative FFI
slide-44
SLIDE 44

Compiled and interpreted models

Open research problems

  • Optimizing boxing
  • High-level optimizations
  • Combining ahead-of-time and JIT compilation

How not to Design a Scripting Language Paul Biggar

  • 1. this is the shit we

should be researching, instead of finding ways around intracaible problems

  • 2. javascript 10px
  • 3. table based
  • 4. should be trivial

Open research problems

  • Optimizing boxing
  • High-level optimizations
  • Combining ahead-of-time and JIT compilation
slide-45
SLIDE 45

Compiled and interpreted models

Conclusion

Design the next scripting language right

How not to Design a Scripting Language Paul Biggar

Conclusion

Design the next scripting language right