The Artima Developer Community
Sponsored Link

Weblogs Forum
Introducing the Iterable Concept

16 replies on 2 pages. Most recent reply: Nov 14, 2005 12:01 AM by Christopher Diggins

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 16 replies on 2 pages [ 1 2 | » ]
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Introducing the Iterable Concept (View in Weblogs)
Posted: Nov 9, 2005 8:54 PM
Reply to this message Reply
Summary
In the STL there exist numerous concepts such as Random Access Containers, and Back Insertion Sequences. Boost has introduced several improved Range concepts. I've got a new one for the list, the Iterable concept.
Advertisement
As the description of Random Access Containers and Back Insertion Sequences at SGI.com will reveal, the C++ STL concepts are very complex. Boost has improved the situation somewhat with the introduction of the Range concepts and library.

All of these concepts are built on the idea of iterator pairs, representing a range of values. This framework, which while being extremely powerful and flexible, is more complex than is needed in some (many?) scenarios. When studying Scala -- which is arguably the only truly multi-paradigm language -- I realized that a Generic Programming framework can be built for collections from a single concept, which, for lack of a better name, I am currently calling the Iterable concept. An Iterable concept is as follows (written in imaginary-Heron):

concept Iterable {
  types {
    value_type;
  }
  signature {
    for_each[Procedure[value_type] P](P proc);
  }
}
In pseudo-C++ this translates to roughly:
concept Iterable  {
  public {
    typedef value_type;
    template<typename Procedure>
    void for_each(Procedure proc);
  }
}
The Procedure concept is simply a void function which takes only parameter, a reference to value_type.

This is an exceedingly simple concept. In order to model the Iterable concept a class has to only provide one typedef, and one member function. However, don't let the simplicity fool you. By taking lessons from functional techniques (mixed with value mutation), you can achieve very sophisticated code with relatively little work.

Example 1: Outputting all Elements from an Iterable

struct putter {
  putter(std::ostream& o, char delim = ' ') : out(x) { }
  template<typename T> void operator()(T& x) { 
    out << x << delim;  
  }
  std::ostream& out;
};

putter put(std::ostream& o) {
  return putter(o);
}

template<typename Iterable>
void print_iterable(Iterable& i) {
  i.for_each(put(std::cout));
}

Example 2: Concatenation of Iterable Collections

It is easy to concatenate two completely different Iterable collections, to create a new type which can be used whereever a Iterable is called for.
template<typename Iterable1, typename Iterable>
struct cat {
  cat(Iterable1& i1, Iterable2& i2)  
    : iterable1(i1), iterable2(i2) 
  { }
  template<typename Procedure>
  void for_each(Procedure proc) {
    iterable1.for_each(proc);
    iterable2.for_each(proc);
  }  
  typedef typename Iterable1::value_type value_type;
  Iterable1& iterable1;
  Iterable2& iterable2;
};

Example 3: Adapting a Container to an Iterable

Any class modeling a Container concept, can be trivially converted to an Iterable concept:
template<typename Container>
struct container_to_iterable {
  container_to_iterable(Container& x) : 
    container(x) 
  { }
  template<typename Procedure>
  for_each(Procedure p) {
    typename Container::iterator iter = container.begin();
    typename Container::iterator last = container.end();
    while (iter != last) {
      p(*iter++);
    }
  }
  Container& container;
}


Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Introducing the Iterable Concept Posted: Nov 10, 2005 5:53 AM
Reply to this message Reply
> All of these concepts are built on the idea of iterator
> pairs, representing a range of values. This framework,
> which while being extremely powerful and flexible, is more
> complex than is needed in some (many?) scenarios.
[...]
> The Procedure concept is simply a void function which
> takes only parameter, a reference to value_type.

As you say, your Iterable concept may be used in some cases (when iterating forward through a complete sequence/container), but can't be used for other things iterators are commonly used for, such as finding an element, and insert/delete.

However, because this operation is so common (iterating through a sequence), several languages have special constructs or functions for this, such as for_each(). There also exists a proposal for a "for_each" kind of extension to C++ (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html), with a syntax like:

