Haskell's array libraries... are a mess. Specifically, there is now 
about half a dozen of them.

When I suggested that we should sort this stuff out and make one 
consistent library for handling arrays, the general reaction was "no, 
we're not going to do that. This is open-source. Competition is good. 
We're building a bazaar, not a cathederal."

Um, WTF? I just want to write a program that involves arrays. I 
shouldn't have to spent a week examining a dozen libraries that all 
provide similar-yet-slightly-different implementations of the same 
thing. Not if you want people to take Haskell seriously, at any rate...

I presume the remark is referring to the "cathederal and the bazaar" 
that is sometimes referenced in connection with OSS. Does anybody know 
what it says? (Presumably it claims that proprietry software is like a 
cathederal and OSS is like a bazaar or something...)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I presume the remark is referring to the "cathederal and the bazaar"
> that is sometimes referenced in connection with OSS. Does anybody know
> what it says? (Presumably it claims that proprietry software is like a
> cathederal and OSS is like a bazaar or something...)

My most profound apologies, but

http://tinyurl.com/d6sjjd

 - Ricky

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I presume the remark is referring to the "cathederal and the bazaar" 
> that is sometimes referenced in connection with OSS. Does anybody know 
> what it says? (Presumably it claims that proprietry software is like a 
> cathederal and OSS is like a bazaar or something...)

  WiyF: http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

-- 
                                                          - Warp

Post a reply to this message

> Haskell's array libraries... are a mess. Specifically, there is now about 
> half a dozen of them.

Not so different with C and all its derivatives (C++, C++ STL, C++ .net), 
there are many different array handling "libraries", fun if you work with 
code that uses all sorts of different approaches :-)

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > Haskell's array libraries... are a mess. Specifically, there is now about 
> > half a dozen of them.

> Not so different with C and all its derivatives (C++, C++ STL, C++ .net), 
> there are many different array handling "libraries", fun if you work with 
> code that uses all sorts of different approaches :-)

  Really? C has no array handling libraries whatsoever (standard C, that is).
The core language has exactly one type of array. (Ok, two if you count
dynamically allocated and statically allocated arrays as distinct, although
they behave basically in the exact same way.)

  The C++ standard libraries have two data containers which could be
considered "arrays" (std::vector and std::deque). Perhaps three if you
count std::string. They are pretty straightforward and well-defined.

-- 
                                                          - Warp

Post a reply to this message

>> Haskell's array libraries... are a mess. Specifically, there is now 
>> about half a dozen of them.
> 
> Not so different with C and all its derivatives (C++, C++ STL, C++ 
> .net), there are many different array handling "libraries", fun if you 
> work with code that uses all sorts of different approaches :-)

Yeah. It's a hoot. You use one library that uses array-X, and another 
library that uses array-Y, and now your program must waste time 
converting from one to the other. Great fun. :-/

It wouldn't be so bad if we were talking about complete libraries that 
differ stylistically or something. But we're not. We're talking about 
several libraries, each of which only covers about 20% of what you might 
like to do. But each library covers a different 20%. Which means you're 
virtually *forced* to use several of them at once... *sigh*

Apparently everybody else thinks this is "perfectly OK".

Post a reply to this message

>  Really? C has no array handling libraries whatsoever (standard C, that 
> is).
> The core language has exactly one type of array. (Ok, two if you count
> dynamically allocated and statically allocated arrays as distinct, 
> although
> they behave basically in the exact same way.)
>
>  The C++ standard libraries have two data containers which could be
> considered "arrays" (std::vector and std::deque). Perhaps three if you
> count std::string. They are pretty straightforward and well-defined.

Yep, and then when you start using .net managed C++ there is the original 
.net way of creating arrays, and then the new way...

The problem is when using pre-written code and you're not sure which method 
it's using, you have to search back for statements like this:

String[,,] s = new String[5, 3, 10];
vector<int> iV(x, y);
array<int>^myIntArray = {1,2,3,4,5};

Then try and work out what's going on...

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> Yep, and then when you start using .net managed C++ there is the original 
> .net way of creating arrays, and then the new way...

  But .NET is not standard C++.

-- 
                                                          - Warp

Post a reply to this message

>  But .NET is not standard C++.

What bit of "Not so different with C and all its derivatives" did you not 
get?

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  But .NET is not standard C++.

> What bit of "Not so different with C and all its derivatives" did you not 
> get?

  Check the thread topic.

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:

> Yeah. It's a hoot. You use one library that uses array-X, and another 
> library that uses array-Y, and now your program must waste time 
> converting from one to the other. Great fun. :-/
> 
> It wouldn't be so bad if we were talking about complete libraries that 
> differ stylistically or something. But we're not. We're talking about 
> several libraries, each of which only covers about 20% of what you might 
> like to do. But each library covers a different 20%. Which means you're 
> virtually *forced* to use several of them at once... *sigh*
> 
> Apparently everybody else thinks this is "perfectly OK".

Irony: Haskell was invented because there are numerous "competing" 
functional programming languages, and people wanted to concentrate their 
efforts on just one such language.

So having several different but essentially equivilent programming 
languages was "bad". But having several different but somewhat 
overlapping array libraries is "good" and even "to be encouraged". WTF?

Post a reply to this message

>> What bit of "Not so different with C and all its derivatives" did you not
>> get?
>
>  Check the thread topic.

Yes, and C++ .net has standard libraries, what on Earth is your problem, do 
you really not have anything better to do?

Post a reply to this message

Invisible wrote:

> So having several different but essentially equivilent programming 
> languages was "bad". But having several different but somewhat 
> overlapping array libraries is "good" and even "to be encouraged". WTF?

Sounds like they drank the OSS flavored kool-aid.

-- 
~Mike

Post a reply to this message

>> So having several different but essentially equivilent programming 
>> languages was "bad". But having several different but somewhat 
>> overlapping array libraries is "good" and even "to be encouraged". WTF?
> 
> Sounds like they drank the OSS flavored kool-aid.

I have no idea what the heck kool-aid is, but... yes.

Don was the person who rejected my suggestion for working on unifying 
the libraries. Don is also the guy who regularly posts graphs of the 
number of packages being submitted to the Haskell package database. 
(Because, after all, it's the number of packages that matters, right? 
Not, say, the quality of those packages or how many people they're 
useful to or even whether they compile at all...)

