Contents tagged with Ruby

  • Reminder: DC ALT.NET - 8/28/2008 - Ruby with Jeff Schoolcraft

    The August meeting for DC ALT.NET will be on August 28th, 2008 from 7-9PM.  Check our site and our mailing list for continuing updates and future meetings.  This month, Jeff Schoolcraft, ASP.NET MVP, will host a conversation on Ruby.  This will include some Ruby demos, a little bit of Ruby on Rails, as well as approaching it from the ASP.NET mindset.  This talk will go very nicely with our talk on ASP.NET MVC next month.

  • DC ALT.NET - 8/28/2008 - Ruby with Jeff Schoolcraft

    The August meeting for DC ALT.NET will be on August 28th, 2008 from 7-9PM.  Check our site and our mailing list for continuing updates and future meetings.  This month, Jeff Schoolcraft, ASP.NET MVP, will host a conversation on Ruby.  This will include some Ruby demos, a little bit of Ruby on Rails, as well as approaching it from the ASP.NET mindset.  This talk will go very nicely with our talk on ASP.NET MVC next month.

  • RubyNation - August 1st-2nd

    One of the interesting things happening in the Ruby community is the budding of regional Ruby conferences.  The Washington DC area is a pretty strong area for Ruby and Ruby on Rails as we have two Ruby user groups, Northern Virginia Ruby Users Group (NovaRUG) and the DC Ruby User Group (DCRUG).  With that, it was due time that DC got its own conference called RubyNation which will be held August 1st-2nd, 2008 in Herndon, Virginia.  What's great about this conference is that they are just trying to cover expenses and doing it for the love of the technology.


    They have a fantastic lineup of speakers which include:

    • Neal Ford - Keynote
      The debate between static and dynamic languages is a red herring, that the debate should be about Essence vs. Ceremony. Neal's keynote will illustrate the origins of these concepts, what they mean to modern software development, and why everyone is suddenly interested in dynamic languages like Ruby.

    • Stuart Halloway - Closing Keynote

    • David Bock - Tools for your Ruby Toolbox
      Rails may be the framework that turned many of us on to Ruby, but if you are using it for all of your server-related Ruby projects, you probably have a hammer and are seeing every problem as a nail. There are a number of smaller, tighter solutions to problem in this space, including GServer (built into the Ruby libraries), StaticMatic (a tool for generating a static site, but with all the templating goodness), and Sinatra, a small server with an awesome DSL for restful web services. We will spend a little bit of time of each of these, seeing how you can use each for a project where you might have previously considered Rails.

    • Giles Bowkett - Archaeopteryx: A Ruby MIDI Generator
      Archaeopteryx generates MIDI via Ruby to drive prosumer studio music software. It can generate hyperkinetic DJ mixes, infinite streams of ambient music for meditation, and original drum and bass rhythms.

    • Yehuda Katz - Living on the Edge
      Yehuda will walk you through some of the most exciting advances on the frontiers of Ruby, and provide a tour guide to those who want to walk the dangerous path. By the time the talk is over, you should feel comfortable downloading a bleeding-edge git-repository and installing it.

    • Glenn Vanderburg - The Culture of Innovation in Ruby
      The Ruby community is a wellspring of innovation at the moment; many people are doing fascinating new things with tools, libraries, and exploring new ways to use the language. This talk will explore some of the reasons for that innovative culture, and discuss ways we can benefit from it and keep it healthy.

    The event will be held at the Center for Innovative Technology (CIT) in Herndon, VA.  If you're familiar with the area, you'll notice it is the upside down oddly shaped building.  As you travel along Rt 28 or the Dulles Toll Road, you can't miss this building. 

    The address for the conference is:
    CIT Complex
    2214 Rock Hill Road
    Herndon, Virginia 20170

    Register today here!  Looking forward to this event.

    kick it on DotNetKicks.com

  • Static versus Dynamic Languages - Attack of the Clones

    Very recently there has been an ongoing debate between static and dynamically typed languages.  Since it seems that there has been some Star Wars references, I thought I'd add my own.  I originally wanted to cover this as part of the future of C#, but I think it deserves its own topic.  There have been many voices in the matter and I've read all sides and thought I'd weigh in on the matter.  I find myself with my feet right now in the statically typed community right now.  I do appreciate dynamic typing and it definitely has its use, but to me the static verification is a key aspect.  But, of course I do appreciate dynamic languages, especially those of the past including Lisp, Erlang, etc.

    Here are some of the salvos that have been fired so far:


    The Salvos Fired

    First, Steve Yegge posted a transcript from his talk at Stanford called "Dynamic Languages Strike Back".  In this talk, he talks about the history of dynamic languages, the performance, what can be done, and the politics of it all.  But at the end of the day, it comes down to the tools used.  It was a pretty interesting talk, but of course dredge up some pretty strong feelings.  In turn, you had responses from Cedric Beust coming out in favor of statically typed languages, and Ted Neward, Ola Bini and Greg Young analyzing the results of the two of them.  I won't get into the me too aspect of it all, but I encourage you to read the posts, but also the responses as well.

    I think Cedric lost me on the argument though is when he brought Scala into the argument.  To me, it was kind of nonsensical to mention it in this case.  And to mention that pattern matching is a leaky abstraction is unfortunate and I think very wrong.  The thing that functional languages give us is the ability to express what we want, and not necessarily how to get it.  Whether it puts it in a switch statement, an if statement, or anything else doesn't matter, as long as the decision tree was followed.  I don't see any leakiness here.  So, that was a bad aside on there.  I'm not a huge fan of Scala either, but for entirely different reasons.  First off, the type inference isn't really as strong as it should be and the syntax to me just doesn't seem to be as functional as I'd like.  F# and Scala tackle the problems in vastly different ways.

    Ola Bini, who has been advocating the polyglot programmer for some time, summed up the Steve versus Cedric posts very concisely in these two paragraphs:

    So let's see. Distilled, Steve thinks that static languages have reached the ceiling for what's possible to do, and that dynamic languages offer more flexibility and power without actually sacrificing performance and maintainability. He backs this up with several research papers that point to very interesting runtime performance improvement techniques that really can help dynamic languages perform exceptionally well.

    On the other hand Cedric believes that Scala is bad because of implicits and pattern matching, that it's common sense to not allow people to use the languages they like, that tools for dynamic languages will never be as good as the ones for static ones, that Java generics isn't really a problem, that dynamic language performance will improve but that this doesn't matter, that static languages really hasn't failed at all and that Java is still the best language of choice, and will continue to be for a long time.

    It seems that many of the modern dynamic languages are pretty flexible, but also not as performance oriented as the ones in the past.  Why is this?  It's a good question to ask.  And what can be done about it?  Of course Ola takes the tact, and I think correctly so that the tooling won't be the same or as rich for dynamic languages as it is for statically typed.  It simply can't be.  But that doesn't mean that it needs those tools won't exist, they'll just be different.  But at the end, Ola argues for the polyglot programmer and each language to its strength.  He talks a bit more about this with Mike Moore on the Rubiverse podcast here.

    Impedance Mismatch?

    There was a topic discussed at the ALT.NET Open Spaces, Seattle fishbowl on the polyglot programmer which talked about the impedance mismatch between statically typed languages and dynamic ones.  What's great is that Greg Young got together a session with Rustan Leino and Mike Barnett from Microsoft Research on the Spec# team, John Lam from the IronRuby team, and me.  It was a great discussion which revolved around the flexibility that dynamic languages give you versus the static verification that you lack when you do that.  And there is a balance to be had.  When you look at that flexibility that Ruby and other dynamic languages give you, also creates a bit more responsibility for ensuring its correctness.  It's a great conversation and well worth the time invested.  But one of the benefits we're seeing from CLR and in turn the DLR is the interop story so that you could have your front end be Ruby, service layer in C#, rules engine in F#, Boo for configuration and so on.

    Anders Hejlsberg on C# And Statically Typed Languages

    As I noted earlier, Anders Hejlsberg was on Software Engineering Radio Episode 97 to discuss the future of C#.  Although Anders has his foot firmly in the statically typed camp, he sees the value of dynamic dispatch.  The phrase that was used and quite apt was "Static Programming but Dynamically Generated".  I think the metaprogramming story in C# needs to be improved for this to happen.  Doing Reflection.Emit isn't the strongest story for doing this, and certainly not easy.

    Where I think that C# can go however is more towards making DSL creation much easier.  Boo, F# and others on the .NET platform are statically typed, yet go well beyond what C# can do in this arena.  Ayende has been doing a lot with Boo and making the language, although statically typed, very flexible and readable.  Ruby has a pretty strong story here and C# and other languages have some lessons it can learn.

    Another example is that Erlang is a dynamic language, yet very concurrent and pretty interesting.  C# and other .NET languages can learn a bit from Erlang.  I'm not sure Erlang itself will be taking off, as it would need some sort of sponsorship and some better frameworks before it could.  F# has learned some of those lessons in terms of messaging patterns, but no in terms of recovery and process isolation just yet.  I covered a bit of that on my previous post.

    Wrapping It Up

    It's a pretty interesting debate, and at the end of the day, it really comes down to what language meets your needs.  The .NET CLR has a pretty strong story of allowing other languages to interoperate that nicely compliments the polyglot.  But, I don't think that static typing is going the way of the dodo and I also don't think dynamic typing will win the day.  Both have their places.  Sounds like a copout, I know, but deal with it.  I have a bit more to discuss on this matter, especially about learning lessons from Erlang, one of the more interesting languages that has seen a resurgence lately.


    kick it on DotNetKicks.com

  • Metaprogramming in F#

    Tonight I will be heading to the Northern Virginia Ruby Users Group (NoVARUG) meeting tonight with Dave Thomas (PragDave) talking about metaprogramming in Ruby.  Should be a great time and I'm sure it will be full tonight.   For those interested in some introduction to metaprogramming in Ruby, here's a good link to help get you started.

    Metaprogramming in F#?

    One of the many things that has interested me in F# is that it was originally written as a language to write other languages.  This of course leads me to a discussion of F# and metaprogramming.  Is it a fit?  There are a couple of links well worth visiting and then at a future date, we'll come back to the subject.

    Before the links, most of the language oriented stuff comes from quotations.  Quotations are a little block of code which turns a particular piece of code into an expression tree.  This language tree can then be transformed, optimized and even compiled into different languages.  There are two types of these quotations, raw and typed.  Typed Quotations contain static typing information whereas the raw do not.  For a good introduction to these, check out Tomas Petricek's post here.

    I hope when I get a further chance, I'll dig into it a bit more here.  Until next time...

    kick it on DotNetKicks.com

  • NoVARUG Meeting April 16th - Dave Thomas (PragDave)

    The Northern Virginia Ruby Users Group (NoVARUG) will be holding their next meeting next week with a special speaker in Dave Thomas (PragDave).  Dave is in town teaching Advanced Rails Studio in Reston and will be kind enough to come talk about the Ruby Object model and how it facilitates metaprogramming.

    The details are as follows:

    Subject:
    Dave Thomas - The Ruby Object Model and Metaprogramming

    Date:
    April 16th, 2008 - 7-9PM

    Location:
    FGM Inc
    12021 Sunset Hills Road
    Suite 400
    Reston, VA 20190

    Hope to see a good crowd there!  I know I'm very interested in this subject and hope to dive deeper soon.  That reminds me I need to do some of metaprogramming in F# as well.

    kick it on DotNetKicks.com

  • Looking at DSLs in .NET

    As I've mentioned in recent posts such as here, here and here, I've been very interested in Domain Specific Languages (DSLs), especially with regards to F# and the DLR as well.  I recently re-listened to Software Engineering Radio Episode 52 with Obie Fernandez discussing DSLs in Ruby.   One of the things that attracted me to Ruby for this was the flexibility of the syntax for closures, mixins, etc.  Anyhow, it's a good listen and if you're new to the subject, you should give it a go.  Also, there is a slide deck of DSLs in Ruby which accompanies this episode which can be found here

    So, of course this gets me excited about the possibilities of seeing such things in IronRuby.  After seeing John Lam's presentations at MIX08 and listening to him on various podcasts, I'm excited that they are making such progress and hopefully get it into our hands soon.

    But, before we get too deep into things, I just want to take a step back and look quickly at what DSLs are.

    Internal and External DSLs?

    So, what are DSLs?  Well, to put it succinctly, it's a small language that's used for a very narrow task.  You can think of these as languages specific to a domain such as medical claims processing, stock trading and so on that only have meaning there.  These languages mean very little outside their problem domain and probably wouldn't make sense to anyone outside.  I'm very well aware of such things as I've worked in the medical claims processing industry and their terms, calculations and so on are very specific and to solve the problem well, it's best to suit the language best for expressing solutions.

    Martin Fowler wrote an article entitled "Language Workbenches: The Killer-App For Domain Specific Languages?" in which he talks about the history of DSLs especially in the Lisp world, but until now really haven't caught on.  Martin argues that XML structures such as configuration files, and so on qualify for that status, due to the fact that it is readable by a human and probably a domain expert as well.  But Lisp is well know for the Lex/Yacc parsing and expression trees and so on.

    Now the real interesting part comes in when we talk about internal versus external DSLs...

    External DSLs, quite simply, are those languages that are not in the same language as the main application itself.  This means that I could be free to write any free-form code I wish in order to suit my domain specific need.  This means that you need to write parsers and then ultimately would need to have a translation boundary between your DSL and your application.  This is where I think something like the Dynamic Language Runtime (DLR) could come into play.  What I mean by that is that if you write your language parser for the DLR, and I'll get into that shortly.  There is a bit of overhead with this of course, plus a good debugger and IDE, but with time and patience things like this can be overcome.  Extending such things as #Develop to encompass those pieces is feasible.

    Internal DSLs, on the other hand, are the little languages you can create inside your current language of choice.  Now languages such as Lisp, Ruby, Scala, Boo, and F# seem a bit more suited for these than the mainstream languages of C++, C# and Java.  Of course one of the bigger obstacles is the pesky curly brace which Ruby allows you to discard.  F# doesn't have a concept of this either, and instead the indentation scopes the values and functions and so on.  Martin has an interesting DSL written in Java that's interesting and could be better applied in different languages. 

    Thinking About The DLR

    As I said before, I'm pretty excited about the DLR and the flexibility it can give me as a software engineer looking for new and better ways to solve my customer's problems.  Not only that, but I'm a language geek at heart, what can I say?  I've posted several items on building on the DLR in the context of external DSLs as well as writing custom compilers for .NET.  Projects such as Irony also appeal to me in that way. 

    If you want to play around with the DLR, you can get it in one of two places, the IronPython download on CodePlex or on RubyForge with the IronRuby project.

    Martin Maly, a member of the DLR team has continued his posts about Building on the DLR.  He took some time off to work on some DLR related issues and now is back with some more posts. Let's continue where we left off last time:

    So, as you can see, the DLR has progressed quite a bit, and maybe creating that DSL using the DLR isn't so far off after all.  That is of course if you understand expression trees and so on.  But, the great part about the DLR is that they ship the ToyScript source code with this for you to play with and learn from when you download it.

    DSLs In Boo?

    Oren Eini, aka Ayende, has been working on a book about DSLs called "Building Domain Specific Languages in Boo".  Recently, he posted about some sample chapters now available online with the source code.  I highly recommend that you at least give it a look.  You now have access to the Early Access Edition, and of course you can buy it online.  It'll be interesting to see Ayende at ALT.NET Open Spaces, Seattle to see if he wants to cover more of this stuff. 

    If you're not familiar with Boo, it's one of Ayende's preferred languages.  Such tools as Binsor (The DSL for Windsor) were written in Boo.  If you're not familiar with the language, it has very similar syntax to Python and formats very nicely.  This easily fits Martin Fowler's category as an external DSL.  #Develop has some support for Boo to make it a first class language in the .NET family.  It also ships as part of the Castle Project.  Anyways, a quick sample of Binsor makes it look like a nice DSL for type registration in Castle Windsor in Boo Script:

      import Rhino.Commons
      logger = Component("console_logger", ILogger, ConsoleLogger)

    Check out the first chapter of Ayende's book which is available free online and explore it yourself for DSLs.

    DSLs in F#?

    Another part that had me intrigued was the possibilities of not only Boo to do this, but F# as well.  Robert Pickering covers this in his book, Foundations of F#.  If you pay attention to Chapter 11, he covers DSLs in F# and gives a few examples of how you can do so.  To me, it's pretty powerful because you have a lot of the built-in features of a functional programming language such as lists, pattern matching and so on.  Such examples as given are such things as the arguments parser in F# that is described in the Arg class in Microsoft.FSharp.Compatibility.OCaml namespace.  This allows you to parse well known data structures as first class citizens.  Martin Fowler also gave such an example from the article I quoted from above.  F# lends itself quite well to DSLs in regard to support for lambda expressions. 

    Don Syme also covers these topics in his book Expert F# in Chapter 9.  This covers more language oriented programming techniques, but you can scan some information about building DSLs in F#.  Some interesting parts of this come down to Active Patterns which I covered partially yesterday.  In the coming weeks, I hope to post some of my forays into this, taking some samples from the Ruby community and applying some of the same functionality in F#.

    Conclusion

    There is still much yet to be covered in this topic of DSLs in .NET languages.  We can go on and on with regards to internal and external DSLs and argue about which language is suited for each.   But in the coming weeks, I hope to take some samples and show how they can apply cleanly in F#, and probably run into some language problems where it might not be the best fit.  But, that's the fun part about it.

    kick it on DotNetKicks.com

  • Videos and Interviews from MIX08

    Well, I've had the urge to find all the videos I could and watch them to find out all the goodies I missed while not at MIX08.  If you missed any of the main sessions, you can find out more about them here.   Note that there are 88 sessions recorded here, so it's a lot of good viewing material. 

    Best of all are Scott Hanselman's MVC Videos can be seen here.  He also covers the MVC Mock Helpers which better allow for unit tests using various Mock frameworks including Rhino Mocks, TypeMock.NET and Moq.

    Dave Laribee
    was great on Twitter to make sure we were all kept up to date with all the good things that were happening.  Brendan Tompkins supplied Dave with a video phone so that he could capture impromptu videos and such.  But, best of all they were broadcasted live.  He was able to talk to guys like Rob Conery, Phil Haack, Steve Harman, Miguel, John Lam, Scott Hanselman and Josh Holmes.  Very cool stuff!  They were pretty good and entertaining, although the video wasn't always superb and sometimes you needed motion sickness pills.  But, the sessions of note are:

    More of them can be found here.  And it's enough to make Phil think that he has enough of a fidgeting problem...  Well, enjoy!

    kick it on DotNetKicks.com

  • Lang.NET Videos Now Available

    As you may have seen from previous posts, I have been covering Lang.NET and some of the interesting things that came from it.  I've always been interested in compilers, DSLs and such, and I hope you found them interesting as well.  I covered it these posts here:

    Anyhow, they have finally posted the videos from Lang.NET and are now available here for your review.  They have the talks from Anders Hejlberg for C#, Luke Hoban from F#, John Lam for IronRuby, Roman Ivantsov for Irony, Tomas Petricek for Phalanger and F# and so on.  Go and check them out.  Pretty cool stuff!

    kick it on DotNetKicks.com