for(int i: container) // Print the elements of the container
std::cout << i;

This would work with any container/sequence having the right interface (including built-in arrays).

Regards,

Terje

Marcin Kowalczyk

Posts: 40
Nickname: qrczak
Registered: Oct, 2004

Re: Introducing the Iterable Concept Posted: Nov 10, 2005 7:17 AM
Reply to this message Reply
In order to see a weakness in this interface, please try to implement "given two iterable objects, check if they yield equal sequences of elements" using this interface. Can you avoid producing all elements of one of sequences, which can be very long, and unnecessary if the difference would be near the beginning?

Note: it is possible if the language has first-class continuations (Scheme, Ruby, and I think some Smalltalks) or threads. This is quite a heavy machinery given the apparent simplicity of the task.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Introducing the Iterable Concept Posted: Nov 10, 2005 9:33 AM
Reply to this message Reply
> As you say, your Iterable concept may be used in some
> cases (when iterating forward through a complete
> sequence/container), but can't be used for other things
> iterators are commonly used for, such as finding an
> element, and insert/delete.

The same is true of a Container concept. No concept can (and should) do everything. The power of this concept comes from its simplicity. Consider a simple number generator:


struct int_range {
typedef int value_type;
int_range(int x, int y) : first(x), last(y) { }
template<typename Procedure>
void for_each(Procedure p) {
int n = first;
while (n != last) {
p(n++);
}
}
int first;
int last;
}


To model a Container concept is a heck of a lot more work.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Introducing the Iterable Concept Posted: Nov 10, 2005 9:48 AM
Reply to this message Reply
> In order to see a weakness in this interface, please try
> to implement "given two iterable objects, check if they
> yield equal sequences of elements" using this interface.
> Can you avoid producing all elements of one of sequences,
> which can be very long, and unnecessary if the difference
> would be near the beginning?

You can't easily do such a thing, but I would not characterize that as a weakness in the interface. That is just the way the thing is designed. Positional control (through the use of iterators or indexes) is relinquished for the sake of simplicity. Most advantages of the Iterable concept are as a direct result of not providing iterators/indexers.

It is possible though to do it using threads, though it ain't pretty in C++.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Introducing the Iterable Concept Posted: Nov 10, 2005 10:10 AM
Reply to this message Reply
> In order to see a weakness in this interface, please try
> to implement "given two iterable objects, check if they
> yield equal sequences of elements" using this interface.
> Can you avoid producing all elements of one of sequences,
> which can be very long, and unnecessary if the difference
> would be near the beginning?

I just realized I may have mistakenly given the impression that I think Iterable can fully replace positionally based concepts such as the STL concepts, and the Boost Range concepts. It is intended as more of a supplement.

Sorry if there was confusion.

Now the Indexable concept on the other hand might provide a useful foundation for an alternative framework to STL concepts:


concept Indexable {
types {
Value value_type;
Incrementable index_type;
}
signature {
low() : index_type;
high() : index_type;
get(index_type i) : value_type;
set(index_type i, value_type x);
}
}

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Introducing the Iterable Concept Posted: Nov 10, 2005 1:42 PM
Reply to this message Reply
> > As you say, your Iterable concept may be used in some
> > cases (when iterating forward through a complete
> > sequence/container), but can't be used for other things
> > iterators are commonly used for, such as finding an
> > element, and insert/delete.
>
> The same is true of a Container concept. No concept can
> (and should) do everything. The power of this concept
> comes from its simplicity. Consider a simple number
> generator:
>
struct int_range {
> typedef int value_type;
> int_range(int x, int y) : first(x), last(y) { }
> template<typename Procedure>
> void for_each(Procedure p) {
> int n = first;
> while (n != last) {
> p(n++);
> }
> }
> int first;
> int last;
> }
Let's test this code with some of the simplest code I can come up with, for e.g. printing out the numbers:
void print(int n)
{
std::cout << n << " ";
}

int main()
{
int_range r(1,11);

r.for_each(print);
}
Your code is about 15 lines (not counting access specifiers, braces, and blank lines). Now let's do the same with STL. One way may be:
class generator
{
public:
generator(int initial) : i(initial) {}

int operator()() { return i++; }

private:
int i;
};

