The discussion focused on efforts to separate Java programming from the nitty gritty details of threads. This separation allows a greater number of developers to successfully program for parallel environment by removing focus on the technical details, and thus reducing the knowledge required to write the code. There's also some coverage of the benefits of the higher level of abstraction of functional programming and how the functional programming style is being incorporated into the Java concurrency model. The text has this:

The future will be functional programming or won't be at all.

Intellectually, I applaud these efforts. Emotionally, I feel some loss.

My first introduction to threads was in a systems programming class, using the C language and Pthreads library. Pthreads blew my mind, or maybe it was lack of quality in the lectures. Either way, determined not to be defeated by Pthreads, I went out and bought a stack of books on Pthreads and threads in general and set out to wrap my mind around threads. It worked, but along the way, I learned that I loved the challenge and so I embraced concurrency and parallelism with much enthusiasm. This knowledge that I've accumulated will always be of great value, but as I move toward programming threads at further and further abstractions, I'll lose that close connection to the internals, and I'm a little saddened by that.

From the announcement email:

Professor Martin Odersky is the director of the LAMP group at EPFL, the creator of the Scala programming language, and author of Programming in Scala.

Josh Suereth hosted the first Scala Lift Off East in Reston, VA and has been involved with lots of Scala projects including scala-tools.org, scala-arm, scala-io, scala-jigsaw, and scala-lolz.

I've read halfway through a book on Erlang , another functional programming language, and am finding many similarities to Scala. (That book, BTW, "Programming Erlang: Software for a Concurrent World", by Joe Armstrong , is an excellent book and I highly recommend it.)

So far, I'm liking Scala a lot. It's comfortable because of it's close ties to Java and the fact that it runs in the JVM. It's also compatible with much of the Java code I've written in my life, so that's a huge plus!

My only complaint at this point is with the documentation I've found. There's a lot of great online documentation, but the quick start articles I've read thus far seem to skip all over the place and leave a lot out, so I find myself flipping from one to the other trying to make sense of what I'm reading. It would be a lot easier if I had a concise reference to glance at.

I decided that what's needed is a cheat sheet (pdf), but then couldn't find one, and because necessity is the mother of invention, I've written my own.

Now beware, this cheat sheet was created by a newborn 3-day old Scala programmer, so there may be a lot of corrections needed, and I'm certain it needs more information added to it, but I think this is good enough to start with for a quick start guide.

[Update: I've made several improvements and added a version number that I'll increment every time I update it.]

The Busy Developers' Guide to Scala series:

• “Don't Get Thrown for a Loop”, IBM developerWorks
• “Class action”, IBM developerWorks
• “Functional programming for the object oriented”, IBM developerWorks

Scala Reference Manuals:

• “An Overview of the Scala Programming Language” (2. Edition, 20 pages), scala-lang.org
• A Brief Scala Tutorial, scala-lang.org
• “A Tour of Scala”, scala-lang.org

"Scala for Java programmers", A. Sundararajan's Weblog, blogs.sun.com

First, a couple of quick definitions from Wikipedia:

"Inversion of Control, or IoC, is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to the traditional architecture of software libraries."[2]

"Dependency Injection (DI) in computer programming refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency."[3]

The two topics I want to hit on from Jordan's post are testability of code that's been subjected to IoC/DI and, more trivially, the naming of dependency injection.

What's in a Name?

The term "Dependency Injection" was first published by Martin Fowler, who writes "Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection."[4]

I can appreciate the desire to pin names onto various forms of IoC to separate them more clearly, but I disagree that the term "Inversion of Control" is a more confusing name compared to "Dependency Injection". What can be more clear than inverting control? I don't think dependency injection is anywhere near as clear. I'm probably not the first to say this, but inject it where exactly?

I was pleased to read that I'm not the only person in the world who's not thrilled with the DI terminology after reading Jordan's post[1]. I don't agree with everything he writes, but I'm also not thrilled with the term "dependency injection".

I'm going to use the term IoC going forward in this article, simply because that's the term I prefer. All examples are in Java, for simplicity, and also because most of the articles I read regarding DI/IoC are also using Java.

Testability and Maintainability

I agree that IoC makes unit testing easier, much easier, by allowing us to easily mock portions of our applications, as is nicely explained by Miško Hevery[5]. (JMock is a terrific mock library, btw) Repeatable unit testing is a huge advantage of IoC, but at the same time, it's also a huge disadvantage because IoC makes integration testing and debugging much more difficult. This is because it becomes much harder to trace through the code due to the decoupling.

Regarding decoupling, Jordan writes, "We need some coupling so that we can understand how classes relate to one another. Maintainers of a code base need to be able to discover how various classes relate to one another and be able to trace class usage and interdependence. Hiding all of this complexity in XML files and annotations leaves the application impenetrable."[1]

I've always been a big believer in "read the code" and I love to read code, even bad code, because much can be learned from code. "What happens when you read some doc and either it doesn't answer your question or is demonstrably wrong? In Linux, you say 'Linux sucks' and go read the code. In Windows/Oracle/etc you say 'Windows sucks' and start banging your head against the wall", wrote Denis Vlasenko on the lkml.[6]

