A brief history of Lua - Roberto  Ierusalimschy (PUC Rio)
Upcoming SlideShare
Loading in...5
×
 

A brief history of Lua - Roberto Ierusalimschy (PUC Rio)

on

  • 5,520 views

 

Statistics

Views

Total Views
5,520
Views on SlideShare
3,000
Embed Views
2,520

Actions

Likes
3
Downloads
42
Comments
0

18 Embeds 2,520

http://www.havok.com 1206
http://www.kore.net 639
http://kore.net 597
http://francescoagati.posterous.com 28
https://twitter.com 8
http://www.slideshare.net 7
http://fry.sf.havok.com 7
http://webcache.googleusercontent.com 6
http://web.archive.org 6
http://translate.googleusercontent.com 3
http://lua.kore.net 3
http://thewiki.cs.myharris.net 2
http://kore.havok.com 2
http://static.slidesharecdn.com 2
http://www.sworm.net 1
http://207.46.192.232 1
http://a0.twimg.com 1
http://www.zoominfo.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • However, after a while, both groups started to experiment limitations with those languages. DEL was already being used in 'production', and users were asking all kinds of extensions.
  • What we wanted was a "generic little language", a language that could be used for configuration for any program that needed such language. It should have all features of a programming language, such as conditionals, loops, procedures, assignment, etc. It also should be easily embeddable in any application (that was its main goal!). It should be portable, because Petrobras had a quite diverse array of machines. It should be simple, so we could implement it fast. And it shoud have a syntax somewhat appropriated for non programmers (engineers, geologists, etc.)
  • What we wanted was a "generic little language", a language that could be used for configuration for any program that needed such language. It should have all features of a programming language, such as conditionals, loops, procedures, assignment, etc. It also should be easily embeddable in any application (that was its main goal!). It should be portable, because Petrobras had a quite diverse array of machines. It should be simple, so we could implement it fast. And it should have a syntax somewhat appropriated for non programmers (engineers, geologists, etc.)
  • On one hand, Lua allowed definitions that looked exactly like in Sol. For instance, this definition for a track is exactly as it were in Sol
  • On the other hand, the semantics was radically different. In Lua, that definition was an assignment, and the "at"-name syntax was a kind of constructor: it created an object with the given fields (x, y and title) and called the named function ("track"). That function then could do whatever it needed: type check each field, assign default values, check any kind of condition, etc.
  • The first implementation was really simple and unpretentious. We did not even used a revision control system! The interpreter precompiled the code into bytecodes and then interpreted the bytecodes with a virtual stack machine (inspired in Modula's M machine). The compiler was written with Lex and Yacc, and was strictly one pass, with no intermediate representation. The whole system had less than five thousand lines of C code.
  • We really did have few expectations for Lua 1.0 (as witnessed by its implementation). We wanted to solve our problems with our projects, and with luck also help other projects at Tecgraf. In the end we were very happy with the result. Soon, other projects started using Lua for several different tasks.
  • Around 1994, OO fever was in its height. The two most frequent questions we heard were "is Lua an object-oriented language?" and "why not?". So, we started a new version to try to better answer those questions. Lua 2.1 started two important (but not necessarily good) trends in Lua: incompatibility changes between versions and avoiding though decisions.
  • Inspired by Self, we decided for a prototype-based mechanism. We wanted the easiest modification to the language that would allow us to answer "yes, Lua is an object-oriented language". (Or, more exactly, "can be an object-oriented language!) We added a mechanism called "fallbacks" to Lua.
  • A major change was in the syntax. We unified the different kinds of constructors in an uniform syntax. More important, we removed the concept of "constructor" (in the OO sense) and replaced by a syntactic sugar for function calls.
  • During that period, Lua slowly started to attract some attention outside Tecgraf and PUC. Its first home page was inside my personal page. As we started to receive several questions from outside, we decided to create a list, so that users could answer the questions from other users.
  • based on a stack abstraction

A brief history of Lua - Roberto  Ierusalimschy (PUC Rio) A brief history of Lua - Roberto Ierusalimschy (PUC Rio) Presentation Transcript

  • A Brief History of Lua Roberto Ierusalimschy chief Lua architect
  • The Beginning (92-93)
    • Tecgraf: partnership between PUC-Rio and Petrobras (the Brazilian Oil Company)
    • emphasis on development
      • but in an academic setting
    • two programs using "little languages"
      • with all limitations of little languages
  • Data Entry Programs
    • graphical interfaces for legacy Fortran simulation programs
    d View slide
  • DEL Data Entry Language :e gasket &quot;gasket properties&quot; mat s # material d f 0 # distance y f 0 # stress t i 1 # facing type :p gasket.d > 30 gasket.d < 3000 gasket.y > 335.8 gasket.y < 2576.8 View slide
  • DEL limitations
    • decision-making facilities
    • arithmetic expressions
    • abstraction mechanisms
      • variables, functions
  • Programa Gr áfico Mestre program to visualize geologic profiles
  • SOL - Simple Object Language
    • data description language
      • not totally unlike XML
      • BibTeX-like syntax
    type @track {x:number, y:number=23, z} type @line {t:@track=@track{x=8}, z:number*} -- create an object 't1', of type ' track ' t1 = @track {y=9, x=10, z=&quot;hi!&quot;} l = @line {t=@track{x=t1.y, y=t1.x}, z=[2,3,4]}
  • SOL limitations
    • decision-making facilites
    • arithmetic expressions
    • abstraction mechanisms
    sounds familiar...
  • what about a common language for both projects?
  • What we needed
    • a generic configuration language
      • goal was to configure other applications
    • easily embeddable
      • implemented as a library, to be used by both projects
    • a &quot; complete&quot; language
      • functions, variables, control structures, etc.
  • What we needed
    • portable
      • Petrobras had a diverse array of machines
    • as simple as possible
      • we needed to solve our problem
    • non-intimidating syntax
      • for end users (engineers, geologists, etc.)
  • Lua
    • as the old language was called SOL (&quot;Sun&quot; in Portuguese), a friend suggested the name &quot;Lua&quot; (&quot;Moon&quot; in Portuguese) for the new language
  • Sol x Lua 1.0
    • not that different from Sol...
    t1 = @track{x = 10.3, y = 25.9, title = &quot;depth&quot;}
  • Sol x Lua 1.0
    • but quite different...
    t1 = @track{x = 10.3, y = 25.9, title = &quot;depth&quot;} function track (t) if not t.x then t.x = 0.0 end if type(t.x) ~= &quot;number&quot; then print(&quot;invalid 'x' value&quot;) end if type(t.y) ~= &quot;number&quot; then print(&quot;invalid 'y' value&quot;) end end
  • Lua 1.0 (1993)
    • called 1.0 a posteriori
      • no expectations of other versions
    • the simplest thing that could possibly work
      • tables implemented as linked lists!
    • standard implementation
      • precompiler with yacc/lex
      • opcodes for a stack-based virtual machine
    • less than 6,000 lines of C code
  • Lua 1.0
    • expectations: to solve our problems with PGM and DEL
      • could be useful in other Tecgraf products
    • fulfilled our expectations
      • both DEL and PGM used Lua successfully
      • PGM still in use today in oil platforms
    • it was a big success in Tecgraf
    • soon, several projects at Tecgraf were using Lua
  • Lua 1.1 (1994)
    • new users brought new demands
    • reference manual
      • a must if you live among your users
    • well-defined and well-documented C API
      • ditto
      • later, documentation would be crucial for the spread of Lua
  • Lua 2.1 (1995)
    • several important changes
      • several incompatibilities!
    • cleaner C API
      • no more direct references from C to Lua objects
  • Lua 2.1: Fallbacks
    • growing pressure for OO features
    • similar to exception-handling with resumption
    • delegation
      • allowed prototype-based OO
      • inspired by Self
    • kind of minimum mechanism to get the label &quot; OO inside &quot;
  • Lua 2.1: Constructors t = @(size) -- empty t = @[a, b, c] -- list t = @{x = 10, y = 20} -- record t = @foo{x=10, y = 20} -- object t = {} -- empty t = {a, b, c} -- list t = {x = 10, y = 20} -- record t = foo ( {x=10, y = 20} ) -- object Lua 1.1 Lua 2.1
  • Lua 2.2 - 2.5 (95 - 96)
    • external precompiler
      • faster load for large programs (metafiles)
    • debug facilities
    • pattern matching
  • International exposure
    • announcement in Usenet newsgroups
    • first home page in 1995
      • http://www.inf.puc-rio.br/~roberto/lua
    • e-mail contact with &quot; far-away &quot; users
    • beginning of 1997 - discussion list
      • to allow users to answer users ' questions
      • by the end of 1997, over 100 subscribers, should we try a newsgroup?
  • International Exposure
    • Jun 1996 - paper in S:P&E
      • R. Ierusalimschy, L. H. de Figueiredo, W. Celes, Lua - an extensible extension language, Software: Practice & Experience 26(6):635-652, 1996.
    • Dec 1996 - article in Dr. Dobb 's
      • L. H. de Figueiredo, R. Ierusalimschy, W. Celes, Lua: an extensible embedded language, Dr. Dobb's Journal 21(12):26-33, 1996.
  • Beachhead in Games From: Bret Mogilefsky <mogul@lucasarts.com> To: &quot;'lua@icad.puc-rio.br'&quot; <lua@icad.puc-rio.br> Subject: LUA rocks! Question, too. Date: Thu, 9 Jan 1997 13:21:41 -0800 Hi there... After reading the Dr. Dobbs article on Lua I was very eager to check it out, and so far it has exceeded my expectations in every way! It's elegance and simplicity astound me. Congratulations on developing such a well-thought out language. Some background: I am working on an adventure game for the LucasArts Entertainment Co., and I want to try replacing our older adventure game scripting language, SCUMM, with Lua.
  • 1998: Grim Fandango LucasArts
    • &quot; A tremendous amount of the game was written in Lua &quot; (Bret)
  •  
  • 1998 - 2002
    • user base grows outside Brazil
      • shift from inside PUC to outside
    • development of a virtual community
    • several changes in the language
      • support for larger programs
      • functional facilities
      • several incompatible changes between versions
  • 1998
    • in Aug 1998, Cameron Laird wrote in SunWorld:
    &quot; Its user base is also small; there might be only a few tens of thousands of Lua programmers in the world. They're very fond of this language, though, and the imminent explosion of ubiquitous embedded processing (computers in your car, in your plumbing, and in your kitchen appliances) can only work in favor of Lua. &quot;
  • 1998
    • in Aug 1998, Cameron Laird wrote in SunWorld:
    &quot; Its user base is also small; there might be only a few tens of thousands of Lua programmers in the world. They're very fond of this language, though, and the imminent explosion of ubiquitous embedded processing (computers in your car, in your plumbing, and in your kitchen appliances) can only work in favor of Lua. &quot; For us, this &quot;small base&quot; was much larger than we could have imagined!
  • Lua 3
    • several improvements for functional programming
      • anonymous functions, upvalues
    • multiple states
      • support for Lua processes
    • code reorganization
      • more portable
  • Lua 4.0 (Nov 2000)
    • major change in the API
      • all functions got a new parameter (the state)
      • no more C global variables in the code
      • libraries should not use C globals, too
      • concurrent C threads can each has its own state
  • Lua 4.0
    • several other improvements in the API
      • stack oriented
    • no more built-in libraries
      • all standard libraries defined through the official API
  • 2001
    • March 2001, new site: www.lua.org
      • gift from Jim Mathies
    • few months later, lua-users.org
      • kept by Lua users
    • big plans for 4.1
      • so big that Lua went straight to 5.0
  • Lua 5.0
    • coroutines
    • lexical scoping
    • metatables
    • boolean type, weak tables, proper tail calls, ...
    • module system
      • incompatibility
  • Lua 5
    • Dec 2003 - book &quot;Programming in Lua&quot;
    • Mar 2004 - roundtable about Lua at GDC
    • Jul 2005 - 1 st Lua workshop
      • sponsored by Adobe ( San Jose, CA)
    • Sep 2006 - 2 nd Lua workshop
      • sponsored by Oc é ( Venlo, NL)
  • Lua 5.1
    • incremental garbage collector
      • demand from games
    • better support for modules
      • more policies
      • functions to help following &quot;good practice&quot;
    • support for dynamic libraries
      • not portable!
      • the mother of all (non-portable) libraries
      • this support cannot be dynamically loaded!
  • Growth in lines of code
    • a proxy for complexity...
    1.0 1.1 2.1 2.2 2.4 2.5 3.0 3.1 3.2 4.0 5.0 5.1