int main()
{
typedef std::ostream_iterator<int> out;

std::generate_n(out(std::cout," "),10,generator(1));
}
This code is 7 lines (same counting method as above), half of your code.

> To model a Container concept is a heck of a lot more work.

No, about half of it. ;)

Speaking of simplicity, let's look at your code examples in the blog entry (by the way, your code doesn't compile as it stands. I recommend that you try compiling your code before posting it in a blog):

Example 1: Outputting all Elements from an Iterable

Let's look at the simple example of outputting the elements of an array. Using your code, and making an "iterable" class to wrap the array (trying to make it as simple as possible), I came up with this:
struct putter {
putter(std::ostream& o, char d = ' ') : out(o), delim(d) { }
template<typename T> void operator()(T& x) {
out << x << delim;
}
std::ostream& out;
char delim;
};

putter put(std::ostream& o) {
return putter(o);
}

template<typename Iterable>
void print_iterable(Iterable& i) {
i.for_each(put(std::cout));
}

template<typename T,int Size>
class array_wrapper
{
public:
array_wrapper(T(&array)[Size]) : array(array) {}

template<typename Procedure>
void for_each(Procedure p)
{
std::for_each(array,array+Size,p); // (*)
}

private:
T (&array)[Size];
};

int main()
{
int array[]={1,2,3,4,5,6,7,8,9,10};

print_iterable(array_wrapper<int,10>(array));
}
(*) Notice the irony, here? :) A for_each() inside a for_each()...

That's about 20 lines (again, not counting access specifiers, braces and blank lines). Using idiomatic C++ and STL, you can get the same effect as the above, with just three lines:
int main()
{
int array[]={1,2,3,4,5,6,7,8,9,10};

typedef std::ostream_iterator<int> out;

std::copy(array,array+10,out(std::cout," "));
}
It doesn't need to be more complex, you see... And you're the one bringing up the simplicity argument. ;)

Don't be so quick to diss STL, before you've really learned what it can do.

Furthermore, as mentioned, the above is idiomatic, modern C++, so other C++ programmers familiar with the standard library should be able to understand it.

Note that, unlike your code, the above can be quite easily changed to e.g. write the elements in some other way, such as backwards (and without touching the container itself!):
  std::reverse_copy(array,array+10,out(std::cout," "));
And so on...

The STL stands on four "pillars":

- Containers (or more generally, sequences)
- Iterators
- Algorithms
- Function objects

As you know, iterators provide the link between containers and algorithms, and function objects modify the behaviour of the other components.

This means that these four are decoupled from each other, each representing a single concept. What you've done is to remove the iterator "decoupling", and thereby tied together the container and the algorithm, so that changes to either need to change the container/algorithm class. Not my idea of simplicity, cohesion and decoupling.

Regards,

Terje

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Introducing the Iterable Concept Posted: Nov 10, 2005 3:01 PM
Reply to this message Reply
<snip>
> This code is 7 lines (same counting method as
> above), half of your code.

With all due respect Terje, this is an irrelevant and weak comparison. You are ignoring the lines of code in the STL itself. You also miss my point that you can save a lot of code by modeling Iterable instead of modeling a Container, in a collection class.

> > To model a Container concept is a heck of a lot more
> work.
>
> No, about half of it. ;)

