With the introduction of Domain Specific Languages (DSL's) like LINQ right into the .net languages themselves, we become capable of becoming more focused on the domain of the problem space to which we're developing solutions. We're able to do Domain Driven Design (DDD) at a language level, and that's cool!
What is really cool in addition, is that we don't lose out on the ability to go down to a lower level - the code we write with language-level DSL's is backwards compatible with previous versions of .net, and if we so wish, we can still program at a lower level. Hats off to Anders Hejlsberg and the rest of the teams at Microsoft for their design of LINQ. So it is really easy to make DDD a reality on your business projects today. (When you design the classes describing your business problem domain, you are in fact designing a DSL, but this DSL is confined to your problem space, where DSL's like LINQ are a bit more generic).
So languages are evolving into more high-level, generic DSL's, which is very difficult to do right, because by creating a DSL you immediately introduce constraints and limitations.
Where to might languages evolve next? One of the things that are very difficult to do right now is parallelism. Very few programmers can write solid multi-threaded, re-entering code. It's hard to write, and even more difficult to debug. (Ever tried re-creating state with multiple threads?!) For me it's hard just to think in terms of parallelism - the human brain just doesn't work that way!
For many years we saw the clock speeds of processors increasing exponentially, and then all of a sudden there was a slowdown; making the wafers on processors thinner and yet thinner are becoming constrained by the physical size of atoms! But we still want faster! So we are now seeing processors with multiple cores. More cores are being introduced per processor, and more multi-core processors are introduced per computer. (In fact, more computers are being introduced per computing-grid, but we'll talk about that another time!)
The next logical evolution for programming languages would be to bring parallelism concepts (like threading) to the language level. In fact, LINQ already addresses this somewhat with Parallel LINQ (PLINQ). Anders Hejlsberg: "With PLinq, effectively you write the code the same way, but we arrange for it to run on multiple CPUs".
PS - One library that we (Armand and myself) discovered while doing our Robotics talks at last year's Tech Ed, is the Concurrency & Coordination Runtime (CCR). In the world of robotics there are really many concurrent operations, where the results of one might effect those of another, or even require another to abort. The CCR is an API that manages threading operations very effectively, and can definitely be used outside of the world of robotics in your business applications today!
The amount that the US Department of Energy is spending on the development of nuclear war heads for FY2007, namely $23.4 Billion, is just about enough to give each of the 10 million starving people in the USA $2300 for the year. That's more than double the average (monthly) USA minimum wage!!
Ruby is one of those wonderful gems that has been getting people excited for quite some time, but it hasn't been until the Rails framework has been released that the majority of Ruby users fell in love with it. Developing with Ruby on Rails enables you to get fully functional web-apps up and running in literally no time. What's Rails? It's a brilliant MVC implementation, using the Active Record pattern to map domain objects to your persistence layer:
"Rails is a web-application and persistence framework that includes everything needed to create database-backed web-applications according to the Model-View-Control pattern of separation."
Most of the demos you'll see for Ruby on Rails (RoR) will be shown on a mac. The guys use Textmate and it all looks wicked-cool-and-mind-blowing. It's enough to make you run to the nearest apple store and buy a MacBook Pro.
But can RoR be done on Windows, and could it possibly be as ultra-cool? After reading lots of doom-foreboding posts about running Rails in Windows, and specifically IIS, you might loose heart. But fear not, me hearties, because it took about 5 minutes to get RoR running on my XPSP2 box.
-
Download and install InstantRailsThis will install
Apache HTTP Server,
mySql,
Ruby,
phpMyAdmin, the
InstantRails server management tool and some sample RoR apps. (This step takes care of just about most your required installations in one go).
Here's a screenshot to illustrate the simplicity of the InstantRails management application:
- Install mySql client tools (optional)
If you don't like phpMyAdmin, download the mySql client tools.
- Install RubyInSteel.
To enable you to develop in Ruby right from within Visual Studio, get your hands on this great tool from SapphireSteel. It allows you to create new Ruby-type projects from within Visual Studio 2005, following the Rails standards:
It gives you syntax-colouring, deployment options, issuing Rake commands, and the ability to watch variables at runtime, set breakpoints, step through code, etc:
Change your Ruby In Steel Configuration to point to the correct paths in the InstantRails install location. (You only need to change your MySQL- and Ruby paths).
Morfik's has this to say about their WebOS AppsBuilder (quite a mouthful):
WebOS AppsBuilder brings extreme simplicity to the design of sophisticated AJAX applications without compromising their functionality. You don't need to write any HTML, XHTML, XML, JavaScript or CSS. It has never been easier to create highly interactive web sites and applications - and you don't even have to learn a new language or new technologies to do it!
Their (patent pending) JavaScript Synthesis Technology generates pure HTML/JavaScript/CSS - you only have to write your code in your favourite OO language. (Well, that's if your favourite happens to be one of either Basic, C#, Java or Object Pascal!) You also manage and deploy to your webserver from within the IDE.
Sounds cool - check it out.