Don's position was that "the perfect container API hasn't been invented 
yet" and that we need to "experiment" and that these multiple different 
array libraries would "compete" for users and the best one would win. Or 
something like that.

 From where I'm sitting, we've got a library that does A, B and C, 
another one that does A, D and E, another that does C, D and F, and yet 
another that does X, Y and B. And I'd really like to just have a single 
library that does A through Z easily and without fuss. :-P

IMHO, "competition" only works if people actually have the time and 
inclination to try out all the alternatives and pick the one they like 
the best. That probably works for parser libraries. (Indeed, Haskell has 
at least two major ones - Parsec and PolyParse.) I'm not sure it works 
well for a bunch of array libraries when none of them covers more than a 
few use cases.

But hey, it's only my opinion. And I suck at Haskell, remember? :-S

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> What bit of "Not so different with C and all its derivatives" did you not
> >> get?
> >
> >  Check the thread topic.

> Yes, and C++ .net has standard libraries,

  Defined by which standard?

> what on Earth is your problem, do 
> you really not have anything better to do?

  Look who's talking. ;)

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:

>> Sounds like they drank the OSS flavored kool-aid.
> 
> I have no idea what the heck kool-aid is, but... yes.

Read http://en.wikipedia.org/wiki/Drank_the_kool-aid it's interesting, 
and gives the source for the expression.

> Don's position was that "the perfect container API hasn't been invented 
> yet" and that we need to "experiment" and that these multiple different 
> array libraries would "compete" for users and the best one would win. Or 
> something like that.

Interesting assertion ... I don't know what to say.

>  From where I'm sitting, we've got a library that does A, B and C, 
> another one that does A, D and E, another that does C, D and F, and yet 
> another that does X, Y and B. And I'd really like to just have a single 
> library that does A through Z easily and without fuss. :-P

No problem compartmentalizing libraries. But, you really don't need two 
libraries that do A, and three that do C, etc ...

> IMHO, "competition" only works if people actually have the time and 
> inclination to try out all the alternatives and pick the one they like 
> the best. That probably works for parser libraries. (Indeed, Haskell has 
> at least two major ones - Parsec and PolyParse.) I'm not sure it works 
> well for a bunch of array libraries when none of them covers more than a 
> few use cases.

How many libraries does it take to deal with such an elementary concept 
as an array? (I assume we're talking about what is essentially a vector, 
a list of values, no particular data structures like hash tables, linked 
lists and the sort ...)

> But hey, it's only my opinion. And I suck at Haskell, remember? :-S

Yeah, right .. Sounds like the Haskell community is dominated by a bunch 
of egos that have closed themselves off from any outside ideas and 
believe that what they think is right, and no one else is.

That's just the sort of thing that will cause a project to stagnate and 
die.

-- 
~Mike

Post a reply to this message

>> Yes, and C++ .net has standard libraries,
> 
>  Defined by which standard?

http://en.wikipedia.org/wiki/Standard_library

Post a reply to this message

>>> Sounds like they drank the OSS flavored kool-aid.
>>
>> I have no idea what the heck kool-aid is, but... yes.
> 
> Read http://en.wikipedia.org/wiki/Drank_the_kool-aid it's interesting, 
> and gives the source for the expression.

...OK, *now* I'm depressed. :-/

>> Don's position was that "the perfect container API hasn't been 
>> invented yet" and that we need to "experiment" and that these multiple 
>> different array libraries would "compete" for users and the best one 
>> would win. Or something like that.
> 
> Interesting assertion ... I don't know what to say.

While it's a reasonable theory, I don't think you can have competition 
between half a dozen semi-broken packages.

I mean, look at web browsers. There's IE, there's Safari, Firebox, 
Opera, etc. But imagine if there was one browser which could do HTTP and 
FTP, but didn't understand HTML. And another browser that understands 
HTML and CSS, but only handles HTTP and not FTP. Now imagine another 
browser that handles HTTP and HTML, but doesn't support forms, but does 
support Java... Would they "compete"? Or would everybody just concluse 
that this whole web dealy isn't worth the effort?

> No problem compartmentalizing libraries. But, you really don't need two 
> libraries that do A, and three that do C, etc ...

See above.

> How many libraries does it take to deal with such an elementary concept 
> as an array? (I assume we're talking about what is essentially a vector, 
> a list of values, no particular data structures like hash tables, linked 
> lists and the sort ...)

Well... Haskell is slightly unusual in that it prefers data structures 
to be immutable. Hence it offers immutable arrays. No other language 
does. Look at BASIC, Pascal, C, C++, C#, Java, Perl, Tcl, etc., and 
arrays are always mutable. Only in Haskell does such an animal as an 
immutable array exist.

The Haskell data structure of choice is a list or a tree, because these 
can be recursively defined. Arrays are not recursive, but it is possible 
in various ways to pretend that they are. Similarly, immutable arrays 
aren't particularly useful, but there are various ways to make mutable 
arrays look immutable while retaining efficiency.

So, to summarise, arrays are slightly tricky in Haskell. There are 
design choices to be made, and the optimal choice varies depending on 
what you want to do. By contrast, C arrays are "just arrays".

>> But hey, it's only my opinion. And I suck at Haskell, remember? :-S
> 
> Yeah, right .. Sounds like the Haskell community is dominated by a bunch 
> of egos that have closed themselves off from any outside ideas and 
> believe that what they think is right, and no one else is.

Either that, or I come across as sounding like an idiot so people ignore 
the content of what I'm saying.

Don and friends all seem like highly intelligent people. Maybe they just 
have other priorities or something, IDK.

> That's just the sort of thing that will cause a project to stagnate and 
> die.

Er, yeah.