To write a class X which models a Container ( http://www.sgi.com/tech/stl/Container.html ), you would have to at the very minimum write:


struct MyContainer {
typedef fu value_type;
typedef fu iterator;
typedef fu const_iterator;
typedef fu reference;
typedef fu const_reference;
typedef fu pointer;
typedef fu difference_type;
typedef fu size_type;
MyContainer(const MyContainer& x);
MyContainer& operator=(const MyContainer&);
iterator begin();
const_iterator begin();
iterator end();
const_iterator end();
size_type size();
size_type max_size();
bool empty();
void swap(MyContainer& a);
}


Compare that with the Iterable concept:


struct MyIterable {
typedef fu value_type;
template<typename Procedure>
void for_each(Procedure p);
}


> Speaking of simplicity, let's look at your code examples
> in the blog entry (by the way, your code doesn't compile
> as it stands. I recommend that you try compiling your code
> before posting it in a blog):

They are only intended as pseudo-code snippets. I am working on a fully tested proof-of-concept.

<snip>
> That's about 20 lines (again, not counting access
> specifiers, braces and blank lines). Using idiomatic C++
> and STL, you can get the same effect as the above, with
> just three lines:
>
int main()
> {
> int array[]={1,2,3,4,5,6,7,8,9,10};
>
> typedef std::ostream_iterator<int> out;
>
> std::copy(array,array+10,out(std::cout," "));
> }
It doesn't need to be more complex, you see... And
> you're the one bringing up the simplicity argument. ;)

I don't buy this kind of proof-by-example. It demonstrates little, and is misleading. I also think it would be only fair to compare high-level notations such as (ootl being the namespace for a framework built on new concepts such as Iterable, Indexable, Stackable):

int main()
{
int array[]={1,2,3,4,5,6,7,8,9,10};
ootl::range_to_iterable(array, array + 10).for_each(ootl::out(std::cout, " "));
}


Or better yet:

int main()
{
int array[]={1,2,3,4,5,6,7,8,9,10};
ootl::array_to_iterable(array, 10).for_each(ootl::out(std::cout, " "));
}


However, this alone, like your example, doesn't show anything meaningful. Either way I am more concerned with the complexity of modeling the concepts.

> Don't be so quick to diss STL, before you've really
> learned what it can do.

I am very aware of what can be done with the STL. Don't be so quick to assume that the STL doesn't make any trade-offs and represents the best design for all possible circumstances.

> Furthermore, as mentioned, the above is idiomatic, modern
> C++, so other C++ programmers familiar with the standard
> library should be able to understand it.

I don't buy this argument neither. Being idiomatic is not an advantage from my point of view.

> Note that, unlike your code, the above can be quite easily
> changed to e.g. write the elements in some other way, such
> as backwards (and without touching the container
> itself!):

> std::reverse_copy(array,array+10,out(std::cout,"
> " "));
And so on...

That is definitely something which is severely limited by a Iterable concept. But again, this isn't a fair comparison because a Iterable concept is more closely related to a Forward Container, which itself has the same drawback.

> The STL stands on four "pillars":
>
> - Containers (or more generally, sequences)
> - Iterators
> - Algorithms
> - Function objects
>
> As you know, iterators provide the link between containers
> and algorithms, and function objects modify the behaviour
> of the other components.
>
> This means that these four are decoupled from each other,
> each representing a single concept. What you've done is to
> remove the iterator "decoupling", and thereby tied
> together the container and the algorithm, so that changes
> to either need to change the container/algorithm class.

Yes I agree that this is precisely what I have done, and intentionally so.

> Not my idea of simplicity, cohesion and decoupling.

Here is where I disagree, I think it is much simpler to have iteration managed within a collections member function, and not exposed to the programmer (sometimes). The STL is great at being decoupled, but it would be foolish to think that extreme decoupling has no downside. One downside is complexity.

I also argue that by placing the iteration within a single method is in fact more cohesive. I like the following definition of cohesion:

"A measure of the extent to which related aspects of a system are kept together in the same module, and unrelated aspects are kept out".

Iteration is arguably very closely related to collection management, and deserves to be kept together in the same place. This is of course highly subjective, and not something which I would debate vigorously.

There are other properties of software which are important as well, such as the property of encapsulation. This property is severely violated by STL iterators, but is very well maintained by the Iterable concept.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Is this a fair comparison? Posted: Nov 10, 2005 3:14 PM
Reply to this message Reply
/*(snip) Your code is about 15 lines (not counting access specifiers, braces, and blank lines). Now let's do the same with STL. One way may be:

(snip)

This code is 7 lines (same counting method as above), half of your code.
*/

I understand that you did not count lines of code in the STL because the programmer isn't expected to type them. I'm curious if this is a fair comparison, since I'm not sure how much of the code presented in the example would come in a library and how much would be the responsibility of the programmer. I'm also curious if, perhaps, the Iterable concept would come with suporting functions (as the STL does) to reduce the example's line count.

