Boost and Elevate, Similarities and Differences

[Nathan Lane]

I just found a link the Elevate on my VS2008 RSS feed today, checked
it out, and I am excited about it. I have heard of Boost. I know of a
couple of applications that use it, but I never really got into it
myself. I use Linq a lot as well as some other convenience
technologies in C#, and I've always thought that I felt like there
could be more. Maybe like MS stopped developing before the
brainstorming was complete. Naturally a project like Linq (Linq to
Objects, Linq to SQL, Linq to XML) needs user feedback before it can
be determined what value it provides to the developers.

I have just been going over what was said in the blog entry,
Introducing Elevate on Chris's blog, as well as the code in
Elevate.Guide. Now most of the projects I work on in C# are very
large, multi-project solutions, and so I was kind of surprised to see
that Elevate is just one solution with multiple sub folders, clearly
helping to identify the namespace architecture, while at the same time
it makes a lot of sense to me to provide just one assembly that
developers need to reference in their projects.

Looking at the architecture, I decided to look into Boost more.
Granted Boost is written in and for C++, and so the architecture would
likely need to be somewhat different. But it seems a little more
organized so far. I understand that some developers, like me, tend to
write - refactor - write - refactor as a project increases in size.
And since this project is relatively young (from what I've read, the
dates on everything and such), I'm sure that the architecture will
change as time goes on, and it may come to make more and more sense as
it is anyway. It seems like a good layout so far though.

I also delved into the road map link on the Elevate home page on
CodePlex. Short and sweet, I too am looking ahead to .NET 4.0 for the
anticipated features. I'm certain there will be many that I use and
some that I don't, but it looks very promising. I was extremely
excited with the 3.5 Linq release. You mention drawing inspiration
from F# on the road map, and on the blog entry, you mention Ruby and
Haskell as well. I'm and avid supporter of Ruby, never programmed in
F#, and I've heard a lot about Haskell but again never programmed in
it. I am just wondering if somebody could give a better idea of what
kinds of things are being thought about for inclusion from these
various languages. What is the more discrete goal in drawing
inspiration from them?

Thanks. I hope this turns out to be a huge success, and I would love
to get involved. I'm know I'm going to get some good use out of
Elevate.

[Nathan Lane]

Ah, looking more and more at the source of Elevate and thinking more
about how Ruby, Haskell, and F# fit into your design, as well as your
reference to the Boost C++ framework, I realized that your project,
while similar to Boost, is more of an in-the-spirit-of-Boost model.
Whereas Boost provides many utilities to make development in C++ using
common, yet not standards implemented patterns easier, Elevate seeks
to provide the same to a C# programmer. One basic example that I can
think of, as shown in all of your code, is the extension of a type,
such as String (alias string). I sometimes want to capitalize a
string, and for that I use a function that I wrote to determine
whether the first character of the string is a lowercase letter (and
not a digit or other symbol), and whether the string is more than one
character long, and not an empty string, then I proceed to capitalize
that string and return the result, or otherwise return the source. If
this were to become an addition to your library, I would not be
surprised. There are a number of string operations that I could see
being added as such.

I also see the inspiration from F# and Haskell, which I have not
looked into very deeply, as functional development extensions.

Anyway, I hope that this group picks up. I'm loving Elevate more and
more.

[Chris Marinos]

Nathan-

I think you've got the right idea about the kinds of things we want to see in Elevate.

For your question about the discrete things that we'd like to pull in from other languages, the answer is that we intentionally left that vague. To get specific about F#, I would like to see us capture all of the functions that they have for working with sequences captured in our APIs. For the .NET 4.0 version, this may just mean having C# friendly APIs that call out to the F# implementation.

I don't have as good of an answer for what we'd like to pull from Ruby, Haskell, Python, etc. This is mostly because I don't personally have as much experience with those languages. I do know that there are good ideas in those languages, and I'd like to incorporate as many of them as possible into C# with Elevate. We'd like someone to take a look at the standard libraries for these languages and pull over the useful bits that are missing from C#. That "someone" could just as easily be a developer from the community as it could be one of our team members.

Hope that helps to clear things up a bit.

-Chris

[Nathan Lane]

Wow, yes. That is a perfect explanation for all of my inquiries.
Thanks. One of my favorite things about Ruby is the "everything is an
object" design. Even native types have members. Now in C# they are
objects too, but most people don't try to use native types to perform
operations. And most native types aside from the alias string, which
is by far an exception, don't have many method attached to them. As an
example the native type int is also an alias for the object type
Int32. Using the type int or Int32 is synonymous as far as what is
available for class methods: CompareTo, Equals, GetHashCode, GetType,
GetTypeCode, and ToString. Likewise as far as static methods go they
are also the same: Equals, MaxValue, MinValue, Parse, ReferenceEquals,
and TryParse. All of these are very useful, but when we get into Ruby,
we get a whole bunch of useful methods that are not only available for
basic integer type variables, but for any variable, for example:

inspect - Returns a human readable representation of obj. If not
overridden, uses the to_s (ToString) method to generate the string.
chr - Returns a string containing the ASCII character represented by
the receiver‘s value.
even? - Returns true if int is an even number.
next, succ - Returns the Integer equal to int + 1.
odd? - Returns true if int is an odd number.
size - Returns the size in bytes of the object.
zero? - Returns true if int is equal to zero.
to_f - Converts int to a float.
to_s - Converts int to a string representation.
times - Produces an iterable sequence based on the value of int
starting with 0; used as: 5.times do |i| print i, " " end. The result
of such expression would be: 0 1 2 3 4
pred - Returns the Integer equal to int - 1.
upto - Produces an iterable sequence based on the value of int
starting with int and iterating up to and including the limit; used
as: 5.upto(10) do |i| print i, " " end. The result of such expression
would be: 5 6 7 8 9 10

Naturally, some of these are trivial calculations, like determining
whether an int value is zero: bool zero = intVal == 0; however having
these types of methods might just add some value to C#.

Nathan

On Oct 10, 11:12 am, Chris Marinos <cmmari...@gmail.com> wrote:
> Nathan-
>
> I think you've got the right idea about the kinds of things we want to see
> in Elevate.
>
> For your question about the discrete things that we'd like to pull in from
> other languages, the answer is that we intentionally left that vague. To get
> specific about F#, I would like to see us capture all of the functions that
> they have for working with sequences captured in our APIs. For the .NET 4.0
> version, this may just mean having C# friendly APIs that call out to the F#
> implementation.
>
> I don't have as good of an answer for what we'd like to pull from Ruby,
> Haskell, Python, etc. This is mostly because I don't personally have as much
> experience with those languages. I do know that there are good ideas in
> those languages, and I'd like to incorporate as many of them as possible
> into C# with Elevate. We'd like someone to take a look at the standard
> libraries for these languages and pull over the useful bits that are missing
> from C#. That "someone" could just as easily be a developer from the
> community as it could be one of our team members.
>
> Hope that helps to clear things up a bit.
>
> -Chris
>