But hey, it's already begun. Every day, mainstream programming languages 
continue to steal Haskell's inovative ideas. Maybe someday soon Haskell 
truly will wither and die. :-(

Post a reply to this message

Invisible wrote:

> While it's a reasonable theory, I don't think you can have competition 
> between half a dozen semi-broken packages.
> 
> I mean, look at web browsers. There's IE, there's Safari, Firebox, 
> Opera, etc. But imagine if there was one browser which could do HTTP and 
> FTP, but didn't understand HTML. And another browser that understands 
> HTML and CSS, but only handles HTTP and not FTP. Now imagine another 
> browser that handles HTTP and HTML, but doesn't support forms, but does 
> support Java... Would they "compete"? Or would everybody just concluse 
> that this whole web dealy isn't worth the effort?
> 
>> No problem compartmentalizing libraries. But, you really don't need 
>> two libraries that do A, and three that do C, etc ...
> 
> See above.
> 

Oh, so it's much worse that I thought.

>> How many libraries does it take to deal with such an elementary 
>> concept as an array? (I assume we're talking about what is essentially 
>> a vector, a list of values, no particular data structures like hash 
>> tables, linked lists and the sort ...)
> 
> Well... Haskell is slightly unusual in that it prefers data structures 
> to be immutable. Hence it offers immutable arrays. No other language 
> does. Look at BASIC, Pascal, C, C++, C#, Java, Perl, Tcl, etc., and 
> arrays are always mutable. Only in Haskell does such an animal as an 
> immutable array exist.
> 
> The Haskell data structure of choice is a list or a tree, because these 
> can be recursively defined. Arrays are not recursive, but it is possible 
> in various ways to pretend that they are. Similarly, immutable arrays 
> aren't particularly useful, but there are various ways to make mutable 
> arrays look immutable while retaining efficiency.
> 
> So, to summarise, arrays are slightly tricky in Haskell. There are 
> design choices to be made, and the optimal choice varies depending on 
> what you want to do. By contrast, C arrays are "just arrays".
> 

I see. So, essentially Haskell prefers to deal with data structures, 
rather than flat arrays?

> 
> Either that, or I come across as sounding like an idiot so people ignore 
> the content of what I'm saying.
> 
> Don and friends all seem like highly intelligent people. Maybe they just 
> have other priorities or something, IDK.
> 

Who knows...

>> That's just the sort of thing that will cause a project to stagnate 
>> and die.
> 
> Er, yeah.
> 
> But hey, it's already begun. Every day, mainstream programming languages 
> continue to steal Haskell's inovative ideas. Maybe someday soon Haskell 
> truly will wither and die. :-(

Yep, and I believe I use a few of Haskell's stolen features every day. 
I've learned to really appreciate C#'s lambda expressions :)

-- 
~Mike

Post a reply to this message

>> While it's a reasonable theory, I don't think you can have competition 
>> between half a dozen semi-broken packages.
>>
>> I mean, look at web browsers. There's IE, there's Safari, Firebox, 
>> Opera, etc. But imagine if there was one browser which could do HTTP 
>> and FTP, but didn't understand HTML. And another browser that 
>> understands HTML and CSS, but only handles HTTP and not FTP. Now 
>> imagine another browser that handles HTTP and HTML, but doesn't 
>> support forms, but does support Java... Would they "compete"? Or would 
>> everybody just concluse that this whole web dealy isn't worth the effort?
> 
> Oh, so it's much worse that I thought.

Er... yah.

> I see. So, essentially Haskell prefers to deal with data structures, 
> rather than flat arrays?

Not so much that... Haskell likes to deal with immutable data 
structures. That is, data structures that never "change". So to "change" 
your data structure, rather than modify it, you create a modified copy.

Which is greate if you're working with, say, a binary tree. You just 
copy the node that changed, and the parent nodes above it. (Any 
unchanged nodes can be "shared" between the new and old trees.) But for 
an array, you don't really want to copy a few million array elements 
every time somebody changes one freaking element!

Haskell already has facilities for modifying files on disk - and what is 
a disk file? It's an array of bytes. So you can use the same facility 
(i.e., monads) to handle mutable arrays - that is, arrays that you can 
modify in-place, like in every other programming language on earth. It's 
just a little less convinient to work with them that way.

As a result, you have libraries that try all sorts of tricks to either 
make immutable arrays fast, or make mutable arrays look like immutable 
ones... Then there are arrays specialised to particular element types... 
You get the idea.

>> But hey, it's already begun. Every day, mainstream programming 
>> languages continue to steal Haskell's inovative ideas. Maybe someday 
>> soon Haskell truly will wither and die. :-(
> 
> Yep, and I believe I use a few of Haskell's stolen features every day. 
> I've learned to really appreciate C#'s lambda expressions :)

You appreciate them *now*... Wait until you start using a language where 
the standard way to iterate over a data structure is to pass your "loop 
body" (as a lambda function argument) to the function that does the 
traversal. :-P

Post a reply to this message

Warp wrote:
> scott <sco### [at] scottcom> wrote:
>>> Haskell's array libraries... are a mess. Specifically, there is now about 
>>> half a dozen of them.
> 
>> Not so different with C and all its derivatives (C++, C++ STL, C++ .net), 
>> there are many different array handling "libraries", fun if you work with 
>> code that uses all sorts of different approaches :-)
> 
>   Really? C has no array handling libraries whatsoever (standard C, that is).

#include <string.h>
technically speaking. :-)

And you'd have to count malloc() and free() and memset() and all that stuff. 
It's not especially sophisticated, mind, but that counts, doesn't it?

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
>> Yes, and C++ .net has standard libraries,
>   Defined by which standard?

http://www.ecma-international.org/publications/standards/Ecma-335.htm

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Invisible wrote:
> Yeah. It's a hoot. You use one library that uses array-X, and another 
> library that uses array-Y, and now your program must waste time 
> converting from one to the other. Great fun. :-/

Could be worse. Could be Ada, where you have things like "library of arrays 
holding bytes in memory" and "library of arrays holding bytes from I/O 
operations" and they aren't the same and there's (AFAIK) no standard 
conversion functions.

Great, if your computer isn't using 8-bit bytes for memory. For all the rest 
of us, rather a PITA.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Mike Raiford wrote:
> Invisible wrote:
> 
>>> Sounds like they drank the OSS flavored kool-aid.
>>
>> I have no idea what the heck kool-aid is, but... yes.
> 
> Read http://en.wikipedia.org/wiki/Drank_the_kool-aid it's interesting, 
> and gives the source for the expression.

I thought the Heaven's Gate Away Team was the source of that expression, but 
I guess that was apple sauce.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Darren New wrote:

> Could be worse. Could be Ada, where you have things like "library of 
> arrays holding bytes in memory" and "library of arrays holding bytes 
> from I/O operations" and they aren't the same and there's (AFAIK) no 
> standard conversion functions.
> 
> Great, if your computer isn't using 8-bit bytes for memory. For all the 
> rest of us, rather a PITA.

