Discover Top Posts Tagged with #odersky

Advanced Apache Spark Meetup January 28th, 2016 Speakers: Martin Odersky and Chris Fregly Location: Galvanize SF http://www.meetup.com/Advanced-Apache-Spark-...

#scala #programming #odersky #Martin Odersky

Scala - The Simple Parts, a talk by Martin Odersky at Gilt

Last night, I went to a talk at Gilt by the creator of Scala, Martin Odersky, titled: Scala - The Simple Parts (slides).

The talk was about celebrating the 10th anniversary of scala, and reflecting on the current status of its user group and its regard as compared to its originating philosophy.

Pinning down the controversy

Why is scala controversial both within and outside of its user group? There are internal disagreements on what the essence of scala is, and what will be in its the future versions. There is also external derision that scala is too academic, and has sold out to industry. But the most vexing vexing complaint for Odersky is that "scala is everything at the kitchen sink."

Does this disagreement come from scala trying to please many masters? Generally, scala is seen as a unifier, a scalable language. It fulfills agile desires of being easy to script with and being easy to change. Yet scala also satisfies heavier production demands like being performant, and that its programs will be correct (the program's set of outputs contains only its intended meanings)

Yet is either of these (code velocity vs code stability) its main focus? Scala has proved to be growable, in the spirit of Guy Steele. It is flexible enough for a plethora of DSLs to crop up. The downside of this is that DSLs can fracture a community. If it is too easy to develop side-languages, then it is inevitable that some distributed dislike of and opposition to particular DSLs written in scala will be displaced to scala itself. Following the Lisp curse, a coherent user group for scala could vanish.

"Behold, the people is one, and they have all one language [....] Go to, let us go down, and there confound their language, that they may not understand one another's speech. So the Lord scattered them abroad from thence upon the face of all the earth: and they left off to build the city." Tower of Babel

Rephrasing Compromise - A Modular Language

Scala can be seen as a cross between Object Oriented and Functional languages.

From James Iry - A Brief, Incomplete, and Mostly Wrong History of Programming Languages:

2003 - A drunken Martin Odersky sees a Reese's Peanut Butter Cup ad featuring somebody's peanut butter getting on somebody else's chocolate and has an idea. He creates Scala, a language that unifies constructs from both object oriented and functional languages. This pisses off both groups and each promptly declares jihad.

However, scala's origins are about modularity more than compromise. A decade ago, the Object Oriented paradigm of putting your objects where your data are was challenged by the popular data-store XML. XML is the excuse/inspiration for scala. XML is pure data. You can't put your code in the XML files. Odersky thought that handling XML was perhaps best suited for a functional style of programing driven by pattern matching.

This was a growth promoting (project growth rather than the above community growth) decision. The idea was that only one set of concepts is needed for different size projects.

"A large system is one where you do not know that some of its components even exist." - Source Unknown

Scala's spirit does not come out of an Object Oriented or Functional language compromise, but instead out of a desire to be a Modular language. The focus of scala is to provide a way to write discrete modules that can be combined in many interesting ways. It answers John Backus' call to action to improve upon the von neumann bottleneck, where a centralized bus between memory and cpu smothers any ideas of parallel computation. Odersky instead wants a separation of concerns in scala programs.

Scala is set apart in its quest for modularity above all else. Functional languages like Haskell can fail at this (Haskell's type classes have global dependencies 7.2). Object oriented languages are no better, an easy example is monkey patching. If a program is truly large, then somebody else's monkey patch that you don't know about is bound to interfere with your code sometime. But its larger problem is the paradigm of mixing domain models with the application. This can sometimes avoid initial implementation headaches, but if you have a fixed set of data, putting code near the data means you have to touch many source files to track down or change one interaction in the future.

Focus on the Simpler Parts

Unfortunately, much of what you read about scala on blogs is about the experimental features (which should disappear by the time version 12 comes out in about a year). But there some underused simple parts of scala.

Most notably:

People often jump straight from writing imperative loops to combinators in collections, missing the intermediate tools of recursion.

var is important. Used wisely, mutable state can cut down on annoying boilerplate. Where Odersky say he uses mutable state:

caching

persisting

copy on write

fresh values (unique ids)

Rich types and Static types should be taken full advantage of. The greatest ability of static types is to hide implementation details behind a type.

#odersky

Trending Tags

Recently Viewed Tags

#odersky