I’ve read a bit and played around with Scala and Arc recently. I always recommend to learn other languages. Nobody is forced to get productive tomorrow in a language one learns but it always makes you a better programmer. This sounds trivial but I often met programmers who did only Java or only PHP or … you name it. There is nothing wrong with focusing on a language and getting really good at it, but ignorance is wrong. A good programmer always wants to learn, he basically defines himself through his fast ability to adopt new stuff. Everytime I look at different languages outside of my daily scope (which is mostly PHP and C, Ruby and Python for fun), especially on those who look exotic from the first view, I get something better. When I’ve tried to learn Erlang – even I totally failed at really getting it – I looked completely different afterwards at PHP constructs like array_filter(), array_walk() and the general concept of callbacks. When you halfway know both worlds, the functional as well as the object oriented, you just get more effective in applying the adequate methodology to solve an issue.

Back to Scala. Scala comes with a really feature rich object model. It provides classes, a concept well known to those who do Java or C++. Classes and methods may even be abstract. So far nothing new. But Scala provides a language feature so called traits. It addresses the issue that single inheritance is often too limited when it comes to stable (and convenient) compositions while mixins as in Ruby or classical multiple inheritance as in Python induce fragile, hardly maintanable hierarchies. The answer are traits. Traits allow stable compositions. A trait is basically a container for functionality. A class may extend from multiple traits, rename or overrride methods. Think on a debugging functionality – in this case implemented as a debugging trait – which should be used in a number of classes while each class has its own hierarchy. The debugger is than easily composited with the debugging consumer class while the class hierarchy is kept and the composition is stable itself. In PHP we do big wrenches to do composition. We introduce broker components to handle composited objects and what not. Traits are an elegant solution to the problem, a really impressive language construct.
Scala also provides generics. Generics are datatypes that can take other types while keeping type safety. Think you have an array and can enforce it to only accept instances of the class “Foo”. C#, Java and C++ implement that concept for a long time but nevertheless it is really handy.
I’m not really sure, how handy that would be in practice, but Scala enforces to explicitly overrride methods. I have the feeling that after a while one would do “override def method()” with the same implicitness as we do it today. Maybe this feature will be good for teaching object oriented programming.
The general syntax is a best of both worlds, the Java and the Ruby world. It is also possible to reuse existing Java libraries in Ruby, which makes it pretty attractive and lowers the entry barrier as a full stack of libraries are already present.

Arc is the newest baby by Paul Graham, the inventor of the bayesian spamfilter which mildens the pain for everyone of us dealing with email. Graham loves Lisp and it relatives. This is why Arc is very lisp’ish including polish notation for mathematical expressions. Actually the code examples are so incredible short to do a lot of stuff I guess I will try some sort of prototyping with it in the future. The plan is to design Arc to be useful in 100 years. This means time for adoption.

The current discussion about whether or not to use Smarty nowadays misses the point as it may simply depend on the environment. In a small development team, up to five people or so, you could just use the template-alike PHP syntax as all parts of the application are written by the same people with more or less equally shared responsibilities. This is what I would call a “single hands” process. Everything is done by everyone (that’s a bit oversimplified as in such environments intuitive structures emerging but let’s take it for now). This kind oft environment can often be found in startups and the like. This is were the process is really hands-on, the development process is often relatively agile as everyone is the others neighbour and there is often no explicit design stage. This is were you just ask your mate “hey, what’s the name of this template variable”. Such an environment has a lot of advantages but for sure a lot of disadvantages, often in terms of quality.

In other environments where responsibilities are much finer grained and balanced, a template engine might become a structural element of the development process as it represents a responsibility split between collegues. A template language is in fact an API for the user interaction/frontend developer. An API is a small subset of the factual possibilities, and this is where a template language might represents organisation prinicples. We as software developers define our API to encapsulate richer functionality and provide access to a well-thought (yeah, hopefully) subset of modification paths we want to allow on purpose. Just because the other guy does not need to know about the ugly internals. A good template language is a small subset of the language environment and exposes only functions which are really needed for view generation.

Beneath that, a template engine can structure the adoption of a pattern. Think about the MVC pattern, which is nowadays halfway common in web development environments. A template language in an MVC-alike environment enforces the usage of the view as “just a view”. While you would need to establish rules and procedures which subset of PHP is allowed correct for templating, a template engine establishs this rules and procedures implicitly. The other side of “do not try to solve social problems technically” is “do not try to solve technical problems socially”.

Of course, there are a lot of personal targets everyone will have for the next year. Stop smoking is typical, not mine, even I’m smoking. But for those working in the IT industry especially as a developer, David Coallier has a few useful hints how to improve your work by improving yourself. It is really a must-read.

We have added a feature I call naive type detection/casting to Zend Framework’s Zend_Config. Per default Zend_Config is not aware of types, everything is a string (except the crappy auto-detection parse_ini_file() does, but that’s another – ugly – chapter). Our patch provides an opt-in feature to detect wheither something is an integer, a string, a float or a boolean. It does that when a value is fetched, which should be the fastest way (most of configuration values are fetched one time, during a page load). The related ticket is #2312 and the latest patch is available here.

PHP does not have different primitive types for arrays and structs. It is all an array. The only difference is, that a list contains just ascending integers as keys, starting from zero, the rest is a struct.

<?php
if (array_keys($array) === range(0, count($array) - 1)) {
    // Is an array
} else {
   // Is a struct
}

In the Zend Framework this differentiation is needed in the XmlRpc-component. I’ve submitted a patch to make it more efficient.

One thing I’ve learned is, that one of the hardest things to create are examples. Most people do not use examples as what they are, they use it as templates. So examples have side-effects. You write an example to demonstrate how a certain component works or should be used, but you did not follow the coding style of your organization unit. Developers then going to copy your stuff and bang, your errors are repeated again and again. Or, just do it like Yahoo: add a small piece of PHP for demonstration purposes and introduce a huge security problem. Here it is. Lucky for them, they seem not to use the same code in their live example.

In den letzten Stunden eher nicht geschlafen, sondern Neu.de mit an den Start gebracht.

Hier.

Heute, Zend Studio. Alles was ein PHP-Entwickler braucht.