That's advanced. :-D

OTOH, Haskell has something extremely similar... A library for arrays, 
and a seperate library for C-compatible arrays. The advantage being that 
the C-compatible version has fast I/O (wanna guess why?), but slow 
everything else...

Post a reply to this message

Invisible wrote:
> You appreciate them *now*... Wait until you start using a language where
> the standard way to iterate over a data structure is to pass your "loop
> body" (as a lambda function argument) to the function that does the
> traversal. :-P

C++0x?

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Invisible wrote:
> > You appreciate them *now*... Wait until you start using a language where
> > the standard way to iterate over a data structure is to pass your "loop
> > body" (as a lambda function argument) to the function that does the
> > traversal. :-P

> C++0x?

  It will indeed introduce core features which help a lot in this matter.

  For example the current standard library has a for_each() utility
function which in theory makes it easier to loop through an iterator
range and apply some function to each element. However, in practice
doing this is so cumbersome that few people prefer that over the more
traditional for loop. The reason is that there's no way in the current
C++ to embed the function into the for_each() call. Instead, you have
to write the function separately and give the name to for_each(). Great
if you already have such a function, but more trouble than it's worth
if you don't, which means you have to write the function.

  Also even if you go through the trouble of writing the function, it
still has its limits. Most prominently, it's not a closure, which means
that the function has no access to the variables in the scope where the
for_each() is executed. This reduces the usability of for_each() even
further, compared to the traditional for loop (where there rather
obviously *is* access to all the variables in scope).

  The C++0x (well, C++1x, really) standard will most probably introduce
lambda functions and closures, which addresses all these problems, and
more. You will be able to write your function directly as a parameter
to for_each() (or whichever generic function you want to use) as a
lamdba function, and this lambda function can (optionally) have access
to all the variables in scope.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> The reason is that there's no way in the current
> C++ to embed the function into the for_each() call. 

> that the function has no access to the variables in the scope where the
> for_each() is executed. 

Technically, these are both the same problem. :-)  I just thought that was 
an amusing observation when I saw it: C *does* have closures. It just 
doesn't have nested function scopes, so closures and pointers-to-functions 
are the same thing in C.

I really have to wonder, sometimes, how far people are going to mutate C++ 
before they just give up and decide they're done. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:

>   For example the current standard library has a for_each() utility
> function which in theory makes it easier to loop through an iterator
> range and apply some function to each element. However, in practice
> doing this is so cumbersome that few people prefer that over the more
> traditional for loop. The reason is that there's no way in the current
> C++ to embed the function into the for_each() call. Instead, you have
> to write the function separately and give the name to for_each(). Great
> if you already have such a function, but more trouble than it's worth
> if you don't, which means you have to write the function.

Indeed.

Haskell doesn't do anything that's "impossible" with other languages. 
You can do "functional programming" in any programming language that has 
a certain minimal set of features. It's just that in other languages, 
it's so much trouble to write your code in this way that no sane person 
would bother. (Quite apart from the compiler not being specifically 
optimised for it.)

>   Also even if you go through the trouble of writing the function, it
> still has its limits. Most prominently, it's not a closure, which means
> that the function has no access to the variables in the scope where the
> for_each() is executed. This reduces the usability of for_each() even
> further, compared to the traditional for loop (where there rather
> obviously *is* access to all the variables in scope).
> 
>   The C++0x (well, C++1x, really) standard will most probably introduce
> lambda functions and closures, which addresses all these problems, and
> more. You will be able to write your function directly as a parameter
> to for_each() (or whichever generic function you want to use) as a
> lamdba function, and this lambda function can (optionally) have access
> to all the variables in scope.

Mmm, interesting...

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I really have to wonder, sometimes, how far people are going to mutate C++ 
> before they just give up and decide they're done. :-)

  You make it sound like C++ is the only language which is constantly
being developed further by adding new features and new libraries (and
that this is somehow a negative thing?). That other currently used languages
are more or less "ready" and do not change much.

  Of course that's pure BS. Most currently popular languages are being
constantly developed further and their libraries enhanced. Look at Java, C#
or the .NET framework. It's not that long ago that Java didn't even have
generics. Now it has them. What is the current version of .NET? 3.something?
And each major version introduced new features. Look at Haskell: That's
probably one of the languages which is going through the largest amount
of development. Things which were hard or cumbersome to do in the past
are being fixed in newer versions by adding new features.

  Why do you deliberately make it sound like C++ is the only modern language
for which new features are being added? Why do you deliberately ignore all
the other languages for which the exact same thing is true? Why do you
deliberately make it sound like it's a *bad* thing that the language is
being developed further? Why are you deliberately singling out C++ from
all the other languages? Are you deliberately trolling?

  I don't know if I'm just being paranoid, but I honestly think that you
are doing this for the simple reason that you know that you are going to
troll me.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I really have to wonder, sometimes, how far people are going to mutate C++ 
>> before they just give up and decide they're done. :-)
> 
>   You make it sound like C++ is the only language which is constantly
> being developed further by adding new features and new libraries (and
> that this is somehow a negative thing?). That other currently used languages
> are more or less "ready" and do not change much.

No. But I think the current languages don't rewrite themselves as severely 
as C++ does. Other languages tend to add things, while C++ makes them 
fundamental parts of the language.  I'm assuming that the lambdas that C++ 
is adding won't be just a library bit. If it is, then bleh, but OK.

>   Of course that's pure BS. Most currently popular languages are being
> constantly developed further and their libraries enhanced. Look at Java, C#
> or the .NET framework. It's not that long ago that Java didn't even have
> generics. Now it has them.

Generics in Java are syntactic sugar. It still generates exactly the same 
code as the equivalent source done in the obvious way.

> What is the current version of .NET? 3.something?

Sure. And it has new syntax for new stuff, and it's cleanly integrated with 
the rest of the language.

>   Why do you deliberately make it sound like C++ is the only modern language
> for which new features are being added?

I'm not. I'm criticizing the way C++ adds new features, not that it does.

Every new feature in C++ seems to be hurt by (1) not wanting to pay any 
price if you don't use it, (2) not wanting to add any syntax for it, and (3) 
interacting poorly and confusingly with every other feature of the language.