Don't get me wrong -- I like the STL and would rather re-use it than re-build it. OTOH, I know there are some problems in the STL (the lack of lambda is the one I'm most familiar with (http://www.boost.org/doc/html/lambda/s03.html#id1150814)). I'm interested in articles like this one that identify perceived weaknesses in the STL and suggest improvements. Another article (that I disagree with BTW, because it doesn't take into account STL programming practices) is at http://people.debian.org/~aaronl/Usenix88-lexic.pdf . Even though I disagree with that article, it does start a conversation about lexical closures.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Is this a fair comparison? Posted: Nov 10, 2005 3:36 PM
Reply to this message Reply
> I'm interested in articles like this one that identify
> perceived weaknesses in the STL and suggest
> improvements.

Thanks Max.

<soapbox>
Something I really don't understand, is why people get so darn riled up everytime I poke their favourite golden calf with a stick. It's not like my article was a pointless attack on the STL. Its only technology people! It's not like I am not making "yo'mamma" jokes. The criticisms were only secondary to the fact that I was proposing a new concept which traded expressive power for simplicity. It seems that people are so caught up in defending their favourite technologies, that they steadfastly refuse to even try to look for the value within new ideas.

Furthermore, in my own defence, I want to point out that I used the STL so extensively in my chapter on Science and Mathematics for the C++ Cookbook ( http://www.cpp-cookbook.com ) that the reviewers suggested I make less use of it. Here I get accused of not knowing enough about the STL. Something backwards about that picture.
</soapbox>

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Introducing the Iterable Concept Posted: Nov 10, 2005 4:15 PM
Reply to this message Reply
> <snip>
> > This code is 7 lines (same counting method as
> > above), half of your code.
>
> With all due respect Terje, this is an irrelevant and weak
> comparison. You are ignoring the lines of code in the STL
> itself.

I'm not igoring it, but I think "client code" (the code you have to write yourself) is way more important than any library code you happen to use.

> You also miss my point that you can save a lot of
> code by modeling Iterable instead of modeling a Container,
> in a collection class.

With all due respect, yourself, I responded with an alternative to a concrete use case. You may make as elaborate examples as you want, but they should be real, as in a concrete example of something that works, not a thought-experiment.

I showed in my example that one answer to your question is "Mu!" :) Which is an expression that Kevlin Henney is fond of, and it means basically "unasking the question". The point is that you _don't need to_ implement a container, to solve the problem you posed.

> > That's about 20 lines (again, not counting access
> > specifiers, braces and blank lines). Using idiomatic
> C++
> > and STL, you can get the same effect as the above, with
> > just three lines:
> >
int main()
> > {
> > int array[]={1,2,3,4,5,6,7,8,9,10};
> >
> > typedef std::ostream_iterator<int> out;
> >
> > std::copy(array,array+10,out(std::cout," "));
> > }
It doesn't need to be more complex, you see...
> And
> > you're the one bringing up the simplicity argument. ;)
>
> I don't buy this kind of proof-by-example. It demonstrates
> little, and is misleading.

You claimed the STL made writing code more complex than needed to. I showed examples where the resulting code was smaller (and arguably simpler, for someone knowing STL), than your alternative.

Why do you think this demonstrate little, and why is it misleading? We're discussing concrete examples _that you used in your own argumentation_!

> I also think it would be only
> fair to compare high-level notations such as (ootl being
> the namespace for a framework built on new concepts such
> as Iterable, Indexable, Stackable):

I agree, and if you have such a framework, show us the examples with it. I can only respond to what you showed.

> > Don't be so quick to diss STL, before you've really
> > learned what it can do.
>
> I am very aware of what can be done with the STL. Don't be
> so quick to assume that the STL doesn't make any
> trade-offs and represents the best design for all possible
> circumstances.

Have I said otherwise? If so, then please provide a quote. Are you saying I've assumed that? You say I shouldn't be quick to assume, and I don't, but if you claim I assume the above, you went into that trap, yourself, and assumed something I haven't claimed.

