Tuesday, September 04, 2012

Moving On

An update: I've left Embarcadero Technologies.

There's a lot of reasons. I was in the same position for more than six years, but I didn't necessarily want to be pigeonholed as a compiler guy. I was working remotely from London, with all the downsides that remote working entails: relative lack of camaraderie, out of sight / out of mind, disconnection from the actually quite vibrant local tech scene (I live about 3 miles from Old Street roundabout). But more than anything else, I'd fallen out of love with Delphi, and could no longer motivate myself to try and make it better - the gap I'd try to bridge would be a gap too far for the market to bear.

I'm currently taking stock, thinking about what I want to do next. No specific plans, but it's going to be fairly different than what went before!

Thanks Barry for adding and improving the language features to Delphi over the last few years. It's a shame you are moving on but you've got to do what makes you happy. You'll be a great loss to the Delphi community. Best of luck to you.

On another note, would you be able to elaborate as to the "gap" you were trying to fill and can you explain why you feel that the market would not be able to bear it? All the best.

Colin: by gap, I mean the distance between the established product of Delphi, and a language I'd be happy and proud to continue working on.

It's a fact that Delphi has been around for long enough that changing it significantly isn't really an option. You have to give people a path forward with their existing codebase. And it's not just customers; the product itself has lots of code doing a lot of stuff, and if the language is too different, the result would be an IDE and compiler and a few basic libraries, and that's it. Not a great business move.

Delphi is very procedural. It grew out of Pascal, a language designed in an era when memory was very expensive. So most of its core runtime is based around mutation and destructive updates.

But the longer I've been coding, the greater and greater benefit I see to more functional approaches - which pretty much require garbage collection - and persistent data structures like you see in Clojure.

I've also lost some of the object orientation religion I first picked up when I was in my teenage bedroom, figuring out how virtual method calls worked in my copy of Turbo Pascal 6. I remember the epiphanies of those days. But these days, I see the bureaucracy and busywork involved in creating class hierarchies, how it can fool you into thinking you're doing productive work when you're filling out various idioms and "patterns". Some problems - like GUI widgets - work really really well with OO. But others work far better with the functional approach, where the set of data structures is closed but the set of methods is open. Shoehorning these into OO results in ugly architectures with extra indirections.

Suffice it to say, if I was creating a language I was truly in love with, it would look quite different to Delphi.

Thanks Barry for clarifying the gap. Not being a compiler whiz, I've read that it is possible to do functional programming in C#. Apart from the barriers you mentioned such as GC and mutable values. Can you still follow a functional programming approach in Delphi with some discipline?

Last but not least the POW! project - stopped in 2khttp://www.fim.uni-linz.ac.at/pow/Pow.htmAn IDE preferring the more 'Borland' like interface (Turbo/Win) vs. the traditional Smalltalk/docked approach.

All the best to your future endeavors, the Delphi compiler will miss you, as we will your great work in the community of Delphi. It was a great honor meeting you a few years ago at the EKON in Frankfurt. I wish you all the best and hope to meet you some time again.

Thank you for your contribution to bringing DCC forward into the 21st century, and thanks for all the insightful blog posts. I understand why you are moving on; and a lot of great opportunities are yet to come. I wish you all the best!

@Pavel you say so, but when i re-surrected the topic about closures ("anonymous methods") in FPC, i saw that every one of core community saw closures having no value for Pascal at best or explicitly destructing the language at worse. So, i don't expect FPC to move that way, be it good or bad. However there still are Nemerle and Scala to blend OOP anf FP together :-)

@0xffff, "anonymous methods" in Delphi are admirably beautiful in documentation, are so natively pascalish... But they are hardly usably. Closures should be very short and concise. Delphi closures are nothing but boilerplate. They can only be usable for complex 5-15 lines procedures, but that scope is where it is time to just make a normal routine and give it a name. C++ closures are ugly to look, but they are practical more or less. Delphi closures are beautiful but impractical.

"I've also lost some of the object orientation religion I first picked up when I was in my teenage bedroom, figuring out how virtual method calls worked in my copy of Turbo Pascal 6. I remember the epiphanies of those days. But these days, I see the bureaucracy and busywork involved in creating class hierarchies, how it can fool you into thinking you're doing productive work when you're filling out various idioms and "patterns". Some problems - like GUI widgets - work really really well with OO. But others work far better with the functional approach, where the set of data structures is closed but the set of methods is open. Shoehorning these into OO results in ugly architectures with extra indirections."

I have a similar feeling. I don't about your new favourite language but maybe Google Go is worth a look. The concept is really appealing and IMO their willingness to keep things simple but effective is rarely seen today.

I wasn't know that you were working with Delphi team, but I know you from experts-exchange, when you was number 1 in Delphi area. I remembered that when I come to London in 2001 or 2002 I put a post in experts-exchange containing my telephone number in London, but unfortunately we didn't met.Motaz Abdel Azeemhttp://www.code.sd/eng/products.html