Sparkling the champagne of languages

H2CO3

H2CO3About

• Árpád Goretity

• Programming aficionado

• 10+ years, 10+ languages

• BSc student in Bionics

Greetings, few words about me: university student, programming enthusiast, have used several languages.

515

40

Scheduleslides 40’

demo 15’

questions 5’

!

77.111.97.114

Questions

Show IP address, explain how the question system is working

!

77.111.97.114

+++++ +++++ [ > +++++ ++ > +++++ +++++ > +++ > + <<<< - ]

Here is what it looks like

!

77.111.97.114

var letters = { 'H', 'e', 'l', 'l', 'o', '!' };

for var i = 0; i < sizeof letters; i++ {

printf("%c", letters[i]);

}

Just kidding, here’s what it actually looks like. Sparkling combines features and high-level design decisions from other popular languages, such as: … I also added my own novel ideas.

!

77.111.97.114

But… Why?

Problem: JS tries to implicitly make sense of the nonsensical. Sparkling: counter-example — all of these expressions are correctly false.

!

77.111.97.114

Types, types, types

>>> "0" == 0

>>> "0" == []

true

>>> 0 == []

true

Sparkling

false

false

falsefalse

JavaScript

Mistake found in: JavaScript Problem: JS tries to implicitly make sense of the nonsensical. Sparkling: counter-example — all of these expressions are correctly false.

!

77.111.97.114

Huge implementation200 MB

94 MB

150 kB

V8

Sparkling

CPython

Often, you want your apps to be user-scriptable. But do you want it to be 200 MB bigger b/c it has Python? - “ - 100 MB bigger due to JS?

!

77.111.97.114

Floating-point

true

> a = 2 ^ 54

> print(a == a + 1)

false

> global a = 1 << 54;

> print(a == a + 1);

Sparkling

Lua

Mistake found in: JavaScript, Lua Scripting languages tend to simplify things -> that’s good But numbers are oversimplified: only FP -> bad!

!

77.111.97.114

Operators

> print(0x08 & 0x08 == 0x08); true

>>> 0x08 & 0x08 == 8 0

Sparkling

JavaScript

Mistake found in: C and descendants

!

77.111.97.114

Implied globalsb.prevObject=this,b.context=this.context,b},each:function(a,b){return n.each(this,a,b)},map:function(a){return this.pushStack(n.map(this,function(b,c){return a.call(b,c,b)}))},slice:function(){return this.pushStack(d.apply(this,arguments))},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},eq:function(a){var b=this.length,c=+a+(0>a?b:0);return this.pushStack(c>=0&&b>c?[this[c]]:[])},end:function(){return this.prevObject||this.constructor(null)}, push:f,sort:c.sort,splice:c.splice},n.extend=n.fn.extend=function() !{var a,b,c,d,e,f,g=arguments[0]||{},h=1, i=arguments.length,j=!1; for("boolean"==typeof g&&(j=g,g=arguments[h]||{},h++),”object”==typeof…

Can you spot the error?Missing var keyword

Mistake found in: Lua, JavaScript The error is obvious once it’s pointed out… Of course this is not an actual situation, but similar things happen in real life.

!

77.111.97.114

Implied globals

> global foo = 42; > print(goo); runtime error: global `goo' does not exist > goo = 43; semantic error: variable `goo' is undeclared

Sparkling:

!

77.111.97.114

Garbage Collection

— Mistake found in: almost all script languages (JS, Python, Lua) + Java — GC on mobile != GC on desktop (memory-constrained environment) — when Apple announced they abandon GC: the audience applauded

!

77.111.97.114

Garbage Collection

ARC

GC

— Mistake found in: almost all script languages (JS, Python, Lua) + Java — GC on mobile != GC on desktop (memory-constrained environment) — when Apple announced they abandon GC: the audience applauded

Tim

e sp

ent

on G

C

Relative memory

GC: - wastes memory - is non-deterministic - can cause lags in user experience On desktop: you might have spent your entire life in the right half of this chart On mobile: code exponentially slowing down!

Sparkling uses ARC

And so on…• Complexity of C API (Lua, Python)

• Subjective…

• Syntax → semantic errors

Apple SSL bug https://www.imperialviolet.org/2014/02/22/applebug.html

Architecture

• strict C89

• no external dependencies

• drop-in library

!

Compiler

• lexer: no regexes

• parser: purely recursive descent

• codegen: no optimizations

Lexer: manually written, no regular expressions (not portable, regexes are horrible and incapable of lexing Sparkling); — parser “is slow” but still fast enough; easy to read and extend: code structure follows the grammar — codegen: if you need more speed, then use C

Virtual Machine

• register-based → fast

• implements reference counting

• symbol tables

• standard library

Global symtab stores globals Local symtabs: each file has its own - stores string literals and references to external globals - stdlib: just a set of native extension functions, nothing special

The numbers• Everyone is worrying so much

about performance• Very few people should

• If speed is critical: C, C++, ASM

• JIT: huge

• Still reasonably fast – how? why?

JIT: planned, but only as a separate project (core library should be portable) ! - Avoiding premature optimization != coding without thinking - Higher-level design decisions and considerations (e. g. register machine – wasn't trivial to implement) - All micro-optimizations are left to the C compiler (e. g. heavy reliance on LTO) - compiler is better at this than I am

Demo time

Next slide! (HW + SW specs should be presented before starting the demo)

Demo time• MacBook Pro ‘10, 2.66 GHz, 8 GB RAM • C: Clang/LLVM • JavaScript: JavaScriptCore • Python: CPython 3.x • 10 runs, averaged

Conclusion

• Simple and small !

• Strict, pure → sane !

• Productive

What’s next?

• Extension language !

• Friendly → education, “good first language” !

• Web (server-side?)

The endThank you for your attention!

@H2CO3_iOS H2CO3/Sparkling

And now we’re doing questions — let’s look at the ones you asked during the presentation!