I think, however, that I've shown that, for use cases you've provided so far, there may be an at least as good solution using STL, as well.

There's a reason why STL has stood the test of time (while various other "collection frameworks" have come and gone), and this generality is one of them.

> > Furthermore, as mentioned, the above is idiomatic,
> modern
> > C++, so other C++ programmers familiar with the
> standard
> > library should be able to understand it.
>
> I don't buy this argument neither. Being idiomatic is not
> an advantage from my point of view.

Other programmers being able to understand the code without learning it from you not being an advantage? Heck, then there must be no advantage of knowing the language in the first place, so Heron and C++ have equal chance of being used on any project in the real world, right?

> > Not my idea of simplicity, cohesion and decoupling.
>
> Here is where I disagree, I think it is much simpler to
> have iteration managed within a collections member
> function, and not exposed to the programmer (sometimes).

I was not at least talking about a full system using this, where the decoupled elements of the STL means they can be combined in many ways, without having to write new code, or learn new components.

> The STL is great at being decoupled, but it would be
> foolish to think that extreme decoupling has no downside.
> One downside is complexity.

Here we need to thread carefully. What kind of complexity are we talking about? Is a system consisting of _one_ monolithic function consisting of several hundred lines of deeply nested code more or less complex than a program with, say 20 simple, focused functions, implementing the same functionality? The total complexity may be the same, even perhaps a little higher in the latter example (due to the decoupling you mention). However, what we perhaps most care about in any system is the _local_ complexity: what you need to understand, in order to understand a particular area of the code, and in _that_ case, the last example is likely enourmously less complicated. The last example lets us view the system as a whole, and drill in on the details, while the first example only provides a monolithic "blob".

The same goes for decoupling in general (as long as it's useful decoupling, i.e. where it makes sense): it may reduce local complexity, and increase chance of combination and reuse.

> I also argue that by placing the iteration within a single
> method is in fact more cohesive. I like the following
> definition of cohesion:
>
> "A measure of the extent to which related aspects of a
> system are kept together in the same module, and unrelated
> aspects are kept out".
>
> Iteration is arguably very closely related to collection
> management, and deserves to be kept together in the same
> place. This is of course highly subjective, and not
> something which I would debate vigorously.

One thing you may agree on, however, is that whether or not iteration is closely related to collection management, depends heavily on what you use the collection _for_. An associative map may have no use for iteration, for example, if all you use it for is looking up values using keys.

> There are other properties of software which are important
> as well, such as the property of encapsulation.

Indeed.

> This property is severely violated by STL iterators

Really? Could you explain why you think so?

Regards,

Terje

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Is this a fair comparison? Posted: Nov 10, 2005 4:46 PM
Reply to this message Reply
> This code is 7 lines (same counting method as above), half
> of your code.
>
> I understand that you did not count lines of code in the
> STL because the programmer isn't expected to type them.
> I'm curious if this is a fair comparison, since I'm not
> t sure how much of the code presented in the example would
> come in a library and how much would be the responsibility
> of the programmer. I'm also curious if, perhaps, the
> Iterable concept would come with suporting functions (as
> the STL does) to reduce the example's line count.

That's a valid point, something I also replied in my latest answer to Christopher. However, in order to assess that, we then need to see the code.

> Don't get me wrong -- I like the STL and would rather
> re-use it than re-build it. OTOH, I know there are some
> problems in the STL (the lack of lambda is the one I'm
> most familiar with

Yes. *sigh* That's a "sore point" of C++/STL (and Christopher thought I thought STL couldn't be improved... :) ). It's not that we don't want it in C++ (I'd certainly liked to have lambda support in some form), it's just that we hardly have the manpower in the standards commitee, to do all these things we'd like to have.

One thing I think is very important, however, is to, if at all possible, get support for "concepts" in the next version of the C++ standard. It seems there's enough of interested and competent people on the committee, that there's a good chance we get that. Support for "Design by Contract" would also be nice, but all these proposals compete for attention and manpower. Basically, if someone wants something in the language, they have to do the work in preparing and presenting it.

An alternative is to make your own language, as Christopher has done. :) However, one advantage with working with improving an existing language like C++, is that you have a chance to make a change for millions of people... (the C++ programmers). Hm, this starts to sound like a "join the committee"-ad. :)

