Scala is amazing, period. Its as machine-like as Haskell and solidly within the functional paradigm camp, as Ive noted before, but its also a very HUGE lesson in PURE object orientation. Now, I find it ridiculous enough of an oversight within the Wikipedia article on Scala to feel it necessary to create a Wikipedia account in order to edit and extend the article (er, sans the caffeine): there is absolutely no mention in the list of languages influencing Oderskys creation about Smalltalk or Simula, which are I the beginning of the OOP lineage of languages. Its myopic to list Eiffel and Oz. I even read an article listing Java as the first purely OOP language, which is entirely untrue - Gosling and his Sun team released Java in the early 90s, whereas Simula came out in the 60s and Smalltalk in the 70s - if any language were in position to be considered purely OOP (and that qualification is also not itself witout need of qualification - what exactly IS pure in this sense? I happen to think of Scala as the first pure OOP, but my qualifying definition of OOP is at least precisely researched and reasoned rather than regurgitated wholesale from some obviously erroneous source - this is why I distrust pop websites and maintain a close dependence upon open source publishing, which produces articles that are open to critical review and editing, and where citing sources is as much the norm as in MLA or APA - I dont know why, in fact, why Wikipedia hasnt been approached about a publishing deal to release a style manual - inquiring library scientists want to know!) Meanwhile, its really a treat to read the first chapter of Oderskys book, Programming in Scala because hes that new-school kind od designer: totally accessible and philosophical, immersed in the history of language design and quite aware of his own designs place within that history: and Smalltalk especially stands out HUGELY in his discussion of Scalas inspirations. Martin Odersky references Alan Kays quote about object orientation, in which he likens the object as analogous to a whole computer, which is really cool conceptually, while also hinting at something Ive just assumed concerning OOP from the beginning: object orientation is nothing more than a sort of unenforced functional paradigm within an imperative context. Ive sometimes been a little unfair in opining that OOP is nothing more than a language patch for all the imperative languages inherent stateful objects, something created to try and control the side effect. Here I was naïve and fundamentally incorrect: OOP was created to handle complexity, and in its purest form is actually very compatible with the functional paradigm. Oderskys Scala is enlightening in the sense that it is a natural conclusion to the relation of functional to OOP paradigmatic design, and the 70s Smalltalk (and 60s Simula) is very important to that eureka moment, I think. A HUGE part of the reason why this should be so is evidenced by an understanding of Scalas internals. Heres something the Wikipedia article could do to TOTALLY encompass a key element of the language, to give readers a taste of Scalas true spirit: every single element within Scala is an object - even when its not apparent. For instance: lets take the operation: 1 + 2. In Scala, + is actually a method, and 1 is an object like this: (1.), and so the object (1.) contains a method (+), which takes (2) in the body of the method and adds it to (1.). It should thus be obvious why curly brackets are superfluous in Scala, mere syntactic sugar - otherwise, how awkward would it be to explicitly state the foregoing like this: main(1) { scala.collections.math.+(2) }, all just to add 2 to 1? Now, if you dig that then you dig Scala deeply. Its actually very beautiful from a pedagogical standpoint: the language is elegantly uniform throughout and so conceptually very simple, without getting in the coders way with exceptions and special forms. This is, as you can see, TRULY pure object orientation. In such a way, then, we neednt wonder at Scalas notoriously terse syntax - from type inference, which ALL code elements possess (which is also an EXTREME static typing but with a with an inference far less nagging than Haskells compiler) you arrive at what might be likened to object inference! Taking the object thing a step further, though, Odersky arrives at further simplicity by encouraging the use of a default functional object - once defined, the object is immutable, while methods within contain optional mutable state variables, simply by declaring either val (immutable, no side effects and thus easily contained within a concise proof) or var (mutable, which is side-effecting and thus necessary, since within I/O what would be the value to the outside world?). Functional defaults make the object orientation model even MORE pure, In my opinion - suddenly the object is what it claims to be, that is: a structural element to handle complexity AND a safety net against many bugs (which is as much the substance of static type checking as it is first-class function - the two, as Haskell goes out of its way to prove, are a right as rain together). Unlike with Haskell, static type checking doesnt get in your way, while Scalas support of algebraic data types offers a concision so on par with Haskell that it is often difficult to tell the two apart at a glance! If any fourth-gen language finally turns the world on to FP (Functional Programming), itll be Scala: as Ive noted previously, the leap from Java (ubiquitous in industry) to Scala is trivial from a syntactic standpoint; however, what people who dont come from an FP background will find challenging and perhaps fun is how to USE that flexible syntax to get into the habit of not relying on side effects - the impetus to do so should be readily apparent to ANY Java shop: why spend so much time coding imperatively, investing in what amounts to over HALF if not MORE of operating costs producing BOILERPLATE? Most of what Ive done in Java, most of what Ive learned, and almost ALL of my debugging, has dealt with control structures and ceremony, while the INTENTION, the FUNCTION of the code itself, makes up maybe a good fifth to MAYBE half of the code. Do the numbers and see for yourself. I rarely hold any book or articles claims or opinions to be sacrosanct - you learn to discern motivations within media of all kinds, and everyone has an angle naturally - and in such a way I constantly push and prod a thing, unsatisfied until Ive fallen asleep face smooshed against the keyboard and a screen full of compiler error messages: only by reading and then being a devils advocate can you arrive at your own conclusions and form your own mental map of languages - if the book says DONT do it, DO it; if the book makes no mention of some idea you think reasonably implied but never encouraged, DO it. Language learning in this way assumes a simple truth: what you are learning has less to do with memorizing discrete THINGS, and more about what the compiler will let you get away with. Thats how precocious child minds learn. Not only this, but with Scala in particular, Ive been adequately rewarded for my iconoclastic imaginagings! That for me is a huge SIGN, personally: the language you immediately find works as you might guess in doing things you yourself imagine and intuit is the one for you - anything in code that seems to roll off the tongue, so to speak, will allow you the most productivity and thus more wiggle room to be creative and take things to extremes. I understand this now. Heres an interesting feature of Scala as well, something I think is killer: Scalas almost wholly Erlang-inspired features, and the huge amount of similarly modular feature set. The language is modular, so that you can extend it through libraries in a way no other language does. For instance, sure Pythons ecosystem offers nearly something for everything under the sun, as does Java, it seems; wide-spread industry use and thus commercial support drive such growth - but these libraries arent nearly so seamlessly integrated as Scalas Erlang-like feature set - one cannot, just coming to the language, discern what is a NATIVE part of the language and what is plugged in and just APPEARS to be a part of the languages built-in features. Thats cool and its the reason Scala stands for scalable language. Its the first language Ive felt impelled to write documentation for, or even started considering immediately the possibility of volunteering on some open source projects to extend the set of libraries! Sure, its important to learn about a handful of languages for purely practical reasons (like accessing the machine, which the JVM only does in a limited sense, through JIT compilation, maybe - or is it ahead-of-time?), if not just in the effort to round out your skillset in a highly competitive job market. Heres what paying attention to several things at once does when learning programming, including language design, compiler theory, lambda, etc - at first, I thought of WHAT I would want to code and thought I probably couldnt actually CARE about any project if it wasnt a video game; whereas now, I find coding itself to BE the game! When abstraction becomes THIS fun, its no wonder this stuff is so addictive!
Posted on: Sun, 23 Mar 2014 20:45:02 +0000