If C++ added lambdas and they actually had things like pointers to stack 
frames and so on, I'd probably not be bothered. But I strongly suspect the 
lambdas they add are going to have so much brokenness to deal with the lack 
of automatic memory management and such that it's going to be harder to use 
lambdas than to just declare your own functions. And I'm betting the syntax 
will be so baroque it's going to be almost impossible to read without doing 
parsing in your head, too. Looking the little I did at the Boost lambda's, 
they're utterly awful compared to any other language with real lambdas built in.

>   I don't know if I'm just being paranoid, but I honestly think that you
> are doing this for the simple reason that you know that you are going to
> troll me.

No. I just don't like C++.  I think the way things get added to C++ is a bad 
thing for a language. They're trying to add sophisticated things from other 
languages on top of a base that really can't support it, so it's wobbling 
like an inverted pyramid, leaving the programmers to run around the outside 
propping it up with flying buttresses in their code.

When C# added LINQ, they didn't try to change the syntax of the language 
without modifying the compiler.

Python added a lot of really ugly stuff under the covers, too. But it's 
under the covers, and doesn't get in your way if you don't use it, and it's 
usable for more than just the one idea the person thought of who suggested 
it. And they didn't make the feature horribly ugly and difficult to use in 
order to save one indirection.


I hereby promise to try to remember to mention I'm trolling you if I ever 
make a post just to troll you, Warp. Fair? I can't promise I won't succumb 
to the urge to tweak you, but I'll try to remember to let you know I'm just 
teasing ya. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
>   The C++0x (well, C++1x, really) standard will most probably introduce
> lambda functions and closures, which addresses all these problems, and
> more. You will be able to write your function directly as a parameter
> to for_each() (or whichever generic function you want to use) as a
> lamdba function, and this lambda function can (optionally) have access
> to all the variables in scope.

std::vector<int> someList;
int total = 0;
std::for_each(someList.begin(), someList.end(), [&total](int x) {
  total += x
});
std::cout << total;

I read in a blog that Visual Studio already has *many* of those features
implemented (in a version not yet released even as alpha).

And gcc website has a list with C++0x implementation status :)

Post a reply to this message

Darren New wrote:
>>   Of course that's pure BS. Most currently popular languages are being
>> constantly developed further and their libraries enhanced. Look at Java,
>> C# or the .NET framework. It's not that long ago that Java didn't even
>> have generics. Now it has them.
> 
> Generics in Java are syntactic sugar. It still generates exactly the same
> code as the equivalent source done in the obvious way.

Lambdas are just syntactic sugar to defining an anonymous function, where
the code will end up stored somewhere else. Very similar to string literals
really.

> If C++ added lambdas and they actually had things like pointers to stack
> frames and so on, I'd probably not be bothered.

std::for_each(someList.begin(), someList.end(), [&](int x) {
  total += x
});

"The specific internal implementation can vary, but the expectation is that
the lambda function will store the actual stack pointer of the function it
is created in, rather than individual references to stack variables."

> Looking the little I did at the Boost lambda's, they're utterly awful
> compared to any other language with real lambdas built in.
[...]
> When C# added LINQ, they didn't try to change the syntax of the language
> without modifying the compiler.

What makes you think C++0x won't modify the compiler?! *Boost* tries to add
complex stuff without modifying the compiler. C++0x adds stuff to the core
syntax, not via a dozen stacked templates with operator overloads.

Post a reply to this message

Nicolas Alvarez wrote:
> Lambdas are just syntactic sugar to defining an anonymous function, where
> the code will end up stored somewhere else. Very similar to string literals
> really.

Uh, no, not really. They're only anonymous functions if you don't have any 
free variables, at which point why bother?

>> If C++ added lambdas and they actually had things like pointers to stack
>> frames and so on, I'd probably not be bothered.
> 
> std::for_each(someList.begin(), someList.end(), [&](int x) {
>   total += x
> });
> 
> "The specific internal implementation can vary, but the expectation is that
> the lambda function will store the actual stack pointer of the function it
> is created in, rather than individual references to stack variables."

So it's not really a closure, but a downward funarg. That's exactly the sort 
of thing I was talking about.  You can't return a lambda, I take it?

What's the type of
    [&](int x) { total += x; }

What kind of variable can I assign that to?

> What makes you think C++0x won't modify the compiler?!

Well, that's good. The syntax, of course, is going to be baroque because 
they're still trying to pretend they're upward compatible with C. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> I really have to wonder, sometimes, how far people are going to mutate C++ 
> >> before they just give up and decide they're done. :-)
> > 
> >   You make it sound like C++ is the only language which is constantly
> > being developed further by adding new features and new libraries (and
> > that this is somehow a negative thing?). That other currently used languages
> > are more or less "ready" and do not change much.

> No. But I think the current languages don't rewrite themselves as severely 
> as C++ does.

  Exactly how are they "rewriting" C++?

  C++0x will be basically fully compatible with the current C++ standard
(give or take a few minor things which will get deprecated). Only additional
functionality and libraries will be added. What rewrite?

> Other languages tend to add things, while C++ makes them 
> fundamental parts of the language.

  I don't understand. How are "adding things" and "making things fundamental
parts of the language" mutually exclusive?

  It's not like the new features would *replace* existing features. They
are pure additions. So I really don't see your point.

>  I'm assuming that the lambdas that C++ 
> is adding won't be just a library bit. If it is, then bleh, but OK.

  Lambdas will be at core language level in the exact same way as eg.
generics in Java are at cure language level. I don't see your problem.

> >   Of course that's pure BS. Most currently popular languages are being
> > constantly developed further and their libraries enhanced. Look at Java, C#
> > or the .NET framework. It's not that long ago that Java didn't even have
> > generics. Now it has them.

> Generics in Java are syntactic sugar. It still generates exactly the same 
> code as the equivalent source done in the obvious way.

  And lambdas in the new C++ are syntactic sugar. The compiler will generate
exactly the same machine code as if you had written a non-lambda function.
(The only difference is the internal name mangling.)

  They are a convenience feature. They will make a lot easier to write
generic code.

> > What is the current version of .NET? 3.something?

> Sure. And it has new syntax for new stuff, and it's cleanly integrated with 
> the rest of the language.

  You say it like the new C++ features aren't. Care to explain?

> >   Why do you deliberately make it sound like C++ is the only modern language
> > for which new features are being added?

