A view on languages and where I’m focusing my development
A respected colleague, Bob Joslyn, asked in CDP if I had yet looked at a new language called Go. As of the moment I saw the question, my answer was no. But I just took a quick look and thought this blog would be a better place to post some thoughts on language, and development in general.
What’s Go?
If you said a game, you’d of course be correct but that’s not what I’m talking about here. You can find info on the Go language here. The Go language is an experimental, non Windows replacement for C. I say C and not C++ because Go isn’t object-oriented, which is one of the fundamental differences between C and C++. To me it looks like any other language out there, a cross between C, Delphi, Objective C, Java, PHP, and Pascal – but without OO. (Yeah, that’s lumping some apples and oranges…) I won’t attempt to define it further – as I said I just learned about it myself and I’m not qualified to discuss it. IMHO, from what I understand so far, the investment to learn it anytime soon isn’t balanced with a business case, so it’s not for me. Someone else might be interested if they’re doing new low-level development, and perhaps have an aversion to the sometimes arcane nature of C.
Over time I’ve learned over 20 programming languages and dialects, and these days I choose new ones carefully. In some cases I migrate due to factors like populariity and viability, so for example I dumped Perl for PHP and dumped Java for C# (a cross-platform implementation for which is Mono). I suppose the next new one I’d learn is Ruby if I had time. These days my personal R&D is on frameworks which make better use of the languages I know. Most developers are building higher-functionality libraries over the languages rather than going low-level with new languages. Examples include jQuery, ASP.NET MVC, Hibernate, and CSLA. (Yeah, I know those library/frameworks are for completely different purposes, that’s sort of my point.) The .NET Framework currently supports over 30 languages and they all interoperate with one another via the CLI (Common Language Infrastructure), so if someone is going to learn a new language, rather than Go, it may be more worthwhile to start with VB.NET or C#, get familiar with the underlying framework, then transfer that knowledge to something like F#, IronPython, or Boo. Or, if someone has specific projects in mind, look into the standards like PHP, Ruby, or Java.
Boo? Did I scare ya?
I mention Boo because, if you’re interested in languages for MV, Boo can be used to create “Domain Specific Languages“. So, one could create the BooMV language which specifically targets MV without looking like it’s working through a communications library like UO, QMClient, or mv.NET. I don’t have time for such things but if I were dabbling with languages that might be the direction I’d go.
For myself at the moment, I’m more focused on using what I know better, ensuring I can really dance with the tools I already know rather than going completely off the menu. That includes components of the .NET Framework including LINQ, ADO.NET Entity Framework, and nuances of ASP.NET including MVC. .NET 4 is coming up. That means C#4, ASP.NET 4, and updates across the board. These days it’s tough enough to keep up with the dynamics of a single platform. Speaking of “dynamics”, Dynamic Programming is the focus of C# 4.0, and this is a big topic unto itself. With so many things going on with the platforms I already use, adding more tools to the kit at this point is almost counter-productive – which is why I’m not too interested in Go, and I still haven’t picked up on Ruby yet.
I’m also writing extensions to improve code libraries that I use, and building new libraries with C# to support open API’s. As an example, I just published a library to help developers use the Twilio service. As another example, I’ve been dabbling with extensions for mv.NET, and will probably create a set of extensions for the new .NET library for D3 from TigerLogic.
Libraries, APIs, and Mashups
And that brings me to a final topic. Joe Mayo refers to this as Glue in a recent blog. (Joe spreads himself around in articles, books, blogs, Twitter, and the open source project LinqToTwitter. You can find links to a lot of his writings here.) There are a ton of services out there on the web now, and most of them publish an API, an Application Program Interface. This allows people to develop new services against a “platform”. Examples of platforms include Twitter, FaceBook, MySpace, Google Apps, Amazon S3, and the aforementioned Twilio. These days, it’s not enough to publish software as a service (SaaS), you also need to publish your API so that developers will code against it to create their own offerings. The idea is to create great software that others can make greater. Building community around a platform, which includes valued customers is much better than simply selling software to individual sites.
(MV VARs should listen up here.) The software you create itself is only one component of the offering. Twitter isn’t just a web site. It’s a platform with lots of products developed to interface with the core. The same goes for all of the others mentioned, and perhaps thousands just like them. Business applications don’t need to just be sold as-is. The next generation of business applications should have an API which allows end-users to make use of the core business rules in creative ways that the original developers never considered. End-users are coming to expect this.
Here’s an idea: Rather than creating a GUI for an app, a VAR with a character-screen user interface (what I call a CUI) could create an API which allows end-users to create their own interfaces into the system. Pick/MV developers can only guess sometimes at what an end-user will want screens to look like, or what web services they might want. With an API exposing only specific fields and business rules, the VAR offers a whole new view on their application – and perhaps a new revenue stream as well. With an API, like FaceBook or Amazon or others, many developers can create entirely new libraries of extensions for an existing MV app – without even knowing that the back-end is MV or written in BASIC. That’s the beauty of an API – it hides the underpinnings.
That’s where the world seems to be going now, and that’s really what I’m watching now rather than new languages. Because the big deal now isn’t so much on new operating systems or languages – the challenge is about what we do with what we have.
If you’re interested in creating an API for your app, let me know. Think of it as your new MyGreatApp SDK (Software Development Kit). It can be a brand-new offering, a new bit of value-add in your Marketing materials and Sales presentations, a new way for existing end-users to get more from your app, and for new prospects to see value in your app compared to your competitors. Whether you’re talking with Nebula R&D or someone else, consider partnering with a developer to create an SDK for your app, and partner with them to sell and support the software for your clients. You can do this with one of your end-users, partnering on an SDK that meets their needs – with near guarantee that it will meet the needs of other clients as well. As you can see, there are various angles to this.
Summary
Well, I know I just flew from Here to There, but it’s all related. Where are you focusing your research time? Where are you making investments in your app? What can you learn from the rest of the world on these topics? There’s only so much time we can spend on this tech stuff. Spend it wisely.