JVMLangSummit - User contributions [en]

Clojure Keynote

2009-09-17T17:10:37Z

Al3x: New page: = Provocation = * Is OOP the best way to write software? = Background = * single-dispatch, stateful, OOP languages are entrenched * differences between these languages are superficial (ex...

= Provocation =
* Is OOP the best way to write software?

= Background =
* single-dispatch, stateful, OOP languages are entrenched
* differences between these languages are superficial (ex: syntax, availability of closures, etc.)
* key ideas: complexity, time
* "Seek simplicity, and distrust it." - Whitehead

= Incidental Complexity =
* bad tools and solutions make us less efficient in small ways
* complexity is obvious, but sometimes complexity is hidden behind a facade of simplicity
* C++ is easy to learn, but is it really simple?
** same syntax to refer to things on the heap and things not on the heap
** what do you do with objects? no standard automatic memory management - big source of incidental complexity
** the language doesn't make it clear that memory management is the programmer's responsibility
* ditto Java
** even removes the complexity of handling GC
** hidden complexity: mutable vs immutable objects; not just a concurrency problem, a complexity problem
* most programmers measure complexity in superficial ways: syntax, expressivity
* we want encapsulation so we can build things on top of other things more simply; "someone building a house doesn't have to worry about the inside of a brick"

= Pure Functions Are Worry-Free =
* local scope
* takes and returns values
* has no notion of time
* easy to understand and change
* problems with functions, though:
** "programs in general are not functions"
** programs run indefinitely long
** users need to see the program's behavior
** couldn't express Google search as a function, it's a process

= OO and Change =
* behavior and time are almost meaningless in OOP
* there's no real concept of time in objects, they don't have a reified notion of time, but objects pretend to manipulate time
* "the OO model has gotten time wrong"
** we've made objects that can change in place, and we've made objects that we can _see_ change in place
** no proper notion of values
* "No man can cross the same river twice."

= A Simplified View =
* "We've invented mutable objects, we need to un-invent them."
* actual entities are atomic immutable values
* we superimpose mutable models on collections of immutable values
** identities are mental constructs
** the future is a function of the past
** objects are not things that change over time
* "There is a becoming of continuity, but not a continuity of becoming."

= Terms =
* Value: immutable magnitude, quantity, number, or immutable composite thereof
* Identity: a relative entity we associate with a series of values
* State: value of an identity at a moment in time
** "mutable state makes no sense (given this definition)"
* Time: relative before/after ordering of causal values

= Why should we care? =
* our programs need to make decisions
* mutable way of thinking is a useful mental model, makes things easier to conceptualize
* but we can't screw up time and immutability because then things are wrong
* we don't make decisions about the world through direct contact between our brains and the outside world - we don't take our brains out and rub them on things we want to experience
* we also don't get to stop the world to look around
* human perception is uncoordinated and massively parallel - it's NOT message passing
** we are always perceiving the unchanging past
** we perceive based on discrete events - we like snapshots (they're like values)
** are brains are simultaneity detectors
* making things happen are perceiving things are completely different

= Implementation =
* pure functions - we have this
* language constructs for representing values, creating them and sharing them
* coordinate the succession of values
* we have to consume memory to model time
** old value -> pure function -> new value (non-destructive, consumes memory)
** old values can be used as perceptions/memory
** GC will clean up the "past" that's no longer referenced
* persistent data structures
** immutable
** ideal for states, snapshots, and memories
** stable values for decision-making and calculation
*** the next version of a value shares structure with previous value, so usually efficient
*** creating a value never disturbs prior values, nor impedes perceivers of prior
** "your life is going to be better if you use these because there's a huge quantity of things you'll no longer have to worry about"
** usually based on trees (with high branching factors, usually shallow)
*** support structural sharign

= Declarativeness and Parallelism =
* must be more declarative, less looping
* tree-based persistent data structures work well for this
** pre-partitioned
** compositional building blocks
** don't perform as well - better for reads than write, but...
** nobody can see what happens inside operations
** more cores, and the parallelism starts to match up to mutable data structures

= Time Constructs =
* need to ensure atomic succession
* need to provide point-in-time value perception (snapshots)
* multiple timelines support multiple threads of control - no "I'm the program, I control the universe" model
* models: CAS, Agents, STM, locks as a way to enforce timelines
* perception in STM via multi-version concurrency control
** no interference with processes
** cheap historical snapshots
** allows observers/readers to maintain a timeline
*** composite snapshots form glimpses and visual scans, thinking in terms of human vision
** "there is no one STM; if you want to beat up on STM, pick an implementation"
*** granularity matters; if you find yourself requiring a transaction to perceive a consistent value, you're doing it wrong

= Conclusion =
* excessive implicit complexity begs for change
* conflation of behavior, time, identity, and state is a big source of implicit complexity in OOP
* "pay attention to the FP people, look at the great properties of pure functions"
* epochal time model is worth trying - be explicit about time
** we can do multiple implementations, we have the infrastructure to support it
* hard problems: tying STM to things like IO, coordinating with the rest of the world
* "become as happy as you can with the lack of control - that will give you more concurrency"
* more data structures and time constructs to come
* open question: is there a way to reconcile all this with OOP?

Better Ruby

2009-09-16T19:08:54Z

Al3x:

= JRuby, Duby, and Juby: Building a better Ruby — Charles Nutter =

;Project: http://jruby.org/
;Blog:http://blog.headius.com/
;Slides: [[Image:JVM_Languages_Summit_2009_-_JRuby]]

== Abstract ==
You know JRuby is an implementation of Ruby for the JVM. But have you heard about Duby or Juby? Duby is Ruby syntax with Java's type system and static typing. It utilizes local type inference to keep code as clean as Ruby, but runs as fast as Java. Juby is Duby's dynamic cousin, totally dynamically-typed and using invokedynamic for all dispatch. Both Duby and Juby have been research conduits for the next generation of JRuby work, which will incorporate techniques from both languages. We'll talk about all three.

= Notes =

== JRuby ==
* making optimizations for things like returining from closures
* Invoke Dynamic (indy):
** eliminates generated handles, simplifies things
** inlines a lot of otherwise complex logic
** getting faster
* Duby is an experiment in optional static typing that may be rolled into JRuby
* new optimizing compiler now that they have a "real compiler guy" on the JRuby team

== Duby ==
* a side-project
* "like Ruby but as fast as Java; essentially Java with Ruby syntax"
* typing works kinda like Scala
* no runtime library
* purpose: an implementation language for JRuby, mobile applications
** "doesn't add too much"
* code example: only different between Ruby and Duby is specifying the type of some arguments to methods
* "MyObject.new" is hard-coded to object creation, not a method call
* status:
** type and method definitions work
** importing types, Java object construction works
** todo: arrays, reopening classes, mixins, closures, runtime libraries in Duby, Java 5 features,
** possible LLVM backend or in other languages

== Surinx ==
* another side-project
* exactly Ruby syntax
* dynamically typed ("not quite as crazily dynamic as Ruby")
* dynamic dispatch (indy)
* minimal runtime library (indy dispatcher)
* scriptable, but no interpreter
* "as fast as Java (can do indy)"
* goals: experiment with indy, help the implementors test, try things outside JRuby
* code examples: really identical to Ruby
* bunch of stuff still to do
* Java version of fib example (only) 40% faster than Surinx version

Better Ruby - Nutter

2009-09-16T19:07:52Z

Al3x: Redirecting to Better Ruby

#REDIRECT [[Better_Ruby]]

Better Ruby - Nutter

2009-09-16T19:07:23Z

Al3x: Redirecting to Better Ruby

#REDIRECT [[Better_Ruby]]

= JRuby =
* making optimizations for things like returining from closures
* Invoke Dynamic (indy):
** eliminates generated handles, simplifies things
** inlines a lot of otherwise complex logic
** getting faster
* Duby is an experiment in optional static typing that may be rolled into JRuby
* new optimizing compiler now that they have a "real compiler guy" on the JRuby team

= Duby =
* a side-project
* "like Ruby but as fast as Java; essentially Java with Ruby syntax"
* typing works kinda like Scala
* no runtime library
* purpose: an implementation language for JRuby, mobile applications
** "doesn't add too much"
* code example: only different between Ruby and Duby is specifying the type of some arguments to methods
* "MyObject.new" is hard-coded to object creation, not a method call
* status:
** type and method definitions work
** importing types, Java object construction works
** todo: arrays, reopening classes, mixins, closures, runtime libraries in Duby, Java 5 features,
** possible LLVM backend or in other languages

= Surinx =
* another side-project
* exactly Ruby syntax
* dynamically typed ("not quite as crazily dynamic as Ruby")
* dynamic dispatch (indy)
* minimal runtime library (indy dispatcher)
* scriptable, but no interpreter
* "as fast as Java (can do indy)"
* goals: experiment with indy, help the implementors test, try things outside JRuby
* code examples: really identical to Ruby
* bunch of stuff still to do
* Java version of fib example (only) 40% faster than Surinx version

Exploring Dynamism - Randal

2009-09-16T18:41:23Z

Al3x:

Slides: [[Image:Exploring dynamism.pdf]]

----

= Introduction =
* "a mental exploration of dynamic language features"
* "crystalize what dynamism is"
* static vs dynamic as particle vs wave
* sometimes a binary distinction, sometimes not
* "no language is entirely static or dynamic"

= Dynamic Typing =
* you can do more stuff with a dynamic type system
* think of it as a way to extend the type system by having types inspect run-time state

= Dynamic Dispatch =
* "stages of dynamism"
* multiple dispatch can be done either statically or dynamically
* many forms of caching (polymorphic inline caching, et. al.) are forms of dynamic dispatch

= Introspection =
* not strictly a dynamic language feature, but more common in dynamic langs than in static ones
* annotations (ex: research at IBM on using annotations to enforce web application security constraints)

= Dynamic Compilation =
* compiling blocks of code, capturing the environment around that code (closures, runtime environment, etc.)
* higher-order functions: methods generating other methods at runtime
* interaction (REPL), as with the Python command line
* sci-fi future: self-modifying code

= Dynamic Loading =
* another strategy for adding new code at runtime
* including new libraries
* binding routines to objects
* mixins/traits/roles and other cross-cutting inheritance/extension models
* dynamic unloading: not often seen because dynamic languages traditionally power applications that run for short periods and wouldn't see gains from unloading to free up memory

= Conclusions =
* "static systems and dynamic systems are both critical"
* tradeoffs of tighter control vs greater abstraction, productivity vs performance
* hybrid systems may be the most effective

Exploring Dynamism - Randal

2009-09-16T18:40:20Z

Al3x:

[[Image:Exploring dynamism.pdf|Slides]]

----

= Introduction =
* "a mental exploration of dynamic language features"
* "crystalize what dynamism is"
* static vs dynamic as particle vs wave
* sometimes a binary distinction, sometimes not
* "no language is entirely static or dynamic"

= Dynamic Typing =
* you can do more stuff with a dynamic type system
* think of it as a way to extend the type system by having types inspect run-time state

= Dynamic Dispatch =
* "stages of dynamism"
* multiple dispatch can be done either statically or dynamically
* many forms of caching (polymorphic inline caching, et. al.) are forms of dynamic dispatch

= Introspection =
* not strictly a dynamic language feature, but more common in dynamic langs than in static ones
* annotations (ex: research at IBM on using annotations to enforce web application security constraints)

= Dynamic Compilation =
* compiling blocks of code, capturing the environment around that code (closures, runtime environment, etc.)
* higher-order functions: methods generating other methods at runtime
* interaction (REPL), as with the Python command line
* sci-fi future: self-modifying code

= Dynamic Loading =
* another strategy for adding new code at runtime
* including new libraries
* binding routines to objects
* mixins/traits/roles and other cross-cutting inheritance/extension models
* dynamic unloading: not often seen because dynamic languages traditionally power applications that run for short periods and wouldn't see gains from unloading to free up memory

= Conclusions =
* "static systems and dynamic systems are both critical"
* tradeoffs of tighter control vs greater abstraction, productivity vs performance
* hybrid systems may be the most effective

JDK - Reinhold

2009-09-16T18:39:11Z

Al3x: New page: = focus of JDK 7 = * modularization * multiple languages * not really the focus of this talk * Java language evolution = Project Coin = * project to evolve the Java language * improved in...

= focus of JDK 7 =
* modularization
* multiple languages * not really the focus of this talk
* Java language evolution

= Project Coin =
* project to evolve the Java language
* improved integer literals
* "exotic identifiers": #"op~"
** for interoperation with langugages that may use symbols and such in method names and other identifiers (ex: Scala)

= Project Jigsaw =
* modularization of the JVM
* JVM is too large (18MB), slow to download not on broadband, hard to fit on small devices
* ex: import the 'desktop' module, get swing, sound, awt, etc.
* jmod tool to quickly install packages:
** sudo jmod install [url for .jmod package] and you're done

= mlvm =
* Da Vinci Machine Project
* explored further in the next session
* goal is to support multiple languages well on the JVM

Exploring Dynamism - Randal

2009-09-16T18:38:44Z

Al3x:

Slides: [[Image:Exploring dynamism.pdf]]

= Introduction =
* "a mental exploration of dynamic language features"
* "crystalize what dynamism is"
* static vs dynamic as particle vs wave
* sometimes a binary distinction, sometimes not
* "no language is entirely static or dynamic"

= Dynamic Typing =
* you can do more stuff with a dynamic type system
* think of it as a way to extend the type system by having types inspect run-time state

= Dynamic Dispatch =
* "stages of dynamism"
* multiple dispatch can be done either statically or dynamically
* many forms of caching (polymorphic inline caching, et. al.) are forms of dynamic dispatch

= Introspection =
* not strictly a dynamic language feature, but more common in dynamic langs than in static ones
* annotations (ex: research at IBM on using annotations to enforce web application security constraints)

= Dynamic Compilation =
* compiling blocks of code, capturing the environment around that code (closures, runtime environment, etc.)
* higher-order functions: methods generating other methods at runtime
* interaction (REPL), as with the Python command line
* sci-fi future: self-modifying code

= Dynamic Loading =
* another strategy for adding new code at runtime
* including new libraries
* binding routines to objects
* mixins/traits/roles and other cross-cutting inheritance/extension models
* dynamic unloading: not often seen because dynamic languages traditionally power applications that run for short periods and wouldn't see gains from unloading to free up memory

= Conclusions =
* "static systems and dynamic systems are both critical"
* tradeoffs of tighter control vs greater abstraction, productivity vs performance
* hybrid systems may be the most effective

Exploring Dynamism - Randal

2009-09-16T18:38:18Z

Al3x: New page: Slides: [Image:Exploring dynamism.pdf] = Introduction = * "a mental exploration of dynamic language features" * "crystalize what dynamism is" * static vs dynamic as particle vs wave * som...

Slides: [Image:Exploring dynamism.pdf]

= Introduction =
* "a mental exploration of dynamic language features"
* "crystalize what dynamism is"
* static vs dynamic as particle vs wave
* sometimes a binary distinction, sometimes not
* "no language is entirely static or dynamic"

= Dynamic Typing =
* you can do more stuff with a dynamic type system
* think of it as a way to extend the type system by having types inspect run-time state

= Dynamic Dispatch =
* "stages of dynamism"
* multiple dispatch can be done either statically or dynamically
* many forms of caching (polymorphic inline caching, et. al.) are forms of dynamic dispatch

= Introspection =
* not strictly a dynamic language feature, but more common in dynamic langs than in static ones
* annotations (ex: research at IBM on using annotations to enforce web application security constraints)

= Dynamic Compilation =
* compiling blocks of code, capturing the environment around that code (closures, runtime environment, etc.)
* higher-order functions: methods generating other methods at runtime
* interaction (REPL), as with the Python command line
* sci-fi future: self-modifying code

= Dynamic Loading =
* another strategy for adding new code at runtime
* including new libraries
* binding routines to objects
* mixins/traits/roles and other cross-cutting inheritance/extension models
* dynamic unloading: not often seen because dynamic languages traditionally power applications that run for short periods and wouldn't see gains from unloading to free up memory

= Conclusions =
* "static systems and dynamic systems are both critical"
* tradeoffs of tighter control vs greater abstraction, productivity vs performance
* hybrid systems may be the most effective

Presentations2009

2009-09-16T18:37:43Z

Al3x:

'''2009'''

{| border="1"
!
!Wednesday 09/16/09
!Thursday 09/17/09
!Friday 09/18/09
|-
| 9:00||[[Welcome - Goetz/Pampuch]] ||[[Keynote - Hickey]] ||[[ANTLR - Parr]]
|-
|-
| 9:30||[[JDK - Reinhold]] ||[[ -- ]] ||[[JVM continuations - Click]]
|-
|-
| 10:00||[[Da Vinci Machine - Rose]] ||[[JVM Performance - Click]] ||[[Trace-based JIT - Wimmer]]
|-
| 11:00||[[Exploring Dynamism - Randal]] ||[[WS - Click]] ||[[WS - Optimizing Ioke]]
|-
| 11:30||[[Better Ruby - Nutter]] ||[[WS - Randall]] ||[[WS - Clojure deep dive]]
|-
| 1:00||[[MOP & Indy - Szegedi]] ||[[Scala basics - Pollak]] ||[[Static Dynamic Types - Gafter]]
|-
| 1:30||[[Scala IDE - Sabin]] ||[[Groovy Performance - Theodorou]] ||[[Blame Tracking - Siek]]
|-
| 2:00||[[Hotswap - Wuerthinger]] ||[[Sun update - Tanase]] ||[[JavaFX Binding - Field]]
|-
| 2:30||[[WS - Eagle]] ||[[NET Reactive Framework - Meijer]] ||[[ -- ]]
|-
| 2:30||[[WS - DJRuby]] ||[[ -- ]] ||[[ -- ]]
|-
| 3:00||[[ -- ]] ||[[Anti-Optimizations - Ohrstrom]] ||[[Jython - Baker]]
|-
| 3:30||[[ -- ]] ||[[Ioke, a folding language - Bini]] ||[[JSR 292 Backport Deep Dive]]
|-
| 4:00||[[WS - invokedynamic]] ||[[WS - Asynchronicus Anonymous]] ||[[WS - Baker]]
|-
| 4:00||[[WS - Tools]] ||[[WS - using a MOP]] ||[[WS - Factor JIT]]
|-
|}

Da Vinci Machine

2009-09-16T17:38:12Z

Al3x: New page: = Background = * project goal: changes to the JVM bytecode architecture * JVM has been language-independent from the beginning, but hasn't necessarily been optimal for non-Java languages *...

= Background =
* project goal: changes to the JVM bytecode architecture
* JVM has been language-independent from the beginning, but hasn't necessarily been optimal for non-Java languages
* first code posted in 2008, along with draft specifications for reviewer (JSR 292)
* balancing specification with implementation: tail-calls, interface injection, invoke dynamic ("indy")

= Current Status =
* active developer community on mailing list, IRC
* programmers assigned to a number of key tasks in JSR 292

= Future =
* fixnums and tuples handled better in the JVM

JDK7 and Beyond

2009-09-16T16:44:18Z

Al3x:

JDK7 and Beyond

2009-09-16T16:42:07Z

Al3x: New page: - focus of JDK 7 - modularization - multiple languages - not really the focus of this talk - Java language evolution - Project Coin - project to evolve the Java language ...

- focus of JDK 7
- modularization
- multiple languages - not really the focus of this talk
- Java language evolution
- Project Coin
- project to evolve the Java language
- improved integer literals
- "exotic identifiers": #"op~"
- for interoperation with langugages that may use symbols and
such in method names and other identifiers (ex: Scala)
- Project Jigsaw
- modularization of the JVM
- JVM is too large (18MB), slow to download not on broadband, hard
to fit on small devices
- ex: import the 'desktop' module, get swing, sound, awt, etc.
- jmod tool to quickly install packages:
- sudo jmod install [url for .jmod package] and you're done
- mlvm - Da Vinci Machine Project
- explored further in the next session
- goal is to support multiple languages well on the JVM