> I'm not. I'm criticizing the way C++ adds new features, not that it does.

  Right. When other languages add new features (let's say, for example,
Java adding support for generics), that's ok. But when C++ adds new features,
that's something to be critiqued.

  No, you are not biased at all.

> Every new feature in C++ seems to be hurt by (1) not wanting to pay any 
> price if you don't use it,

  Care to explain how, for example, lambda functions would add some overhead
to the C++ language even when you don't use them?

> (2) not wanting to add any syntax for it,

  Have you even looked at how lambda functions will be written in the new
C++ standard? How is it not adding new syntax for it?

> and (3) 
> interacting poorly and confusingly with every other feature of the language.

  Care to elaborate?

> If C++ added lambdas and they actually had things like pointers to stack 
> frames and so on, I'd probably not be bothered. But I strongly suspect the 
> lambdas they add are going to have so much brokenness to deal with the lack 
> of automatic memory management and such that it's going to be harder to use 
> lambdas than to just declare your own functions. And I'm betting the syntax 
> will be so baroque it's going to be almost impossible to read without doing 
> parsing in your head, too. Looking the little I did at the Boost lambda's, 
> they're utterly awful compared to any other language with real lambdas built in.

  Good thing you are not prejudiced nor biased in the least.

> >   I don't know if I'm just being paranoid, but I honestly think that you
> > are doing this for the simple reason that you know that you are going to
> > troll me.

> No. I just don't like C++.

  And for that reason you have to constantly write prejudiced BS about it.

>  I think the way things get added to C++ is a bad 
> thing for a language.

  What way? Care to explain?

  And which way would you think would be better?

> When C# added LINQ, they didn't try to change the syntax of the language 
> without modifying the compiler.

  I don't even understand what you are saying there.

> Python added a lot of really ugly stuff under the covers, too. But it's 
> under the covers, and doesn't get in your way if you don't use it, and it's 
> usable for more than just the one idea the person thought of who suggested 
> it.

  First you critique C++ because the ideology is that new features don't
have any effect if you don't use it. Now you are praising Python for the
exact same thing, implying that in C++ new features *do* have some negative
effect even if you don't use them.

  You are not writing consistently.

  IMO you are just prejudiced and don't know what you are talking about.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> What's the type of
>     [&](int x) { total += x; }

> What kind of variable can I assign that to?

  You don't have to know the type (and in fact, the type is unspecified).
You create a variable like this:

auto myLambdaFunc = [&](int x) { total += x; };

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> std::for_each(someList.begin(), someList.end(), [&total](int x) {
>   total += x
> });

  I think they are also considering adding alternative versions of all
algorithms which take an iterator range. These alternative versions would
take a container and automatically apply the algorithm to all of its
elements, so you could just write:

    std::for_each(someList, [&total](int x) { total += x });

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> I think they are also considering adding alternative versions of all
> algorithms which take an iterator range. These alternative versions would
> take a container and automatically apply the algorithm to all of its
> elements

Yes, it's boost::range made standard :D (but probably implemented
differently)

Post a reply to this message

Darren New wrote:
> So it's not really a closure, but a downward funarg. That's exactly the
> sort
> of thing I was talking about.  You can't return a lambda, I take it?
> 
> What's the type of
>     [&](int x) { total += x; }
> 
> What kind of variable can I assign that to?

"Lambda functions are function objects of a implementation-dependent type;
this type's name is only available to the compiler. If the user wishes to
take a lambda function as a parameter, the type must be a template type, or
it must create a std::function to capture the lambda value. The use of the
auto keyword can locally store the lambda function"

The 'auto' keyword is what Warp mentioned. I guess you can also use
std::function to safely return a lambda.

"However, if the lambda function captures all of its closure variables by
reference, or if it has no closure variables, then its type shall be
publicly derived from std::reference_closure<R(P)>, where R(P) is the
function signature with return type. This is expected to be a more
efficient representation for lambda functions than capturing them in a
std::function."

All this is from Wikipedia article "C++0x". Next time please do some minimal
research before claiming C++ sucks :)

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> What's the type of
>>     [&](int x) { total += x; }
> 
>> What kind of variable can I assign that to?
> 
>   You don't have to know the type (and in fact, the type is unspecified).
> You create a variable like this:
> 
> auto myLambdaFunc = [&](int x) { total += x; };

And when you return that from the function as the function's value, what 
happens with the free variables? How do you declare the function that ends 
execution with "return myLambdaFunc"?  How do you make it a part of a structure?

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Nicolas Alvarez wrote:
> All this is from Wikipedia article "C++0x". Next time please do some minimal
> research before claiming C++ sucks :)

Oh, I see the answer to my question.

"""
Closure variables for local variables can also be defined without the 
reference symbol &, which indicates that the lambda function will copy the 
value. This forces the user to declare their intent to reference local 
variables or copy them. If a closure object containing references to local 
variables is invoked after the innermost block scope of its creation, the 
behaviour is undefined.
"""

So, basically, you don't really have lambda expressions. You have something 
that looks like a lambda expression but is really a pointer to a chunk of 
code. An actual lambda expression closes over variables, not over values. 
And it's a value itself, not a chunk of code that isn't possible to evaluate 
outside the context in which it was created.

You can't do something like

std::vector<std::function> xyz() {
   struct { int a; } alpha;
   std::vector<std::function> stuff;
   for (int i = 0; i < 10; i++) {
     stuff.pushback([](int x) { return alpha.a += x + i; };
   }
   return stuff;
}

void main() {
   std::vector<std::function> thing1 = xyz();
   std::vector<std::function> thing2 = xyz();
   ...
}

Basically, if you actually use a closure (rather than a downward funarg), 
you wind up with undefined behavior. I'm sorry to say, that means C++'s 
lambdas suck, and technically aren't even lambda expressions.

(Note this works fine in languages like C#, for example, because you 
actually can have pointers that get cleaned up when you're done, so you can 
generate code that allocates struct alpha on the stack and keeps it until 
you throw away all the lambda expressions.)

> All this is from Wikipedia article "C++0x". Next time please do some minimal
> research before claiming C++ sucks :)

Oh, C++ sucks for a lot more reasons than just next decade's changes. ;-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
>   It's not like the new features would *replace* existing features. They
> are pure additions. So I really don't see your point.