Boost.Lambda is one possibility, but I've found it hard to use for more complex expressions. Essentially, you get a "language in the language", where the rules are different...

> Another article (that I disagree with BTW,
> because it doesn't take into account STL programming
> practices) is at
> http://people.debian.org/~aaronl/Usenix88-lexic.pdf .
> Even though I disagree with that article, it does start a
> a conversation about lexical closures.

I'll read up on that one, thanks for the link.

Regards,

Terje

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Is this a fair comparison? Posted: Nov 10, 2005 5:29 PM
Reply to this message Reply
/* Yes. *sigh* That's a "sore point" of C++/STL (and Christopher thought I thought STL couldn't be improved... :) ). It's not that we don't want it in C++ (I'd certainly liked to have lambda support in some form), it's just that we hardly have the manpower in the standards commitee, to do all these things we'd like to have.
*/

I'm still a comp sci student. I ran across Boost by pure happenstance, and from there I've been reading committee docs to get an idea of how things work in the "real world." And yes, there are several ways to understand real world.

I also find it interesting to compare C++'s evolution with Perl's. I recognize that Perl really has one implementation, so drastic changes are possible whenever Larry Wall gets a bee in his bonnet. It's interesting to compare that to the C++ Committee's need to make really big suggestions to all the implementors, and hope that they actually implement the new stuff. That, btw, is part of what I mean by the C++ Committee works in the real world.

/* (snip discussions about different techniques)
*/

As a comp sci student, I enjoy learning all these things that exist.

/* [me]: Another article (that I disagree with BTW, because it doesn't take into account STL programming practices) is at http://people.debian.org/~aaronl/Usenix88-lexic.pdf . Even though I disagree with that article, it does start a conversation about lexical closures.

[Terje]: I'll read up on that one, thanks for the link.
*/

Oops! I can't complain that a proposal doesn't take the STL into account when it was written about ten years before the STL!

I meant to link to a proposal I saw at the Committee's website. I'm having some difficulty finding it now, but I do remember it came from MIT and I had a sneaky suspicion that it was written by the GCC guys. In any case, it relied on functions and macros where objects and the STL were a much better fit. It then complained about the need of using functions and macros!

And even though I disagree with the premise, I am interested in the technique.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Is this a fair comparison? Posted: Nov 10, 2005 5:40 PM
Reply to this message Reply
> Something I really don't understand, is why people get so
> darn riled up everytime I poke their favourite golden calf
> with a stick.

Christopher... You may want to rethink what you say here, before continuing... If you're upset, then I suggest you cool off before posting...

What you write here is an "ad hominem" attack against me and others who have given you feedback on this issue. This is not very professional...