The decoupled nature of IoC, though, can turn a simple code-reading into a huge time-sink. Rather than diving in for a good read, the developer struggles to find which concrete class is actually invoked, then must discover which project/package that code actually belongs to, and finally must locate the actual source code for that project/package in the revision control tree before she can even begin to read the code.

I've experienced this first-hand in several different projects where I've taken over enhancing some code after a developer left the company, and it can be an exasperating experience. An enhancement is requested, or a bug is logged. Let's assume it's a bug. I might have been given an exception stack trace, and that at least gets me to a source code file to start from. I usually find a nice set of unit tests that I can run and quickly discover that they all pass - no big surprise there. They're all tests using mocked systems, though, so I'm unable to immediately reproduce the bug aside from being able to write a cute mock test to simulate how the code would respond to that particular error input, since I can easily mock the error. That's nice, but not very useful if my goal is to stop the error from happening in the first place.

Which concrete class is the actual perp? That's where it gets tricky. Most of the time, the stack trace gives no clue. Reading the code and examining XML files (or whatever method was involved for configuring the concrete classes used) can be a huge waste of time, and turns into a sort of tedious breadth-first search.

Is there a more direct way to find the perp? The best workaround I've found is to become very good with the debugger, and many times that means the remote debugger, and stepping deeply into the code until the likely culprit is found. That process will give a class name and package, but there's still some detective work to discover what project that belongs to. If you use version control and have lots of different projects created over many years of development with similarly named Java packages, that can be a nightmare, so let's just hope you work for a highly organized company that has everything documented in great detail so that finding the source code is a breeze.

The ability to quickly gather information and understand a program by reading the code is degraded by IoC because of the decoupling. It's important to recognize both the advantages and disadvantages of using IoC in your projects. I am a fan of IoC, but I always stop to give consideration for what future torture I may be inflicting on myself or others when I'm designing a project and try to plot the course with the minimum future pain.

Summary

Miško Hevery asks us this question, "Should I be using dependency-injection?"[7] My answer to that is yes, no, maybe. The pains "injected" into code maintenance and integration testing by IoC aren't enough to be deal breakers, but they do point out the need for documentation and evaluation. Document what concrete classes are used for what functions, what packages they're in, where to find the tree in your source code repository. Make sure your documentation is easily accessible and up-to-date (my preference - a wiki, but that's for a separate post). Evaluate your project and ask if it would benefit from IoC. How will it be tested, maintained and used in the future? Use IoC when there's a good justification for using it and then use it responsibly, don't just use it because it's the big buzz word that everyone's using and it'll look good on your resume.

[1] Dependency Injection Makes Code Unintelligible
[2] Wikipedia: Inversion of control
[3] Wikipedia: Dependency injection
[4] Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern
[5] Miško Hevery: How to Think About the "new" Operator with Respect to Unit Testing
[6] Top 50 Linux Quotes of All Time, #10 [note lkml == Linux Kernel Mailing List]
[7] Miško Hevery: When to Use Dependency Injection

I prefer Linux over Windows and have preferred Linux for many years. The notebook computer that I use most of the time is running Ubuntu Linux . Linux has the tools I need. Linux, in particular, has the programming and networking tools that I need. Linux is just simply a superb environment for programming.

Adobe Flex is ActionScript programming. The Adobe Flex Builder, an IDE for building Flex applications, is based on Eclipse. Eclipse is an IDE that runs on many platforms, including Linux. Flash runs just fine on Linux (though Adobe has historically been somewhat slow to keep the Linux version up-to-date). I use Eclipse every day. I use Linux every day. I'm new to Flex, but find it fascinating and want to use Flex Builder.

To sum this up, Linux is an ideal programming platform, the tools required for Flex development (Flash and Eclipse) run happily under Linux independently, so why oh why is the Flex Builder not available for Linux?

I downloaded the trail version of Flex Builder to play around with, but to use it, I'm running VMware and have it installed in a Windows XP VM on my Ubuntu laptop – a painful, excruciating situation. So I ask Adobe to please, please, please let your Flex Builder run on Linux, too.

As soon as Adobe adds Linux support, I promise to be first in line to purchase Flex Builder for Linux.

From the site : "memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load."

My first software job was for a company that wanted to cache the Intranet for the enterprise, a sort of indirect competitor for Akamai. I loved the concept of what we were trying to do. It was fascinating and exciting. Sadly, we lost focus and spun our wheels and never really found what the potential clients were looking for. I've never stopped wishing we could have succeeded, though. I think if we had been clever enough to have invented memcached, we might have had more success as opposed to spinning our wheels on developing a custom file system. Ironically, just as we were fizzling out, memcached was coming to life.

Reference: Web Caching of Wikipedia

Here's the mission of the group as given on their wiki page: "The Java Women Network promotes collaboration amongst women who develop and use Java technology to increase the visibility of women's contribution, mentoring opportunities and professional networking."