>   Lambdas will be at core language level in the exact same way as eg.
> generics in Java are at cure language level. I don't see your problem.

They interact poorly with the rest of the language, putting arbitrary 
limitations on them, and thus not actually solving the problems lambdas are 
usually used to solve. Thereby generally forcing yet another round of syntax 
and kludge piled on top of the existing language, in the next release when 
people try to fix *that*.

>   And lambdas in the new C++ are syntactic sugar. The compiler will generate
> exactly the same machine code as if you had written a non-lambda function.

Yeah. Which means they aren't lambdas. They're just called lambdas.

>> Sure. And it has new syntax for new stuff, and it's cleanly integrated with 
>> the rest of the language.
> 
>   You say it like the new C++ features aren't. Care to explain?

I thought the lambdas C++ was adding were actually lambdas. Since it's 
impossible to actually implement lambda expressions in C++, I thought it 
would be difficult to implement lambdas cleanly. I was right, but what C++ 
calls lambdas are actually implemented cleanly and integrated well. They 
just aren't lambdas. They're anonymous functions.

>> I'm not. I'm criticizing the way C++ adds new features, not that it does.
> 
>   Right. When other languages add new features (let's say, for example,
> Java adding support for generics), that's ok. But when C++ adds new features,
> that's something to be critiqued.

Criticized, not critiqued.

The difference is that C++ seems to want to have both low-level stuff (like 
manual memory management, say, and a lack of run-time type information) and 
high-level stuff (like functional programming and sophisticated separate 
compilation), and those sorts of things just don't go together well. You 
can't have closures in a language without runtime type information.

>> Every new feature in C++ seems to be hurt by (1) not wanting to pay any 
>> price if you don't use it,
> 
>   Care to explain how, for example, lambda functions would add some overhead
> to the C++ language even when you don't use them?

I would, *if* C++ actually was implementing lambda expressions. They're not. 
They're implementing inline anonymous functions that don't close over the 
free variables.

And yes, exactly, the *reason* that C++'s lambda expressions suck is 
*because* the designers of C++ don't want to add any overhead to support it.

>> (2) not wanting to add any syntax for it,
> 
>   Have you even looked at how lambda functions will be written in the new
> C++ standard? How is it not adding new syntax for it?

A complete lack of any sort of keyword, like, oh, "lambda" maybe?

OK, so I thought they were standardizing the way Boost did it. They aren't. 
It's better than that. But still wrong. :-)

>> and (3) 
>> interacting poorly and confusingly with every other feature of the language.
> 
>   Care to elaborate?

A lambda that closes over local variables is undefined if you return it from 
the function it was declared in? And (I'd guess) undefined if you use it 
outside the block it was declared in if that block declares local variables 
that are free inside the lambda expression?

A lambda that closes over a local variable "by value" closes over a 
different local variable than another lambda that closes over the same local 
variable?

>> If C++ added lambdas and they actually had things like pointers to stack 
>> frames and so on, I'd probably not be bothered. But I strongly suspect the 
>> lambdas they add are going to have so much brokenness to deal with the lack 
>> of automatic memory management and such that it's going to be harder to use 
>> lambdas than to just declare your own functions. And I'm betting the syntax 
>> will be so baroque it's going to be almost impossible to read without doing 
>> parsing in your head, too. Looking the little I did at the Boost lambda's, 
>> they're utterly awful compared to any other language with real lambdas built in.
> 
>   Good thing you are not prejudiced nor biased in the least.

"Prejudiced" would imply that I'm not making judgements based on experience, 
but rather based on lack of knowledge.  Since I've been using languages that 
support lambdas correctly for, oh, decades, as well as languages that can't 
and don't try, I think I've called this one properly.

I'm biased against ugly languages that are a pile of hacks to fix flaws in 
other hacks.

>>>   I don't know if I'm just being paranoid, but I honestly think that you
>>> are doing this for the simple reason that you know that you are going to
>>> troll me.
> 
>> No. I just don't like C++.
> 
>   And for that reason you have to constantly write prejudiced BS about it.

It's neither prejudiced nor BS. What makes you think it's prejudiced?

>>  I think the way things get added to C++ is a bad 
>> thing for a language.
> 
>   What way? Care to explain?

Sure. Adding a lambda expression whose evaluation is undefined depending on 
where you invoke it and what variables it uses is "bad". The "way" in which 
it gets added is "this works in a few limited cases to solve a handful of 
specific problems, and if we can't support it well, we'll just do undefined 
behavior instead of telling you it's broken."

>   And which way would you think would be better?

Either accept that your language isn't suitable for that sort of 
programming, or do it right.

>> Python added a lot of really ugly stuff under the covers, too. But it's 
>> under the covers, and doesn't get in your way if you don't use it, and it's 
>> usable for more than just the one idea the person thought of who suggested 
>> it.
> 
>   First you critique C++ because the ideology is that new features don't
> have any effect if you don't use it. 

No. I criticize C++ because the ideology is that new features aren't allowed 
to add any overhead if you don't use them, and hence the new features are 
broken by design to meet that other goal.

> Now you are praising Python for the exact same thing,

No. I'm simply saying that Python, while under the covers is ugly in some 
ways, nevertheless is done *right* in the sense that instead of saying "this 
is ugly, and hence broken," they say "this is ugly, but it works right."

>   IMO you are just prejudiced and don't know what you are talking about.

When C++ stops adding features that have undefined behavior when you use 
those same features the way the rest of the world does, I'll believe that 
C++ is adding elegant features. As it is, I'll just have to laugh at people 
who say that C++ is adding lambda expressions in the next release, just like 
I laugh when people say things like "C++ has automatic memory management as 
long as you write all the management code into your application and take 
care not to hit the corner cases that blow up your memory model."

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
>     std::for_each(someList, [&total](int x) { total += x });

And, really, what's the advantage of this over a normal for loop?

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

"Programming languages should be designed not by piling feature on top of
feature, but by removing the weaknesses and restrictions that make additional
features appear necessary."
-- William D. Clinger in:
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-3.html#%_chap_Temp_3
http://lists.r6rs.org/pipermail/r6rs-discuss/2007-July/003080.html

C++ has always evolved by the exact opposite, by going from a simple C with
Objects preprocessor to a Java/C# wannabe now and everything in-between
(Haskell, Python etc).

There's only one other language that also evolves by continual absorption.  That
being Perl, which still hasn't got anywhere near complete in the 6th revision,
started about 1 decade ago.  It's hard to keep up with all that barroque
counterpoint.

Post a reply to this message

nemesis wrote:
> C++ has always evolved by the exact opposite, by going from a simple C with
> Objects preprocessor to a Java/C# wannabe now and everything in-between
> (Haskell, Python etc).

Which might not be so bad, except for the insistence that they add no actual 
runtime support for any of it. So every feature is implemented half-assed, 
with the other butt-cheek left to the programmer to fill in, lest you wind 
up with a program that sits crooked.  And heaven forbid any actual useful 
application-level libraries be standardized. :-)