You may have seen in another thread, a little while ago, that I have, myself, _defended you_ from what I perceived as an unfair attack on you - an "ad hominem" (http://en.wikipedia.org/wiki/Ad_hominem) attack, for one thing. Where I gave a very sharp answer back to that someone... Thus, I don't think what you say here is a very nice way of showing "gratitude" for that...

Let me make one thing absolutely clear: My posting was 100% focused on _your arguments_ - not your person, or whatever. I gave arguments back, challenging your potentially bold claims. Now, normally, in professional discussion, there's nothing wrong with that, and when you come with bold claims (as you've often done through your blogs - that's also something that makes your blogs some of the ones I most like: they provoke my thinking), you should expect, and perhaps even be grateful for it, if someone challenges your claims, because it'll likely make _you_ think. This way, we all learn something.

But what do I get?

"Something I really don't understand, is why people get so darn riled up everytime I poke their favourite golden calf with a stick."

Do you think that's a nice thing to say? I certainly don't, and if this is going to be the level your discussions are to be at, then I have no interest discussing further with you.

Christopher... You've been open, and said - I think it was in a recent CUJ (like I said, I read your stuff, because it tend to be interesting :) ), that you've had a tendency to take criticism personally, even though it may have been meant purely as a technical discussion (like this one). Try to understand: I, and others, are here because we think we may all get something good out it.

Let me be open, as well, and say that I'm similar: I've tended to take things personal, when they weren't meant that way. However, the way I saw it, was that this discussion - up to your posting here, has been a purely technical, non-emotional argument. Yes, it may been a little "heated" (as in people saying bold things, etc.), and I enjoy a little heat, :) it shows that people are passionate about what they do, and that's a good thing, but nothing has been personal. Up to now.

Even if you don't understand someone's argument, or why they think as they do, it doesn't give you any right to ridicule them, as in your rant here.

> It's not like my article was a pointless
> attack on the STL. Its only technology people!

Have anyone said anything else? Christopher, I haven't seen any post in this thread that would indicate otherwise, but if you think so, feel free to mail me privately about it (tslettebo at broadpark.no), so we may clear up any misunderstandings. I feel I have responded to you with respect (if with a little sarcasm, to get a point across, such as that about the advantage of idiomatic use).

> It's
> not like I am not making "yo'mamma" jokes. The criticisms
> were only secondary to the fact that I was proposing a new
> concept which traded expressive power for simplicity. It
> seems that people are so caught up in defending their
> favourite technologies, that they steadfastly refuse to
> even try to look for the value within new ideas.

I find this quite offensive, and I don't think I'll say anything further at this point, lest I say something I'll regret.

Regards,

Terje

P.S.

> Here I get accused of not knowing
> enough about the STL. Something backwards about that
> picture.

I wrote: "Don't be so quick to diss STL, before you've really learned what it can do."

The reason I did, was that I thought you might not know about these alternatives (since they produced less "client code"). However, if you _were_ familiar with these ways of doing it, then I apologise as it was then an unfair remark, so I take it back.

Now, I hope you can also reevaluate what you yourself have said in this posting, once you've cooled off. For me, this was only intended as a respectful, technical discussion, but you've seemed to take much of it in a way that wasn't intended at all, and your derogative remarks above, in particular: "It seems that people are so caught up in defending their favourite technologies, that they steadfastly refuse to even try to look for the value within new ideas." is absolutely not true! And I would appriciate a retraction and apology for this one, if we are to have any more discussion.

Just because people don't agree with you, doesn't mean they "won't even look at new ideas." I read and learn about a bunch of great ideas all the time. But you need to use critical thinking to separate the wheat from the chaff, lest your head get filled with nonsense in no time.

I realise that you may feel frustrated that "people aren't getting it", but try to take it in a different way. It could be either or a combination, or anything else, of the following:

1) If they don't get it, what may I do, do make them get it?

2) Maybe _I_ don't get it? Maybe they have a point?

What you should absolutely _not_ assume is that people don't get it, because they haven't looked into it, or don't want to. Not until you have good reason to believe that. If you think so, you better argue why you think so, but I've seen no indication of that.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Is this a fair comparison? Posted: Nov 10, 2005 6:50 PM
Reply to this message Reply
I'm very sorry Terje for offending you. I honestly did not intend for my rant to be so offensive. Please accept my sincere apology. Furthermore I want to retract all of my comments in this thread, so that we can start fresh and have a good technical conversation later on, if you are so inclined.

"The reason I did, was that I thought you might not know about these alternatives (since they produced less "client code"). However, if you _were_ familiar with these ways of doing it, then I apologise as it was then an unfair remark, so I take it back."

I very much appreciate that apology, and that is what prompted my tirade. In the same way I made the incorrect assumption you weren't open to new ideas, it appeared to me that you were suggesting my new ideas were simply a result of my ignorance. That kind of statement I hear a lot, and it almost inevitably, makes me angry.

I have a lot of respect for you Terje, and I think you are a smart guy, but even more importantly in my mind, a nice and respectful person. I regret not having given you the benefit of the doubt, and I'm upset at myself for it. Please accept my apology.

Flat View: This topic has 16 replies on 2 pages [ 1  2 | » ]
Topic: No way to run a judicial system... Previous Topic   Next Topic Topic: Trees and Labelled S-Expressions


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us