> There's only one other language that also evolves by continual absorption.  That
> being Perl, which still hasn't got anywhere near complete in the 6th revision,
> started about 1 decade ago.  It's hard to keep up with all that barroque
> counterpoint.

Yeah, I don't like Perl either. ;-)

On the other hand, I've decided that Python 3.x has finally surpassed Tcl in 
terms of the capabilities that I use on a normal daily basis. It finally 
supports unicode cleanly, multithreading, event programming, multiple 
embedded interpreters, wrapped scripts, and so on. It actually does a lot 
more than Tcl, and did, but it was missing some of my must-have features 
which is now has in 3.x.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On the other hand, I've decided that Python 3.x has finally surpassed Tcl in
> terms of the capabilities that I use on a normal daily basis. It finally
> supports unicode cleanly, multithreading, event programming, multiple
> embedded interpreters, wrapped scripts, and so on. It actually does a lot
> more than Tcl, and did, but it was missing some of my must-have features
> which is now has in 3.x.

It also features much cleaner syntax and semantics.  uplevel?!  frankly... :P

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Basically, if you actually use a closure (rather than a downward funarg), 
> you wind up with undefined behavior. I'm sorry to say, that means C++'s 
> lambdas suck, and technically aren't even lambda expressions.

  You have embarked in a holy quest to prove that C++ will not have "true"
lambda functions, and for that reason it sucks. In fact, it seems that you
have started a holy war against C++ right now. Whatever it takes to prove
that it sucks.

  Now that you have "proven" that C++ will not have "true" lambda functions,
you must be exhilarated.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   It's not like the new features would *replace* existing features. They
> > are pure additions. So I really don't see your point.

> >   Lambdas will be at core language level in the exact same way as eg.
> > generics in Java are at cure language level. I don't see your problem.

> They interact poorly with the rest of the language, putting arbitrary 
> limitations on them, and thus not actually solving the problems lambdas are 
> usually used to solve. Thereby generally forcing yet another round of syntax 
> and kludge piled on top of the existing language, in the next release when 
> people try to fix *that*.

  Says the person who didn't even know how lambda functions will be
implemented in the next C++.

  Good thing you are not prejudiced in the least.

> >   And lambdas in the new C++ are syntactic sugar. The compiler will generate
> > exactly the same machine code as if you had written a non-lambda function.

> Yeah. Which means they aren't lambdas. They're just called lambdas.

  I like it how you succeed in making *everything* sound negative when
applied to C++, while at the same time the *exact same thing* is positive
in other languages.

  For example, generics in Java being "just syntactic sugar" is a positive
thing, while lambdas in C++ being "just syntactic sugar" is a negative thing.

  Good thing you are not biased in the least.

> You can't have closures in a language without runtime type information.

  Oh, now C++ doesn't even have RTTI. Right.

  Like "lambdas", what is called "RTTI" in C++ is not *really* RTTI, right?

  I start seeing your general rule of thumb: Every programming language
feature, when implemented in C++, either isn't *really* that true feature,
or is magically converted into a negative aspect of the language (while
it's a positive feature in all other languages).

> >> (2) not wanting to add any syntax for it,
> > 
> >   Have you even looked at how lambda functions will be written in the new
> > C++ standard? How is it not adding new syntax for it?

> A complete lack of any sort of keyword, like, oh, "lambda" maybe?

  Wow. The lack of a keyword is now a negative feature. Right.

  I'm sure that if there was a keyword, that would also be a negative
feature. *Everything* is negative when implemented in C++.

> >   Good thing you are not prejudiced nor biased in the least.

> "Prejudiced" would imply that I'm not making judgements based on experience, 
> but rather based on lack of knowledge.

  Are you seriously telling me that you did extensive research on the
new lambda function feature as specified by the current C++0x standard
draft before making your remarks? Because it certainly didn't sound like
that to me. It sounded more like you were making tons of assumptions and
bashing the feature based solely on that.

> I'm biased against ugly languages that are a pile of hacks to fix flaws in 
> other hacks.

  At least you dare to admit it.

> >> No. I just don't like C++.
> > 
> >   And for that reason you have to constantly write prejudiced BS about it.

> It's neither prejudiced nor BS. What makes you think it's prejudiced?

  Because you write about a new language feature without even knowing how
it will be implemented.

> I'll just have to laugh at people 
> who say that C++ is adding lambda expressions in the next release, just like 
> I laugh when people say things like "C++ has automatic memory management as 
> long as you write all the management code into your application and take 
> care not to hit the corner cases that blow up your memory model."

  I hope you have a good time laughing.

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> C++ has always evolved by the exact opposite, by going from a simple C with
> Objects preprocessor to a Java/C# wannabe now and everything in-between
> (Haskell, Python etc).

  Yes, let's all join in group-bashing C++.

  Every new feature added to C++ is wrong and sucks. Every new feature
added to Java or C# is right and rules. This even if it's the exact same
feature.

  Btw, I find it hilarious that you call C++ a "Java wannabe". Java is
a rather horrible object-oriented language which lacks lots of features
which would help in abstraction and modularity.

  But of course we are talking about C++ here, and *everything* in C++
sucks. Consequently everything that Java does differently than C++
rules. Thus Java is in all possible aspects the superior language, and
consequently C++ is just a "Java wannabe".

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >     std::for_each(someList, [&total](int x) { total += x });

> And, really, what's the advantage of this over a normal for loop?

  Nothing. Since it's C++ code, it sucks.

  In fact, C++'s for-loop also sucks. Everything in C++ sucks. Even if
it's a byte-by-byte identical feature as in some other, better language,
it still sucks because it's in C++.

-- 
                                                          - Warp

Post a reply to this message